A distanza di alcuni giorni dalla scoperta della vulnerabilità identificata da Microsoft con il bollettino MS08-067 e di cui ne avevo parlato già nel precedente post, torno sull’argomento per chiarire alcuni punti non chiari tra molti utenti online.

La domanda che più volte ho letto e che mi è stata anche rivolta da più persone è stata: “pur essendo vulnerabile il servizio, non dovrei comunque essere al sicuro grazie all’hardware enforced DEP?“.

La risposta semplice e diretta è: non completamente. Tuttavia vediamo di argomentare meglio.

La tecnologia DEP (Data Execution Prevention) è una tecnologia di sicurezza implementata da Microsoft a partire dagli ultimi sistemi operativi (Windows XP SP2 in poi) che si prefigge come scopo – detto in maniera molto semplice – la prevenzione degli attacchi causati da buffer overflow, stack overflow, heap overflow e figli.

Come funziona logicamente? Il meccanismo alla base di questa tecnologia è molto semplice: tutte le zone di memoria in un processo adibite ai dati (stack, heap…), e dunque non a codice eseguibile, non dovrebbero contenere alcun codice eseguibile e, come tali, niente da quelle zone di memoria dovrebbe venir mai eseguito.

Dunque, attraverso un bit settato (denominato NX bit o XD bit) e grazie a CPU compatibili con questa tecnologia, la funzionalità DEP previene l’esecuzione di codice iniettato attraverso buffer overflow.

Sto ovviamente parlando di hardware enforced DEP, cioè della tecnologia DEP supportata da un processore compatibile con questa tecnologia. Per maggiori informazioni sulla tecnologia DEP è possibile leggere le dettagliatissime spiegazioni fornite da Microsoft qui.

Sappiamo che l’exploit MS08-067 sfrutta la vulnerabilità in una funzione esportata dalla libreria netapi32.dll causando uno stack buffer overflow grazie al quale viene iniettato del codice arbitrario. Allora, teoricamente, l’hardware enforced DEP dovrebbe prevenire questo attacco, bloccando l’esecuzione del codice iniettato. Giusto? Non è totalmente esatto.

L’hardware enforced DEP ha quattro modalità di configurazione: AlwaysOff, OptIn, OptOut, AlwaysOn.

AlwaysOff disattiva completamente la tecnologia DEP per qualunque processo. AlwaysOn invece attiva il controllo su tutti i processi, in maniera indiscriminata.

OptIn e OptOut sono, tuttavia, le configurazioni di cui andiamo a parlare. Sono, infatti le configurazioni di default. In Windows XP SP2 la configurazione di default del DEP è OptIn, mentre in Windows Server 2003 la configurazione di default è OptOut.

Il settaggio OptIn attiva la configurazione solo per alcuni file di sistema di Windows. Il settaggio OptOut, invece, abilita il DEP per tutti i processi eccetto quelli esclusi dall’utente.

In entrambe le configurazioni, sia OptIn che OptOut, tuttavia, Microsoft ha messo a disposizione la possibilità di disabilitare il DEP a seconda del processo.

In parole più semplici: se il DEP è configurato in modalità OptIn o OptOut, qualunque file eseguibile può arbitrariamente decidere di disabilitare il controllo DEP sul proprio processo.

Microsoft ha messo a disposizione una funzione in Windows XP denominata DisableNX e presente nella libreria AcGenral.dll che permette la disabilitazione arbitraria del controllo DEP sul processo da cui la funzione viene eseguita. La funzione è stata messa a disposizione da Microsoft per problemi di compatibilità dei programmi.

Win32 API used to disable DEP

Cosa c’entra tutto ciò con l’exploit? È possibile, sfruttando correttamente la vulnerabilità e gestendo lo stack overflow in maniera adeguata, chiamare questa funzione in modo tale che, per il processo colpito, venga disabilitato il controllo DEP. Di conseguenza, una volta disabilitato, la strada per il payload vero e proprio è del tutto spianata.

Questa tecnica di attacco dell’hardware enforced DEP è ormai conosciuta da diverso tempo e rappresenta il tallone di Achille di questa tecnologia che, altrimenti, risulta particolarmente efficace. Tallone di Achille che non è comunque intrinseco nella natura della tecnologia, bensì un effetto collaterale della scelta Microsoft di fornire la possibilità di disabilitare il controllo DEP per un processo dall’interno del processo stesso.

Tuttavia, per poter attuare correttamente questa tipologia di attacco, è necessario per l’eventuale attacker conoscere con esattezza l’indirizzo della funzione in questione. Questo è possibile nei sistemi operativi dove l’ASLR non è attivo di default.

Cos’è l’ASLR? L’Address Space Layout Randomization è una tecnica di sicurezza che prevede il caricamento di elementi quali librerie, stack, heap all’interno della zona di memoria dei processi ad indirizzi ogni volta differenti.

Nei sistemi quali Windows Vista e Windows Server 2008 la funzionalità ASLR è abilitata di default, mentre in Windows XP/2003 l’ASLR non è previsto.

Cosa significa tutto ciò? Mentre in Windows XP/2003 le librerie vengono caricate sempre allo stesso indirizzo nel range di memoria di ogni processo – e quindi la funzione sarà sempre individuabile ad uno specifico indirizzo – in Windows Vista/2008 ciò non è prevedibile a priori perché ad ogni avvio di sistema le librerie verranno caricate ad indirizzi differenti.

Ecco perché, mentre in Windows XP e 2003 l’exploit è in grado di poter funzionare anche con hardware enforced DEP attivato, in Windows Vista/2008 – essendo presente sia il DEP attivato (in settaggio OptIn) che l’ASLR, tutto diviene più complesso e molto difficile (a questo andrebbero aggiunte anche le altre tecnologie di sicurezza integrate in Vista, tra cui l’UAC, che mitigano l’exploit. Tuttavia queste non erano immediatamente indispensabili per la spiegazione di questo post).

Quindi, chi si sentisse al sicuro con l’hardware enforced DEP attivato in sistemi operativi Windows non predisposti per l’ASLR (Windows XP principalmente), dovrebbe tenere in considerazione che – in configurazione OptIn e OptOut – la protezione potrebbe venire disabilitata.