Prima che Windows introducesse l'isolamento dei privilegi dell'interfaccia utente, qualsiasi applicazione poteva inviare tutti i tipi di messaggi della finestra a qualsiasi finestra sullo stesso desktop (un attacco sferrato), consentendo l'elevazione dei privilegi.
Ora, UIPI arresta le applicazioni con privilegi limitati dall'invio di molti messaggi della finestra a applicazioni con privilegi più elevati. Wikipedia dice :
User Interface Privilege Isolation (UIPI) is a technology introduced in Windows Vista/2008 Server to combat shatter attack exploits. By making use of Mandatory Integrity Control, it prevents processes with a lower "integrity level" (IL) from sending messages to higher IL processes (except for a very specific set of UI messages).
Sembra che dovrebbe affrontare il problema - secondo questo PDF collegato in quell'articolo, solo WM_NULL , WM_MOVE , WM_SIZE , WM_GETTEXT , WM_GETTEXTLENGTH , WM_GETHOTKEY , WM_GETICON , WM_RENDERFORMAT , WM_DRAWCLIPBOARD , WM_CHANGECBCHAIN , WM_THEMECHANGED e% co_de non documentato e 0x313 sono consentiti. (Il PDF menziona un possibile attacco denial-of-service, a partire da pagina 57, ma mentre un problema non è l'elevazione dei privilegi. Ho anche fatto un controllo superficiale della DLL responsabile, e sembra che su Windows 8 non funzioni in realtà registra il messaggio che porta al problema.)
Non sembra che nessuno di questi abbia problema creato da 0x31B , che ha portato il processo di destinazione a passare a un indirizzo arbitrario. Tuttavia, questo articolo di un blogger Microsoft (Raymond Chen) insinua strongmente gli attacchi in frantumi sono ancora un problema:
What you can do is have a service inject the program into the session, and let it run as the logged-on user. (You have to make it run as the logged-on user in order to avoid a shatter attack.)
Questo documento Microsoft su Controllo dell'account utente rileva che alcune risorse "sono ancora condivise tra i processi a diversi livelli di privilegio ":
- Desktop window, which actually owns the screen surface.
- Desktop heap read-only shared memory.
- Global atom table.
- Clipboard
Tuttavia, il semplice fatto di avere quelle cose accessibili da processi con livelli di privilegio diversi non sembra consentire il salto effettivo che causa l'elevazione dei privilegi. E anche se fosse stato fatto il salto, pensavo che Data Execution Prevention avrebbe impedito l'esecuzione effettiva del codice iniettato.
Quindi, avere una finestra da un processo eseguito come WM_TIMER sul desktop di un utente con privilegi limitati offre comunque a quell'utente l'opportunità di elevare i privilegi?