Apple rilascia l'aggiornamento Mac OS X 10.6.1

[Nui_Mg]

Originariamente inviato da simon71

(Auguri!)

Cavolo, veramente, la maggior parte poi non sa che di default Win7 ha un bucone nello UAC che sembra non verra' fixato perche' per microsoft non e' tale:

-------------------------------------------------------------------------
e, a tal proposito e ritornando ad alcune osservazioni su Seven e ultime novita' su UAC, ecco come Russinovich (Technical Fellow at Microsoft in the Platform and Services Division) cerca di giustificare la non voglia di M$ di recepire utili feedback per evitare i buchi di Win (si e' "scoperto" che per M$ lo UAC e' piu' uno strumento/"feature" per educare nel medio-lungo periodo gli sviluppatori e non per dare un po' piu' di sicurezza dai malware nell'immediato):
--------------------
Several people have observed that it's possible for third-party software running in a PA account (Protected Administrator account) with standard user rights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the WriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code, a technique called DLL injection. Since the code is executing in Explorer, which is a Windows executable, it can leverage the COM objects that auto-elevate, like the Copy/Move/Rename/Delete/Link Object, to modify system registry keys or directories and give the software administrative rights. While true, these steps require deliberate intent, aren't trivial, and therefore are not something we believe legitimate developers would opt for versus fixing their software to run with standard user rights. In fact, we recommend against any application developer taking a dependency on the elevation behavior in the system and that application developers test their software running in standard user mode.

The follow-up observation is that malware could gain administrative rights using the same techniques. Again, this is true, but as I pointed out earlier, malware can compromise the system via prompted elevations as well. From the perspective of malware, Windows 7's default mode is no more or less secure than the Always Notify mode ("Vista mode"), and malware that assumes administrative rights will still break when run in Windows 7's default mode.
--------------------

Sul blog di M$ ci sono stati ottimi suggerimenti (immediati/facilissimi da implementare senza stravolgere in alcun modo il "disegno" di M$) da parte di gente preparata per colmare certe assurde "visioni" di M$ : niente da fare, per M$ e' una feature, il fatto che si possa venire facilmente infettati (in rete ci sono i binari e pure i sorgenti per sfruttare la "feature") e' un effetto collaterale.
-------------------------------------------------------------------------

Provato anche su 7 rtm professional l'exploit dell'autoelevazione, funziona ancora, "ben fatto" microsoft

[PaveK]

Originariamente inviato da dotlinux

Se penso che in azienda siamo passati da osx a Vista64 ... (42 postazioni, facciamo effetti speciali per il cinema)
Voi ci uccidereste tutti!

W la vita! ^_^
Dai, non è così raro quando ci si trova in settori molto specifici. Vi auguro il massimo dei risultati col minimo sforzo

[AlexSwitch]

@ sapo84 e curtis

Guardate qui come funziona il discorso dei 64 bit in OS X SL:



In figura vengono mostrati i processi di sistema, kernel task a parte, contate quanti ce ne sono a 32 bit.... Nessuno!!
Stessa cosa per le estensioni del Kernel e i dirvers: tutti scritti a 64 bit.... Idem per il 90% dei framework, e lelibrerie....
E tutti girano assieme a software a 32 bit... Una cosa molto diversa da Vista e Seven a 64 bit, dove tutto il codice deve essere scritto a 64 bit altrimenti non funzionano....

[Simock85]

Originariamente inviato da Nui_Mg

Cavolo, veramente, la maggior parte poi non sa che di default Win7 ha un bucone nello UAC che sembra non verra' fixato perche' per microsoft non e' tale:

-------------------------------------------------------------------------
e, a tal proposito e ritornando ad alcune osservazioni su Seven e ultime novita' su UAC, ecco come Russinovich (Technical Fellow at Microsoft in the Platform and Services Division) cerca di giustificare la non voglia di M$ di recepire utili feedback per evitare i buchi di Win (si e' "scoperto" che per M$ lo UAC e' piu' uno strumento/"feature" per educare nel medio-lungo periodo gli sviluppatori e non per dare un po' piu' di sicurezza dai malware nell'immediato):
--------------------
Several people have observed that it's possible for third-party software running in a PA account (Protected Administrator account) with standard user rights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the WriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code, a technique called DLL injection. Since the code is executing in Explorer, which is a Windows executable, it can leverage the COM objects that auto-elevate, like the Copy/Move/Rename/Delete/Link Object, to modify system registry keys or directories and give the software administrative rights. While true, these steps require deliberate intent, aren't trivial, and therefore are not something we believe legitimate developers would opt for versus fixing their software to run with standard user rights. In fact, we recommend against any application developer taking a dependency on the elevation behavior in the system and that application developers test their software running in standard user mode.

The follow-up observation is that malware could gain administrative rights using the same techniques. Again, this is true, but as I pointed out earlier, malware can compromise the system via prompted elevations as well. From the perspective of malware, Windows 7's default mode is no more or less secure than the Always Notify mode ("Vista mode"), and malware that assumes administrative rights will still break when run in Windows 7's default mode.
--------------------

Sul blog di M$ ci sono stati ottimi suggerimenti (immediati/facilissimi da implementare senza stravolgere in alcun modo il "disegno" di M$) da parte di gente preparata per colmare certe assurde "visioni" di M$ : niente da fare, per M$ e' una feature, il fatto che si possa venire facilmente infettati (in rete ci sono i binari e pure i sorgenti per sfruttare la "feature") e' un effetto collaterale.
-------------------------------------------------------------------------

Provato anche su 7 rtm professional l'exploit dell'autoelevazione, funziona ancora, "ben fatto" microsoft

mm no guarda che quel buco è stato chiuso già nella RC, evidentemente non hai provato l'exploit di autoelevazione nella RTM. E' stato indivduato da Raphael Rivera nella Beta, la risposta "by design" da parte di microsoft ha sollevato (giustamente) un polverone. Rafael e tanti altri proponevano di rimuovere l’applet UAC dalla whitelist ed in tal modo qualsiasi tentativo di cambiare il setting UAC dall’esterno avrebbe richiesto un ulteriore prompt mettendo in guardia l’utente. Ma andando a leggere il blog Engineering Windows 7 ci si accorge invece che il problema è stato individuato ed è stata data giusta soluzione già dalla RC: il problema non stava nel fatto che cambiare i setting di UAC non richiedesse nessun prompt ma che l’applet fosse pilotabile da altre applicazioni; individuato il problema la soluzione è diventata ovvia: anziché usare il secure desktop basta aumentare il livello di integrità in cui l’applet gira per impedire che riceva messaggi dalle applicazioni desktop che girano sotto l’utenza normale. Basterebbe questo per risolvere il problema e rimuovere UAC dalla whitelist non diventa più necessario; quest’ultima cosa è stata comunque fatta per motivi psicologici.

[Gurzo2007]

Originariamente inviato da AlexSwitch

In figura vengono mostrati i processi di sistema, kernel task a parte, contate quanti ce ne sono a 32 bit.... Nessuno!!
Stessa cosa per le estensioni del Kernel e i dirvers: tutti scritti a 64 bit.... Idem per il 90% dei framework, e lelibrerie....
E tutti girano assieme a software a 32 bit... Una cosa molto diversa da Vista e Seven a 64 bit, dove tutto il codice deve essere scritto a 64 bit altrimenti non funzionano....

veramente in vista/seven 64bit, il sw scritto a 32bit funziona benissimo...e il contrario che non si può fare...

ciò avveniva anke in xp 64bit...non è niente di nuovo

[gianly1985]

Originariamente inviato da Gurzo2007

veramente in vista/seven 64bit, il sw scritto a 32bit funziona benissimo...e il contrario che non si può fare...

ciò avveniva anke in xp 64bit...non è niente di nuovo

La differenza è che in OSX grazie al kernel 32bit a funzionamento "ibrido" (maggiori informazioni qua) è stato possibile, "di nascosto agli utenti" (nel senso senza porli davanti al dubbio "32 o 64"), mettere un OS 64 bit "capable" su TUTTI i mac già dal 2005 con Tiger, senza causare grattacapi agli utenti (kernel e drivers 32bit ---> no problemi) e senza rallentare la diffusione del 64bit vendendo 2 versioni diverse del OS di cui quella 32bit pre-installata nella stragrande maggioranza dei casi.

Infatti già da Tiger si può fare 64bit computing a tutti gli effetti su tutti i mac (CPU permettendo), l'unica limitazione è che si possono fare applicazioni faceless (senza GUI), ma per aggirare questa limitazione basta creare una GUI 32bit che si appoggia al processo 64bit in questione.

Poi con Leopard nel 2007 è arrivata la possibilità di usare applicazioni 64bit complete al 100%, con tanto di GUI. (es. Adobe Lightroom 2, Chess, Quartz Composer, ecc.). Ancora una volta su tutti i Mac (CPU permettendo).

La novità con SL nel 2009 è che sono state riscritte a 64bit quasi tutte le applicazioni di sistema e c'è ANCHE il kernel 64bit (che non E' necessario per usare apps 64bit, vedi Tiger e Leopard). Ma le apps a 64bit si possono usare su tutti i Mac già da Leopard, la differenza è che in SL c'è una bella infornata di Apps 64bit made in Apple (fra cui per esempio il Finder che ha subito un boost prestazionale estremamente tangibile dal fatto di essere stato riscritto in Cocoa 64bit).

Le parole che ti ho evidenziato in rosso costituiscono la differenza fra l'approccio MS e l'approccio Apple al passaggio al 64bit computing, giudica tu quale dei 2 sia più efficace nello "spingere per i 64bit".

[Nui_Mg]

Originariamente inviato da Simock85

mm no guarda che quel buco è stato chiuso già nella RC,

Quella e' roba vecchia, non ce n'era solo uno (come detto io ho provato sulla rtm professional di msdnaa e il bucone c'e' ancora tenendo lo UAC impostato di default: e' anche soprattutto il fatto che non sia impostato al livello max che si rimprovera a MS) e infatti Davidson:
-----------------------------------
Update: Windows 7 RC1 (build 7100) is out now and nothing has changed in this area. (A lot of other stuff has changed and it's a better version of Windows, but the UAC/injection stuff still works like it used to.) It now seems even more unlikely that anything will be changed in time for the RTM, especially as MS still haven't replied to my offers to give them full details.
-----------------------------------

E, 30 luglio:
---------------------------------
Update (~Bryant): let’s take a look at what’s going on here from a different approach. Microsoft says that the vulnerability here is not actually a vulnerability and is, in fact, by design. However, they’ve also classified Leo’s proof-of-concept as malware. Logically speaking, if a process whose sole purpose is to exploit a perceived vulnerability is marked as malware, then it’s reasonable to assume that the perceived vulnerability is indeed a significant problem. Basically, Microsoft contradicted themselves by listing the proof-of-concept as malware.
---------------------------------

[AlexSwitch]

Originariamente inviato da Gurzo2007

veramente in vista/seven 64bit, il sw scritto a 32bit funziona benissimo...e il contrario che non si può fare...

ciò avveniva anke in xp 64bit...non è niente di nuovo

Hai ragione, ma rimane sempre una grossa differenza rispetto a OS X ( partendo da Tiger fino a Snow Leopard ): il kernel a 64 bit di NT per elaborare le istruzioni a 32 si deve appoggiare ad un layer di emulazione WOW ( Windows on Windows ) che traduce al volo le istruzioni IA 32 in IA 64.
Il Kernel darwin di OS X invece grazie alle sue estensioni a 64 bit ( nella versione a 32 ) permette di far elaborare codice a 32 e a 64 bit parallelamente, senza nessun emulatore.... Ecco perchè non esiste una versione di Snow Leopard a 32 bit e un altra a 64.....

[bio82]

Originariamente inviato da dotlinux

Se penso che in azienda siamo passati da osx a Vista64 ... (42 postazioni, facciamo effetti speciali per il cinema)
Voi ci uccidereste tutti!

uno dopo l'altro iniziano a crollare tutti gli ambiti dove il mac era predominante...

Originariamente inviato da AlexSwitch

Una cosa molto diversa da Vista e Seven a 64 bit, dove tutto il codice deve essere scritto a 64 bit altrimenti non funzionano....

confermo che hai scritto una stupidata....

Originariamente inviato da AlexSwitch

Hai ragione, ma rimane sempre una grossa differenza rispetto a OS X ( partendo da Tiger fino a Snow Leopard ): il kernel a 64 bit di NT per elaborare le istruzioni a 32 si deve appoggiare ad un layer di emulazione WOW ( Windows on Windows ) che traduce al volo le istruzioni IA 32 in IA 64.
Il Kernel darwin di OS X invece grazie alle sue estensioni a 64 bit ( nella versione a 32 ) permette di far elaborare codice a 32 e a 64 bit parallelamente, senza nessun emulatore.... Ecco perchè non esiste una versione di Snow Leopard a 32 bit e un altra a 64.....

e quindi hai 2 kernel caricati? wow non traduce le istruzioni ma solo gli indirizzamenti di memoria....

bio

[gianly1985]

Originariamente inviato da bio82

e quindi hai 2 kernel caricati? wow non traduce le istruzioni ma solo gli indirizzamenti di memoria....

E' tutto spiegato qui:

http://www.appleinsider.com/articles...he_kernel.html

[AlexSwitch]

Originariamente inviato da bio82

uno dopo l'altro iniziano a crollare tutti gli ambiti dove il mac era predominante...



confermo che hai scritto una stupidata....




e quindi hai 2 kernel caricati? wow non traduce le istruzioni ma solo gli indirizzamenti di memoria....

bio

A me pare proprio il contrario, visto che le istruzioni IA 32 ( i386 ) sono differenti dalle IA 64 ( i386_64 ); è un codice completamente diverso sia per la tipologia delle istruzioni, che per la lunghezza delle parole e dei dati. La gestione della memoria è solamente un aspetto del problema di far elaborare codice a 32 bit in un ambiente operativo a 64.

Per quanto riguarda il kernel Darwin di OS X, questo è unico ( o 32 o 64 bit ) ma la sua architettura ibrida permette l'uso di Kext ( kernel extension ), ovvero di porzioni di codice così interne e strettamente collegate al kernel, da essere considerati dei " microkernel ". Grazie a questa architettura si può far girare codice a 32 e 64 bit parallelamente, senza la necessità di tradurre le istruzioni, visto che ogni extension provvederà ad elaborare nativamente il codice a 32 bit o a 64 bit.
Ciò è vero soprattutto nel caso in cui il kernel caricato sia a 32 bit, perchè senza extension non permetterebbe l'esecuzione di codice a 64 bit. L'immagine che ho postato precedentemente spiega il tutto in maniera molto chiara.

[bio82]

Originariamente inviato da gianly1985

E' tutto spiegato qui:

http://www.appleinsider.com/articles...he_kernel.html

Originariamente inviato da AlexSwitch

A me pare proprio il contrario, visto che le istruzioni IA 32 ( i386 ) sono differenti dalle IA 64 ( i386_64 ); è un codice completamente diverso sia per la tipologia delle istruzioni, che per la lunghezza delle parole e dei dati. La gestione della memoria è solamente un aspetto del problema di far elaborare codice a 32 bit in un ambiente operativo a 64.

Per quanto riguarda il kernel Darwin di OS X, questo è unico ( o 32 o 64 bit ) ma la sua architettura ibrida permette l'uso di Kext ( kernel extension ), ovvero di porzioni di codice così interne e strettamente collegate al kernel, da essere considerati dei " microkernel ". Grazie a questa architettura si può far girare codice a 32 e 64 bit parallelamente, senza la necessità di tradurre le istruzioni, visto che ogni extension provvederà ad elaborare nativamente il codice a 32 bit o a 64 bit.
Ciò è vero soprattutto nel caso in cui il kernel caricato sia a 32 bit, perchè senza extension non permetterebbe l'esecuzione di codice a 64 bit. L'immagine che ho postato precedentemente spiega il tutto in maniera molto chiara.

in parole povere osx usa lo stesso metodo di xp64/vista64/2003server64 per emulare i 32 bit, ma lo fa anche al contrario (dal kernel32 a 64bit)...

cambia veramente poco a parte il fatto che facendolo la apple è un genialata, facendolo la microsoft è una stronzata...

l'unica cosa che rimane incerta dall'articolo linkato è se la gestione della memoria su SL avviene a 64bit o a 36 (32+PAE); l'articolo è decisamente vecchio...

bio

[Curtis]

Ci sarebbero da scrviere un sacco di cose sul presunto 64bit gia' da osx 10.5 Leopard ( come vantano 2 utenti apple) Vs il 64bit di un Vista 64bit o Win7 64bit, piu' tutto il resto ma non le scrivo altrimenti questo thread nato per una discussione sull'aggiornamento di osx 10.6 travalica poi in una guerriglia 64bit windows vs. 64 osx e succede un putiferio .Gia' so che poi finisce cosi'
Condivido cio' che ha scritto Bio

[AlexSwitch]

Originariamente inviato da bio82

in parole povere osx usa lo stesso metodo di xp64/vista64/2003server64 per emulare i 32 bit, ma lo fa anche al contrario (dal kernel32 a 64bit)...

cambia veramente poco a parte il fatto che facendolo la apple è un genialata, facendolo la microsoft è una stronzata...

l'unica cosa che rimane incerta dall'articolo linkato è se la gestione della memoria su SL avviene a 64bit o a 36 (32+PAE); l'articolo è decisamente vecchio...

bio

Allora non hai letto per bene gli articoli..... Peccato...
La gestione della memoria avviene a 64 bit.
Sulla gestione dei 32 bit da parte del kernel NT a 64 bit ( lo stesso di Xp, Vista e Seven ) e di che cosa sia WOW leggi qui:

http://it.wikipedia.org/wiki/Windows_XP_64_bit_Edition

Mi pare che le cose, rispetto a Darwin siano parecchio diverse...
Un piccolo appunto: chi ha scritto che Ms ha fatto " stronzate " e Apple " genialate "? Mi pare nessuno, forse ti sei perso il fatto che qui si stanno paragonando due filosofie diverse ( quella di MS e quella di Apple ) di come implementare codice a 32 e 64 bit nello stesso sistema operativo.
Forse è a qualcun altro che piace sparare a zero ( non sei te bio ) senza informarsi.

[bio82]

Originariamente inviato da AlexSwitch

Allora non hai letto per bene gli articoli..... Peccato...

in quell'articolo non sapevano ancora come sarebbe stata gestita la memoria (articolo datato)...

bio

[gianly1985]

L'articolo sarà "datato" (oddio...ottobre 2008) ma tutto quello che c'è scritto sul funzionamento del kernel di OSX resta corretto. (e ampiamente verificato già ai tempi dell'articolo, visto che appunto processi 64bit con CPU 64bit e kernel 32bit si facevano girare già su Tiger dal 2005)

Anche sulla memoria non capisco a cosa di riferisci, è giusto e chiaro quello che hanno scritto:

- Tiger, Leopard, SL@kernel32bit -----> max 32gb (PAE)

- SL@kernel64bit -----> più di 32gb (nella fattispecie 16 exabyte credo)

Lo dice nell'asteriscato sotto (**).

Per quel che riguarda la memoria utilizzabile dalle singole APPLICAZIONI, abbiamo che:

Tiger (kernel32bit):
- Applicazione 32bit ---> max 4gb
- Processo (senza GUI) 64bit ----> max 16 exabyte (teoricamente ma limitato dal fatto che il sistema non ne vede più di 32gb)

Leopard (kernel32bit)
- Applicazione 32bit ----> max 4gb
- Applicazione 64bit ----> max 16 exabyte (teoricamente ma limitato dal fatto che il sistema non ne vede più di 32gb, quindi max 32gb)

Snow Leopard (kernel32bit)
- Applicazione 32bit ----> max 4gb
- Applicazione 64bit ----> max 16 exabyte (teoricamente ma limitato dal fatto che il sistema non ne vede più di 32gb, quindi max 32gb)

Snow Leopard (kernel64bit)
- Applicazione 32bit ----> max 4gb
- Applicazione 64bit ----> max 16 exabyte (stavolta non teoricamente)

Il succo è che su OSX veramente non c'è proprio fretta di partire col kernel 64bit. Perchè nel frattempo si gode già dal 2007 di applicazioni 64bit su tutte le versioni (UNA) del OS in circolazione. Sia per la questione memoria addressabile, sia con gli altri vantaggi del 64 bit computing, vedere questo benchmark effettuato su Leopard. (quindi con kernel32bit, come si vede questo non inficia i vantaggi di usare apps 64bit, grazie al "funzionamento ibrido" di suddetto kernel e le sue estensioni)

Nessuno ha parlato di "stronzate" o "genialate", è solo un approccio diverso permesso anche da una struttura del sistema diverso, ma non si può negare che uno dei 2 approcci sia intrinsecamente:
- più hassle-free per gli end users
- più efficace nel diffondere il 64 bit computing A TAPPETO su tutte le macchine

Semplicemente quindi si rispondeva questo a chi giudicava più rilevante "sì ma XXX ha messo in circolazione per prima una versione 64bit integrale, già visto, già fatto". A mio modestissimo (e parziale) parere forse è più rilevante il riuscire a diffondere i 64bit A TAPPETO e creare quindi un circolo virtuoso che invogli quanti più developers possibili a sviluppare applicazioni 64bit.

[macfanboy]

La recensione definitiva di Snow Leopard è ovviamente quella di ArsTechnica.

I dettagli della modalità 64 bit sono a pagina 5 della mostruosa recensione.

Comunque il succo... è che la vera potenza di OS X (e di Apple in generale) è di rendere disponibili agli utenti tecnologie innovative ed avanzate con la massima semplicità e TRASPARENZA. Il 99% degli utenti di computer non sa che significa un OS a 32 o 64 bit e NON DOVREBBE AVERE NECESSITA' DI SAPERLO. Perfino gli utenti più tecnici di questo forum per appassionati spesso si accapigliano sulla sua definizione (l'indirizzamento? I registri? Il kernel? Mah).

Ma come d'uso con i sistemi Apple i 64 bit sono arrivati (piano piano, per gradi, ma ora sono qui davvero basta vedere lo screenshot postato qualche messaggio più su) e... l'utente neanche se ne accorge!!
Questa è la cosa davvero notevole di Snow Leopard. Non 2 versioni da scegliere come Windows o Linux. Una sola, nessuna scelta. Funziona e basta.

Per la cronaca comunque il kernel su Snow Leopard di default parte ancora a 32 bit su quasi tutti i computer venduti (tranne che sugli Xserve), ma basta tenere premuti i tasti "6-4" all'avvio per avere, voilat!, anche il kernel a 64 bit! E per quanto ho potuto vedere (in qualche minuto di prova) alla fine non cambia niente, funziona tutto lo stesso. Magica Apple!!!

[Curtis]

Originariamente inviato da macfanboy

La recensione definitiva di Snow Leopard è ovviamente quella di ArsTechnica.

I dettagli della modalità 64 bit sono a pagina 5 della mostruosa recensione.

Comunque il succo... è che la vera potenza di OS X (e di Apple in generale) è di rendere disponibili agli utenti tecnologie innovative ed avanzate con la massima semplicità e TRASPARENZA. Il 99% degli utenti di computer non sa che significa un OS a 32 o 64 bit e NON DOVREBBE AVERE NECESSITA' DI SAPERLO. Perfino gli utenti più tecnici di questo forum per appassionati spesso si accapigliano sulla sua definizione (l'indirizzamento? I registri? Il kernel? Mah).

Ma come d'uso con i sistemi Apple i 64 bit sono arrivati (piano piano, per gradi, ma ora sono qui davvero basta vedere lo screenshot postato qualche messaggio più su) e... l'utente neanche se ne accorge!!
Questa è la cosa davvero notevole di Snow Leopard. Non 2 versioni da scegliere come Windows o Linux. Una sola, nessuna scelta. Funziona e basta.

Per la cronaca comunque il kernel su Snow Leopard di default parte ancora a 32 bit su quasi tutti i computer venduti (tranne che sugli Xserve), ma basta tenere premuti i tasti "6-4" all'avvio per avere, voilat!, anche il kernel a 64 bit! E per quanto ho potuto vedere (in qualche minuto di prova) alla fine non cambia niente, funziona tutto lo stesso. Magica Apple!!!

sai vero perche' il kernel di osx 10.6 parte di default a 32bit quando invece potrebbe partire a 64?
non te lo dico

[Simock85]

Originariamente inviato da Nui_Mg

Quella e' roba vecchia, non ce n'era solo uno (come detto io ho provato sulla rtm professional di msdnaa e il bucone c'e' ancora tenendo lo UAC impostato di default: e' anche soprattutto il fatto che non sia impostato al livello max che si rimprovera a MS) e infatti Davidson:
-----------------------------------
Update: Windows 7 RC1 (build 7100) is out now and nothing has changed in this area. (A lot of other stuff has changed and it's a better version of Windows, but the UAC/injection stuff still works like it used to.) It now seems even more unlikely that anything will be changed in time for the RTM, especially as MS still haven't replied to my offers to give them full details.
-----------------------------------

E, 30 luglio:
---------------------------------
Update (~Bryant): let’s take a look at what’s going on here from a different approach. Microsoft says that the vulnerability here is not actually a vulnerability and is, in fact, by design. However, they’ve also classified Leo’s proof-of-concept as malware. Logically speaking, if a process whose sole purpose is to exploit a perceived vulnerability is marked as malware, then it’s reasonable to assume that the perceived vulnerability is indeed a significant problem. Basically, Microsoft contradicted themselves by listing the proof-of-concept as malware.
---------------------------------

Stiamo parlando dello stesso "bug", uac impostato non al massimo livello non richiede conferma per l'elevazione dei privilegi per quelle applicazioni che stanno in una white list. Purtroppo la stessa applet che gestisce i setting UAC era nella white list ed era possibile con uno script disabilitare UAC. Ora non è + possibile, uso la RTM professional e te lo garantisco:
http://blogs.msdn.com/e7/archive/200...follow-up.aspx

[theJanitor]

l'ennesima diatriba Mac vs Win, strano