La sessione inizia con un'interessante considerazione: l'unica metrica che è stata trovata valida per giudicare il numero di vulnerabilità è l'età del codice, tanto più vecchio quanti più security bug.
I risultati sono valutabili da tutti per numero di bollettini di sicurezza che sono diminuiti in modo sostanziale. Molte vulnerabilità sono state evitate applicando semplicemente il processo SDL: per esempio evitando di installare per default componenti che hanno dimostrato di avere delle vulnerabilità. Sembra un esempio sciocco ma quando parliamo di milioni di installazioni, fa certamente una grossa differenza. Altri bug eliminati semplicemente per aver ricompilato il codice con VC++2008 che implementa nuovi controlli su over/underflwow aritmetici.
Tra le altre novità del compilatore, oggi il compilatore esegue strategie più sofisticate rispetto a quelle ghià presenti in VC++2005, infatti i buffer nello stack sono stati mossi in modo da evitare attacchi che possono sovrascrivere le variabili e lo stack degli indirizzi di ritorno.
Su 82% dei buffer overrun potenzialmente sfruttabili, 1/3 sono rimossi grazie a SAL e la metà semplicemente con il banning delle API considerate pericolose. Solo due delle prescrizioni indicate da SDL.
Tra i tanti argomenti presentati ci sono:
- Uso estensivo di SAL, un linguaggio di annotazione (in pratica dei metadati da aggiungere al codce C++), che permette al compilatore di riconoscere errori che possono diventare vulnerabilità di sicurezza.
- Data Execution Prevention controllabile per-processo, presto disponibile anche per IE che attualmente non lo supporta.
- Service Hardening. La cosa più notevole è l'ACL creata al volo per ogni specifico servizio a prescindere dalle credenziali usate per avviarlo. Questo permette di restringere l'uso di un oggetto al solo servizio. Per esempio solo il servizio DHCP può accedere al suo database a prescindere dal fatto che sia avviato come network service come tanti altri servizi.
- ASLR (Address randomization) che è il motivo per cui la demo sul buffer overflow che ho realizzato per WPC non ho potuto utilizzarla sotto Vista. In pratica ci sono 256 possibili locazioni in cui le DLL possono essere caricate (viene deciso al boot) e quidi l'indirizzo delle funzioni "note" dell'applicazione o delle librerie non è più fisso come prima. Questo è anche il motivo per cui in Windows Server 2008 i servizi dopo il secondo crash non ripartono più. Se ripartissero, un attacco di overrun potrebbe cercare di indovinare (lo indovinerebbero sicuramente con un massimo di256 tentativi) l'indirizzo della funzione da attaccare.
A mia domanda Michael mi tranquillizza: sono stati aggiunti dei metadati per permettere il debug e l'analisi del crash dump. Se non fosse stato possibile riconciliare gli indirizzi con i crash dump, non sarebbe mai stato possibile aggiungere questa feature. - Nuove difese per la corruzione dello heap come l'overflow sulle new
