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