Ricerca in FOLBlog

DEP e BCD (Backward Compatibility Disaster)

 Scritto da alle 00:15 del 02/03/2009  Aggiungi commenti
Mar 022009
 
closeQuesto articolo è stato pubblicato 8 anni 5 mesi 23 giorni giorni fa quindi alcuni contenuti o informazioni presenti in esso potrebbero non essere più validi. Questo sito non è responsabile per eventuali errori causati da questo problema.

Una delle tecniche maggiormente utilizzate per sfruttare le vulnerabilità del software sono i cosiddetti attacchi buffer overflow.
Un buffer è una zona di memoria usata temporaneamente per l’input o l’output dei dati oppure per velocizzare l’esecuzione di alcune operazioni.
L’overflow del buffer si verifica quando un’applicazione tenta di memorizzare troppi dati in un buffer causando la sovrascrittura della memoria che eccede quella allocata per il buffer.
E ciò che accade quando si fa traboccare un recipiente già colmo tentando di aggiungere altra acqua.

Il malintenzionato autore di malware potrebbe essere in grado di indurre intenzionalmente l’overflow del buffer, per poter inserire codice malevolo in quella parte di memoria che eccede lo spazio allocato per il buffer; in questo modo è possibile determinare l’esecuzione, da parte del sistema operativo, di codice dannoso.

In Windows Vista (e XP a partire da SP2) è presente una funzionalità, il Data Execution Prevention (DEP, Protezione Esecuzione programmi in italiano), in grado di proteggere da questo tipo di attacchi, che in passato (vedi worm CodeRed) ha fatto dei veri disastri.
DEP contrassegna le zone di memoria indicandone il contenuto (codice eseguibile o dati) ed evitando, in questo modo, che il sistema operativo possa eseguire il contenuto di una zona di memoria che è stata contrassegnata come contenente dati, interpretandolo come codice.

Windows Vista 32bit contiene un’implementazione software di DEP, mentre la versione a 64bit sfrutta le funzionalità di DEP incorporate nei processori a 64bit, imponendo così la protezione a livello hardware, molto più difficile da aggirare.
Questo è uno dei motivi che mi fa affermare che Windows Vista 64bit è più sicuro di Windows Vista 32bit.

Per impostazione predefinita, DEP protegge solo le applicazioni ed i servizi principali di Windows.
Per quale motivo?
Backward compatibility, cioè per garantire la massima retro-compatibilità con le applicazioni datate o foot written.

Fortunatamente è possibile abilitare DEP per tutte le applicazioni (anche se il percorso per arrivarci è tortuoso e per nulla intuitivo):

Pannello di controllo –> Sistema e manutenzione –> Sistema –> Impostazioni di sistema avanzate
Impostazioni di sistema avanzate
nel riquadro Prestazioni (?) premere sul pulsante Impostazioni e da lì selezionare poi la scheda Protezione esecuzione programmi
Protezione esecuzione programmi
Com’è possibile notare, si può attivare DEP per tutte le applicazioni e gestire le eccezioni per quelle applicazioni che dovessero soffrire dell’attivazione di questa funzione.
Inoltre in basso è presente una nota che indica se il processore che si sta utilizzando supporta il DEP hardware.
Una volta modificata l’impostazione, sarà necessario riavviare il computer per rendere definitiva la modifica.

Il team di grc, ha realizzato una piccola applicazione, SecurAble, in grado di determinare quali features sono disponibili sulla piattaforma hardware in uso.
SecurAble

Con DEP abilitato per tutte le applicazioni, possiamo ritenerci al sicuro, almeno per quanto riguarda gli attacchi buffer overflow. Giusto?
Non proprio…

Prima di proseguire, occorre approfondire meglio in che modo è implementato DEP in Windows.
La configurazione della funzionalità Protezione esecuzione programmi per il sistema viene controllata mediante opzioni contenute nel file Boot.ini in Windows XP e tramite il comando BCDEDIT in Vista.

Le impostazioni del file Boot.ini hanno il seguente formato:
/noexecute=livello_criterio

mentre la sintassi da utilizzare in Vista con BCDEDIT (da eseguire in un prompt comandi con diritti di amministratore) è:
bcdedit.exe /set  nx livello_criterio

Sono supportati quattro configurazioni a livello di sistema per la Protezione esecuzione programmi applicata all’hardware e al software.

Configuraz.
Descrizione
OptIn Questa impostazione rappresenta la configurazione predefinita.
Nei sistemi con processori in grado di implementare DEP hardware, la funzionalità è attivata, per impostazione predefinita, per file binari di sistema limitati e per programmi in cui viene forzata.
Con questa opzione solo i file binari di sistema di Windows sono protetti dalla funzionalità.
OptOut In questo caso la funzionalità DEP è attivata per tutti i processi.
È possibile creare manualmente un elenco di programmi specifici a cui non viene applicata la funzionalità, come spiegato in precedenza.
AlwaysOn Questa impostazione fornisce la copertura completa della funzionalità DEP per l’intero sistema.
Tutti i processi vengono sempre eseguiti con la funzionalità applicata.
L’elenco delle eccezioni che esclude programmi specifici dalla protezione della funzionalità non è disponibile, come si può notare dal seguente snapshot.
Modalità AlwaysOn
AlwaysOff Questa impostazione disabilita completamente la funzionalità DEP, indipendentemente dal supporto della funzionalità applicato all’hardware

Quindi, è facile intuire che impostando (come descritto prima) DEP attiva per tutte le applicazioni e non inserendo alcuna eccezione, le due modalità AlwaysOn o OptOut producono gli stessi effetti.

E invece no!
Di recente Steve Gibson di grc.com, esperto in sicurezza, in uno dei suoi podcast Security Now (qui in forma testuale) ha segnalato che  IrfanView si rifiutava di funzionare in Windows XP se il DEP veniva abilitato in modalità AlwaysOn, mentre funzionava correttamente se si impostava in modalità OptOut pur non avendo specificato alcuna eccezione al riguardo.
Ma allora o IrfanView riesce in qualche modo ad aggirare DEP oppure OptOut non funziona come ci ha descritto Microsoft.

Quasi.
IrfanView è pacchettizzato con ASPack che comprime i file eseguibili (EXE, DLL, OCX,…) in modo che occupino il minor spazio possibile su hard disk.
L’intento è migliorarne le prestazioni: l’eseguibile viene decompresso in tempo reale al momento dell’esecuzione ed, essendo le CPU più veloci degli hard disk, questa operazione dovrebbe essere più rapida rispetto alla lettura di un numero maggiore di blocchi necessaria se il file non fosse compresso.
ASPack è utilizzato anche per altri programmi come Opera.

Microsoft sembra a volte fare scelte che appaiono stupide, ma che si spiegano con il necessario tributo che occorre pagare per la backward compatibility, ancora lei, cioè la retro compatibilità con vecchie applicazioni, ed anche con vecchi/strani/sbagliati modi di scrivere le applicazioni, a mio modo di vedere eccessivamente tollerati dalla società di Redmond.
ASPack non dovrebbe funzionare se DEP è attivo (come dimostra la modalità AlwaysOn), invece funziona nella modalità OptOut anche se non si inserisce alcuna eccezione perchè…è Microsoft stessa ad aver codificato questa eccezione all’interno della libreria C:\Windows\System32\ntdll.dll.
Esaminando la libreria incriminata tramite un editor esadecimale (ho usato Cygnus),
Eccezioni DEP in ntdll.dll?
… sembrerebbe che le eccezioni di questo tipo siano tre:

  1. aspack (ASPack)
  2. pcle (Pinnacle?)
  3. sforce (Star-Force)

Insomma Microsoft avrebbe avuto un atteggiamento di falltring (neologismo, anzi neoBlogismo, che ho ottenuto acronimizzando –mi sa tanto di neologismo pure questo termine 😉 -l’italianissimo adagio “Fatta la legge, trovato l’inganno”) rispetto a DEP, inserendo essa stessa un modo per aggirare la protezione?

Dovrebbe apparire chiaro a tutti che in questo modo, forse per evitare che alcune tra le più popolari applicazioni non funzionassero, si sarebbe deliberatamente inserita una vulnerabilità nella funzionalità DEP: sarebbe sufficiente pacchettizzare un’applicazione con ASPack per esser certi di essere in grado di aggirare DEP anche quando è eseguito in modalità OptOut.
Dovrebbe apparire chiaro a tutti quanto questo sia rischioso per applicazioni quali un’antivirus (es. Doctor Web) o un browser (Opera)

Per verificare quali applicazioni sono eseguite con DEP abilitata, è sufficiente aggiungere tramite il menù Visualizza di Gestione Attività (Task Manager) la colonna “Protezione esecuzione programmi”:

Nel mio PC, che esegue Vista 64bit, ho scelto di abilitare il DEP in modalità AlwaysOn (tanto per stare più sicuro).
Se qualche applicazione non funziona, suppongo che abbia qualcosa che non va e semplicemente non la uso.
Sul mio PC, ad esempio, è impossibile eseguire l’installazione di Google Chrome (mentre Iron si installa perfettamente) e Google Earth a partire dalla versione 5.
Gli installer semplicemente non si avviano.
Un motivo ci sarà.

Aggiornamento

Anche Safari si comporta in modo molto strano.
Con DEP in modalità AlwaysOn non si avvia. Ma a differenza degli installer di Google, il processo Safari.exe viene eseguito, ma l’interfaccia del browser non viene mostrata, ed il processo safari.exe resta lì, appeso, occupando una frazione della memoria (meno di 7MB) che occupa quando l’esecuzione avviene normalmente, fino a quando non lo termino manualmente.
E’ come se Safari.exe non fosse l’intera applicazione eseguita, ma che richiami un’altra parte dell’applicazione la cui esecuzione però, con DEP in AlwaysOn mode, viene impedita.
Impostando DEP in modalità OptOut, pur senza specificare alcuna eccezione, Safari riprende a funzionare regolarmente, come se la parte nascosta dell’applicazione rientrasse tra quelle eccezioni di cui ho parlato in precedenza.
La cosa che trovo sconcertante è che non sono riuscito, nemmeno utilizzando Process Explorer di Russinovich, che fornisce informazioni ben più dettagliate di Gestione Attività, ad individuare quale sia il processo, la dll, il servizio che Safari invoca senza riuscire ad eseguirlo quando DEP è in modalità AlwaysOn.
In sostanza sembra che la parte di applicazione che non viene eseguita in DEP AlwaysOn mode sia invisibile al sistema (come un rootkit).
Qualcuno ha una spiegazione per lo strano comportamento?

Conclusione
Microsoft sembra a volte cedere al silente ricatto dell’utenza e di alcune software house, forse per evitare di peggiorare la propria immagine presso l’utenza, già troppo volubile di per se’.
Cosa sarebbe successo infatti se, improvvisamente, dopo un aggiornamento di Windows, alcune delle più popolari applicazioni non fossero state in grado di essere eseguite a causa della protezione DEP?
Colpa della solita Microsoft si sarebbe detto in giro.
A mio parere, l’eccessiva avversione verso Microsoft da parte di molti utenti, spinge quest’ultima a scelte quanto meno discutibili, potenzialmente nocive per l’utente, il quale, senza avere competenze sufficienti per stabilire la vera motivazione del mancato funzionamento di una certa applicazione, sarebbe indotto ad incolpare Microsoft, anzichè fare pressioni sulla software house effettivamente responsabile del malfunzionamento.
Il FUD che sempre vien generato attorno a qualsiasi cosa faccia Microsoft farebbe da humus, da propulsore alle lamentele contro Microsoft.
Personalmente ritengo che l’atteggiamento di Microsoft sia controproducente e che dovrebbe avere più coraggio ed essere più intransigente nel pretendere che, chi sviluppa software per la sua piattaforma, lo faccia seguendo le più moderne linee guida, in termini di sicurezza soprattutto.
In particolare, occorrerebbe maggior coraggio nello spostare il trade-off tra retro compatibilità e maggior sicurezza in modo da privilegiare quest’ultima.
Spero che Windows 7 segni una svolta in questo senso.

Ispirazione

Technorati Tag: Vista,XP,


[1]
Sul mio PC on cui Vista 64bit è eseguito con DEP in modalità AlwaysOn, Opera funziona tranquillamente avendo DEP attivato.
Ciò sembra significare che l’ultima versione di ASPack è ora DEP compatibile, oppure che Opera usa un setup ASPack diverso da quello di IrfanView.

Articoli simili:

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

 Lascia un commento

Puoi usare questi tag e attributi HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(richiesto)

(richiesto)

Pinterest
EmailEmail
PrintPrint
%d blogger hanno fatto clic su Mi Piace per questo: