A Ovest Di Paperino

Interessante analisi sui cursori mannari

Tempo fa mi ero ripromesso di capire come sia stato possibile creare un exploit funzionante via "cursori mannari".

Michael Howard, in un nuovo blog dedicato al Security Development Lifecycle, spiega come molte delle nuove protezioni in Vista siano state bypassate in un sol colpo.

flag GS. Il flag GS è stato semplicemente bypassato per via di un'euristica sbagliata. Il pezzo di codice incriminato non ha parametri in ingresso e non è stato correttamente individuato come possibile fonte di buffer overrun. Cambiare le euristiche non è semplice: nel frattempo è stata aggiunta un'ulteriore direttiva pragma per rendere il compilatore più agressivo nella distribuzione di canary
ASLR. ASLR è stato bypassato in quanto il codice bacato è racchiuso in un try...catch in cui la filter expression era un po' troppo generica.
Il codice maligno ha perció avuto la possibilità di tentare tutte le combinazioni necessarie senza che l'applicazione andasse in crash
SAL. Annotare con SAL il pezzo di codice in questione era praticamente impossibile in quanto il buffer è passato in una struttura passata per reference
Banned API: memcpy - a differenza di API come strcpy che sono state eliminate dal runtime e cioé se usate nel codice producono errori di compilazione - non è considerata una banned API per due motivi; il primo è che dal punto di vista teorico non tutte le implicazioni sono ancora ben chiare (e questo va aldilà della singola piattaforma); il secondo - dal punto di vista pratico - è che mettere memcpy nell'elenco delle banned API potrebbe far saltare fuori troppi falsi positivi. Fino a quando le implicazioni teoriche non sono chiare, ha poco senso.
Fuzz Testing: per fuzz testing si intende il dare in pasto dati spazzatura a pezzi di codice per analizzarne gli effetti. Nel caso dei cursori mannari il baco si riproduce creando una seconda copia di un pezzo di header, cosa che il tool per la generazione di fuzz data non prevedeva. Il tool è stato già aggiornato ed ora prevede la duplicazione di elementi

Su Vista, come già fatto notare, il protected mode di IE7 è ciò che ha bloccato l'exploit da avere effetti micidiali.

Tutte queste condizioni a contorno, risultate vere per il baco in questione, fanno capire quanto sia diventato difficile trovare un baco che sia pienamente sfruttabile in Vista. Concludo con le parole di Michael Howard:

In summary, SDL is not perfect, nor will it ever ever be perfect. We still have work to do, and this bug shows that. We have a new -GS pragma that adds more stack cookies; we’ve updated our fuzz tools; we will pay closer attention to exception handlers that could mask vulnerabilities, and we will investigate the impact of banning memcpy for new code. Finally, we will update our education as necessary with lessons learned from this bug.

-quack

Technorati tags: Security, Vista

Pubblicato giovedì 3 maggio 2007 alle 5:10 PM - Archiviato in: Vista, Security.
Condividi su: Facebook, Wikio, Segnalo.

Commenti (2):

1. amok
giovedì 3 maggio 2007 alle 8:10 PM - unknown unknown

Eccellente riassunto! Aggiungerei che l'intrinsico problema che ha dato una non merita ventata negativa all'ottima sicurezza di Vista e' il fatto che alcuni grossi e complicati pezzi di codice di Windows sono funzionanti e vecchi come il colosseo. Talmente vecchi che nessun tool di analisi statica sara' mai in grado di analizzarli per security exploits. Principalmente perche' ai tempi in cui furono scritti le performance e le tempestiche erano i padroni del forziere. La sicurezza informatica era ancora percepita ancora come un plus invece che un fondamento del ciclo di sviluppo come e' accaduto nel caso di SQL Server e di Vista. Linux e cuginastri in fatto di sicurezza possono solo imparare dagli sforzi fatti dal draga saccocce. Vista e' l'unica piattaforma al mondo totalmente usabile e sicura. Al contrario di altre che sono riservate per poche centinaia di eletti per mantenerle sicure.

Permalink