viklog

In ritardo di più di una settimana ecco a voi il secondo episodio della serie Vista features, episodio in cui vi parlerò di ASLR: Address Space Load Randomization.

L’argomento, però, richiede alcune conoscenze più o meno tecniche, come il funzionamento della memoria centrale (la RAM) per poi arrivare al “mitico” buffer overflow. Cercherò anche in questo caso di colmare un po’ di lacune in maniera breve e davvero semplice. Chi conosce già l’argomento salti direttamente a Obiettivi di ASLR.

La RAM

La RAM (Random Access Memory) è la memoria centrale del nostro PC, dove vengono caricati i programmi per essere eseguiti. Il primo requisito della RAM è che l’accesso ai dati presenti al suo interno sia velocissimo: se al Sistema Operativo interessa una certa informazione deve poter accedere direttamente a essa, senza dover scorrerne altre mille prima di trovare quella richiesta. Per adempire al suo dovere la RAM è divisa in “celle” di dimensione prefissata, solitamente 512 byte. Ognuna di queste celle ha un indirizzo (indirizzo di memoria), grazie al quale è possibile alla CPU raggiungere direttamente quella cella. Per cui nella RAM troviamo diversi applicativi, ognuno dei quali è salvato in una o più celle e l’accesso ai dati di una singola cella è diretto. Immaginate la RAM come una lunghissima via, dove ogni cella ha un proprio numero civico. Se, per arrivare al numero 1042 dovessimo scorrere tutti i portoni precedenti la velocità di un PC sarebbe l’1% di quella attuale. Invece ogni numero civico è raggiungibile in maniera semplice perché il “postino” sa quanti metri (o kilometri) deve saltare per arrivare direttamente al 1042.

Nell’esempio Firefox ha indirizzo di memoria 00000003 e occupa 2 celle, mentre Messenger ha indirizzo 0000FFFE e occupa 4 celle. Gli indirizzi normalmente sono espressi in esadecimale per poterli mantenere in forma compatta. In realtà, di solito in alto si trovano gli indirizzi più elevati e in basso quelli minori, io ho invertito per comodità di rappresentazione.

Buffer Overflow

Buffer overflow (in breve BOF) letteralmente significa “trabocco del buffer”. Cosa succede: un programma riceve in input una quantità di dati superiori a quelli attesi. Ora, se il programma implementa un controllo dell’input probabilmente verrà semplicemente sollevato un errore. Se questo controllo non c’è, o non è ben strutturato, allora si incappa proprio in un buffer overflow. Per cui il risaltato è che questi dati in eccesso possono finire in zone della memoria dove sono presenti altri dati sovrascrivendoli: questo è il primo passo verso un attacco. Ovviamente esistono diverse forme di questo tipo di exploit, ma non starò qui a divulgarmi. E’ sufficiente capire che in questo modo è possibile inserire del codice maligno all’interno del nostro sistema e farlo eseguire.

Obbiettivi di ASLR

Ammettendo che un programmatore mal intenzionato sia riuscito a individuare delle vulnerabilità sfruttabili attraverso un attacco di tipo buffer overflow, il malware da esso scritto ha bisogno delle librerie di Windows (Windows API) per potersi insidiare in maniera (più o meno) permanente all’interno della macchina. Il fatto che, queste librerie, avevano un indirizzo in memoria più o meno fisso in ambiente XP, ha sempre permesso agli attaccanti alcune assunzioni sull’indirizzo stesso. L’obiettivo di ASLR è proprio quello di rendere difficile la localizzazione delle Windows API in una maniera molto semplice: caricando le DLL di sistema ed eseguibili annessi, a indirizzi diversi ad ogni avvio.

Soluzioni implementate

All’avvio tutti processi dell’utente vengono allocati in memoria a partire da un certo indirizzo. Mentre con l’introduzione di ASLR l’indirizzo di partenza viene scelto in maniera casuale fra 256 possibili indirizzi all’interno dei primi 16 MB assegnati all’utente. Per quanto riguarda le librerie di sistema il meccanismo è lo stesso: c’è un indirizzo di partenza che si trova nella parte “bassa” della memoria, le librerie vengono allocate dal basso verso l’alto e il reale indirizzo di partenza è scelto all’interno dei 16 MB precedenti all’indirizzo di partenza prestabilito. Se questo non bastasse, le varie DLL di sistema conosciute vengono allocate in ordine casuale. Infine, ci sono altri componenti della memoria il cui indirizzo viene scelta in maniere più o meno casuale, e sono:

• l’User stack, dove risiedono le strutture dati relative ai processi dell’utente;
• i driver dei vari dispositivi;
• (persino) l’immagine del kernel.

Quello che succede si vede bene nella prossima immagine:

Due PC in cui è presente Windows XP hanno immagine di memoria praticamente uguale. Questo implica due cose: la prima è che nell’implementare un attacco di tipo buffer overflow, il programmatore può fare diverse ipotesi a priori sugli indirizzi da colpire. La seconda cosa è che un attacco riuscito su una macchina, facilmente funzionerà anche sulla seconda, ovvero in una rete di computer si può puntare a colpire diverse macchine.

Mentre i due computer con Vista, non solo hanno i vari processi o servizi shiftati uno rispetto all’altro, ma l’ordine delle componenti fondamentali del sistema è anche esso diverso.

Vedere ASLR in azione

Per vedere ASLR in azione sul proprio PC è necessario Process Explorer (chi ha Vista deve assolutamente averlo!), una evoluzione del classico Task Manager di Windows. E’ sufficiente guardare l’indirizzo di memoria di una DLL, ad esempio kernel32.dell e verificare che alla prossima sessione quell’indirizzo sarà diverso. Nel mio caso prima era 0×77c10000, al successivo riavvio era 0×770f0000.

Conclusioni

Ci sarebbe ancora molto da dire su ASLR e sulla sua implementazione. Ad esempio nel mio articolo non ho fatto alcuna differenza fra la memoria virtuale e quella reale: il mapping degli indirizzi di memoria dal “punto di vista del Sistema Operativo” nella reale memoria hardware non è così semplice che può apparire leggendo questo articolo. Andare al fondo dell’argomento, però, avrebbe reso il post una guida di programmazione C/C++/.Net, cosa che non mi interessa. Inoltre trovare materiale su ASLR si è rilevato più difficile di quanto mi aspettassi, in italiano c’è il nulla.

Concluderei con due note:

1. Questo meccanismo per la protezione dalle vulnerabilità di tipo buffer overflow è già stato implementato nel kernel Linux da diversi anni. Questo, a mio avviso, non sminuisce lo sforzo implementativo della Microsoft.
2. ASLR non risolve il problema ma rende il compito decisamente più difficile all’attaccante.

Link sull’argomento

• Attacchi alle applicazioni basate su Buffer Overflow | InTiLinu, in questo articolo viene spiegato in maniera davvero efficace e comprensibile a tutti che cosa è un BOF.
• Random Access Memory su Wikipedia.
• Address Space Layout Randomization in Windows Vista, dal blog di un personaggio autorevole sull’argomento!
• Funny Vista Tricks with ASLR, per chi vuole mettere le mani in pasta in ASLR

Vi saluto, ci vediamo fra qualche tempo per l’Episodio 3.

– Warning: Divide by zero.

Technorati tag: Vista, Vista features, ASLR, Address Space Load Randomization, RAM, memoria, informatica, rubriche

Popularity: 23% [?]