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% [?]

UAC (User Account Control) è sicuramente la feature più discussa e fischiata di Windows Vista, forse semplicemente perché la più evidente all’utente finale. Cercherò di fare un po’ di luce sul misterioso UAC, cercando di essere il più semplice possibile.

Obiettivi di UAC

L’obiettivo di UAC è uno e “semplice”: distinguere l’utente amministratore (Administrator, o in breve Admin) dagli utenti normali (Standar User), distinzione che non è mai realmente esistita nei sistemi operativi Microsoft precedenti. L’utente administrator è quell’utente che ha tutti i privilegi sulla macchina: può installare e disinstallare applicativi, aggiornare il sistema, modificare le chiavi di registro, etc etc. Insomma è quell’utente che potenzialmente può danneggiare il sistema. Un utente normale, invece, può solo utilizzare gli applicativi già presenti nel sistema, può creare ed eliminare file (tranne in alcune cartelle sensibili, come C:\Windows). In pratica è un utente che difficilmente può danneggiare il sistema. Ad esempio, non può accidentalmente installare un virus in quanto non può installare nessun programma. Comunque sia, gli Standard User possono acquisire i privilegi di Amdin per una singola operazione o per un certo periodo di tempo: questa funzione si chiama elevetion, un utente normale viene elevato a utente amministratore. Ovviamente, per effettuare l’elevation vengono richieste le credenziali (nei sistemi desktop, la password) di Admin altrimenti avrebbe poco senso.

Problemi da affrontare

Il passaggio da un sistema come Windows XP, in cui tutti gli utenti sono amministratori, ad uno come Vista (o Linux o MacOS X…), in cui alcuni utenti hanno un limitato numero di privilegi, implica diverse problematiche. In primo luogo bisogna rimuovere le ragioni per cui un utente debba spesso richiedere l’elevazione. Secondo problema è quello di rendere possibile alla maggior parte delle applicazioni di funzionare con privilegi di utente normale. Infine, bisogna incoraggiare le Software House a scrivere programmi che non richiedano i privilegi di amministratore per ogni sciocchezza.

Soluzioni implementate

La maggior parte delle applicazioni potrebbero funzionare con privilegi normali, ma necessitano di poter scrivere dati a run time utili all’utente in alcune parti del file system utilizzabili solo dal sistema (come C:\Program Files) e che richiedono, quindi, i privilegi di Admin per la scrittura. Per venir incontro a questi applicativi, normalmente scritti per Windows XP o sistemi precedenti e dette Legacy Application, in Vista è stata implementata una virtualizzazione del File System.

Virtualizzazione

In pratica le modifiche operate in cartelle del sitema vengono ridirette nella cartella di profilo utente, dove uno Standard User ha pieni diritti di lettura e scrittura. Le cartelle in cui è attiva la virtualizzazione sono: %ProgramFiles% e(solitamente C:\Program Files), %AllUsersProfile% (quello che in XP era C:\Documents and Settings\AllUsers), %SystemRoot% (C:\Windows), %SystemRoot%\System32 (C:\Windows\System32). Quindi, tutte le operazioni di scrittura svolte in queste cartelle vengono in realtà effettuate nella cartella %UserProfile%\AppData\Local\VirtualStore. Questa virtualizzazione è implementata da un serivzio di Vista denominato File System filter driver. Si chiama così semplicemente perché si tratta di un vero e proprio driver e perché filtra tutte le richieste effettuate al gestore del File System.

Facciamo un esempio¹: ci sono due programmi, uno realizzato per Windows XP (abbiamo detto Legacy Application) e uno scritto per Vista (che chiameremo, banalmente, Vista application) che vogliono scrivere all’interno del file App.ini presente nella cartella Windows. Entrambi questi applicativi sono stati lanciati da uno Standard User. Le richieste vengo filtrate dal Filtrer Driver: per quanto riguarda la Legacy Application, la richiesta viene ridiretta in …\VirtualStore\Windows\App.ini senza che l’applicazione percepisca alcuna differenza. Per la Vista application, invece, la virtualizzazione non è attiva: la richiesta arriva inalterata al gestore del File System che restituirà un errore: accesso negato.

Come si distingue una Legacy application da una Vista application?

Da un file MANIFEST, ovvero un banale file xml presente all’interno del file exe stesso. Se il MANIFEST è presente e ben strutturato, l’applicazione è Vista-ready e la virtualizzazione non viene attivata. Viceversa, con MANIFEST assente², la virtualizzazione è attiva.

Per verificare se su di un processo della propria macchina è attiva la virtualizzazione è sufficiente aprire Gestione attività Windows premendo CTRL+ALT+CANC (il vecchio Task Manager) e quindi spostarsi nel tab processi. Cliccare sul menu Visualizza e scegliere Seleziona colonne e infine spuntare Virtualizzazione. Si nota immediatamente che è possibile abilitare/disabilitare la virtualizzazione per ogni singolo processo.

Elevation

Cosa accade quando un processo richiede l’elevazione?

Ecco il fatidico prompt tanto criticato. Non tutte le richieste, ovviamente, sono uguali e si distinguono dal colore che assume la finestra sopra mostrata:

• se la finestra è blu, allora si tratta di un applicativo facente parte di Vista stesso oppure un programma atto alla protezione del sistema (antivirus, antispyware, …), come nell’immagine: non ci dovrebbero esser problemi;
• se la finestra è grigia allora si tratta di un applicativo di terze parti ma conosciuto: ancora una volta non ci dovrebbero essere problemi;
• se la finestra è arancione allora l’applicativo è sconosciuto: bisogna essere sicuri di quello che si fa prima di cliccare su “Continua”.

Integrity Level e UIPI

In tutti i Sistemi Operativi moderni (anche non troppo moderni) ogni processo è identificato univocamente da un Id detto PID (Process ID). In Vista questo Id ha un campo chiamato Integrety Level che mantiene il “livello di privilegi” del processo³. Esistono quattro livelli:

• System, assegnato soltanto ai processi e servizi del sistema locale;
• High, il processo è stato elevato;
• Medium, tutti gli altri processi;
• Low, per adesso usato in un solo caso che consideremo dopo.

Un altro problema è che processi con IL pari a Normal potrebbero comunicare con altri che anno IL pari ad High: un processo mal intenzionato potrebbe demandare azioni a lui non concesse ad un altro processo elevato, questo ultimo magari ignaro del fine della richiesta⁴. Per evitare questo tipo di attacchi, in Vista sono presenti delle librerie denominate UIPI (User Interface Privilege Isolation) che hanno il compito di isolare i processi con privilegi pericolosi, in modo che quelli con privilegi standard non possano comunicare con essi. Un esempio di questa funzione si può vedere sulla propria macchina. Tutti dovrebbero sapere che se si trascina un file di testo (txt) da una cartella qualsiasi all’interno del Blocco Note, questo ultimo aprirà il file. Bene: provate a fare questa operazione dopo aver lanciato il Blocco Note con i privilegi di amministratore (è sufficiente cliccare sul destro sull’icona del blocco note e scegliere ). Il Blocco Note non apre proprio un bel nulla… sorpresi? Questo accade perché la Shell di Windows ha IL pari a Normal, per cui non può passare informazioni al blocco note, il quale ha - in questa occasione - IL pari ad High. E pensare che, a lungo, questo “giochino” veniva confuso con un bug di Vista.

IE in Security Mode

Prima dicevo che c’è solo un processo che viene eseguito con Integrity Level pari a Low. Si tratta di Internet Exploer in Security Mode. In questo modo il browser – sicuramente uno dei pezzi più attaccati in tutti i Sistemi Operativi – non può comunicare direttamente con nessun altro processo presente nel proprio Sistema Operativo. Anche tutti i processi (e operazioni varie) che IE lancia hanno IL minimo: in questo modo ogni tentativo di danneggiare il sistema sarà evidente perché richiederà l’intervento dell’utente. Qui molti storceranno il naso: il rischio (concreto) è che l’utente o l’amministratore siano bombardati di richieste.

Un unico utente

Nel 90% dei casi Vista è configurato con unico utente con i privilegi di Administrator. Affinché il controllo di UAC abbia comunque senso anche in questo caso, i processi lanciati da esso hanno comunque Integrity Level pari a Medium, salvo esplicita richiesta. Dunque, anche nel caso di utente con pieni privilegi su quella macchina, i processi da lui lanciati normalmente devono comunque richiedere l’elevation attraverso il prompt visto precedentemente. La differenza sta nel fatto che non sarà richiesta alcuna password per confermare le proprie credenziali, sempre come è visibile nell’immagine precedente.

[UPDATE] Paperino mi ha fatto notare un imprecisione in questo passaggio: leggi il commento.

L’idea che sta alla base di questo meccanismo è fondamentalmente la stessa su cui si basa il sudo di Ubuntu, anche se poi tecnicamente l’implementazione è nettamente diversa.

Virtualizzazione dei registri

Esiste qualcosa di simile alla virtualizzazione del File System anche per i registri di sistema. Ancora una volta le modifiche effettuate a chiavi di registro vengono ridirette in luoghi sicuri se la virtualizzazione è attiva oppure viene restituito un errore se è disattiva. In questo caso non sarà un Filter Driver ad occuparsene, ma direttamente un processo del kernel di Vista.

Lo Standard User può qualcosa in più

Non so quanti di voi hanno mai attivato l’utente Guest in XP: questo poverino poteva a malapena accendere il PC.

Per questo, alcune operazioni eseguibili solo da Admin in XP sono ora accessibili anche agli Standar User. Alcune di queste operazioni sono:

• configurare il sistema per connettersi a reti protette da WEP (non so per la WPA, sinceramente);
• modificare le impostazioni di risparmio energetico;
• creare e configurare una rete VPN (Virtual Private Network);
• installare aggiornamenti critici del sistema con Windows Update;
• …

Conclusioni

In parte capisco le critiche mosse verso UAC che può apparire paranoico. Ma d’altra parte mi pare che nessun utente Ubuntu (o Linux in generale) si sia mai lamentato di dover inserire la password per effettuare certe operazioni (sudo). Inoltre, dopo qualche settimana di utilizzo, le richieste di UAC caleranno notevolmente, tranne per le operazioni di configurazione del sistema. L’unica critica che mi sento di muovere è la richiesta di privelgi di Admin per copiare un file su un hard disk esterno, cosa che mi pare un po’ assurda.

Un ultima nota interessante: sempre al NSS07 Luca Sanson, rispondendo a una domanda, ha dichiarato che UAC più che una vera e proprio feature di sicurezza è uno strumento per accompagnare il passaggio da un sistema “solo amministratori” a uno veramente Multiuser, fino a che le Software House non scriveranno applicativi come Dio comanda per Windows. A suo avviso questo passaggio richiederà una decina di anni e, alla fine di questi, la Microsoft sarà pronta per far uscire un nuovo Sistema Operativo.

Links sull’argomento

• La virtualizzazione dei file e del registry di Vista
• [UPDATE] User Account Control Overview (Official Microsoft TechNet)
• UAC su Wikipedia (EN)
• Visual Studio 2008 e i manifesti per Windows Vista
• Avviare automaticamente un eseguibile con privilegi amministrativi sotto Windows Vista

- Warning: Divide by zero.

[1] L’esempio è liberamente ispirato dalle slide del talk di Luca Sanson al NSS07. Torna su
[2] In realtà la tecnica del file MANIFEST esiste già da molto tempo, ma in Vista sono state introdotti alcuni nuovi campi riguardanti il controllo degli accessi. Torna su
[3] Non solo ai processi è associato un IL, ma a tutti gli oggetti presenti nella memoria. Torna su
[4] Lo so che i processi non sono essere senzienti, ma era la maniera più semplice per spiegare il particolare scenario che si può verificare. Torna su

Technorati tag: Vista, Vista features, UAC, virtualizzazione, Security Mode

Popularity: 20% [?]

Ultimamente ho avuto di nuovo a che fare con Vista. È così che mi sono deciso di indagare un po’ di più su le famose e discusse feature di sicurezza implementate nel kernel dell’ultimo sistema operativo di casa Microsoft. Ora, come persona informata sui fatti non posso proprio più tollerare articoli come Non illudetevi, Windows Vista è sicuro come Windows 95!. Possiamo non essere d’accordo su molte scelte della Microsoft, come sul costo delle licenze di Vista: sottoscrivo a pieno. Ma dal punto di vista della sicurezza non c’è proprio confronto fra Vista e i precedenti sistemi operativi Windows.

Dopo aver seguito il talk di Luca Sanson al Net&System Security di questo anno, ho deciso di fare un po’ di luce su alcune di queste feauture. Gli episodi avranno frequenza settimanale (credo: si avvicina la sessione d’esame), nella discussione utilizzerò un linguaggio il più semplice possibile, evitando tecnicismi (comunque, in ogni episodio inserirò anche link ad articoli che approfondiscono l’argomento).

Per l’occasione ho anche creato una categoria dal nome (banalmente) Vista features. Nell’episodio 1 parleremo un po’ di UAC. Bye!

- Warning: Divide by zero.

Technorati tag: Vista, Vista features

==
Crediti immagine: Windows Vista Ultimate Packaging Opened by sixs†eps

Popularity: 17% [?]