03 August 2007
Atsiv: attacco al kernel code signing di Vista ? Non proprio
Non so se avete letto questa notizia del tool australiano Atsiv: in ogni caso è importante che ve ne parli, sia per segnalarvi le iniziative che Microsoft ha rapidamente adottato in merito, sia per fare qualche riflessione, per così dire più filosofica, sugli aspetti di sicurezza. Questo tool permetterebbe di bypassare la policy Kernel Mode Code Signing (KMCS) della versione x64 di Windows Vista che intende caricare nel Kernel solo codice che sia stato firmato digitalmente con un valido certificato per il Code Signing. Gli articoli che ne hanno dato notizia l'hanno messa, chi più chi meno, nella solita forma "pro-Microsoft": trovato il modo per aggirare la funzionalità di sicurezza, buco in Vista, e cosi via...
Con parole semplici, come funziona il tool Atsiv ? Primo passo: installa dei driver firmati. Chi può installare driver ? Solo un amministratore. Sapete già dove vado a parare, visto che abbiamo già toccato l'argomento:
l'azione esplicita di un amministratore di installare del software a sua discrezione può essere considerata un buco di sicurezza del sistema operativo, secondo gli attuali modelli informatici ?
Io non credo proprio.
Ho poi sottolineato che i driver sono firmati: in quanto tali vi sembra che la policy di Vista x64 sia stata aggirata ? No. Secondo passo: questi driver caricano il proprio loader che è in grado di caricare quello che vuole, e quindi anche driver non firmati, e di farlo anche in modo che si nascondano alla rilevazione da parte dei tool. Come interpretate questo comportamento così descritto ? Se ci fate caso è la tipica descrizione di un trojan che si installa come rootkit. E' per questo che Microsoft è corsa ai ripari e già ieri, 2 agosto, ha classificato questo tool come potenziale spyware in Windows Defender, a concordare con Verisign la revoca del relativo certificato e a valutare se aggiungere tale chiave revocata anche alla lista di revoca propria del meccanismo KMCS: vi consiglio la lettura del post su Windows Vista Security con valutazioni e dettagli. Quali sono le riflessioni "filosofiche" di cui vi dicevo ? Intanto la considerazione del precedente paragrafo rientrato: un limite oggettivo del modello degli attuali sistemi operativi è che la sicurezza del sistema si appoggia su un set di codice di base che sia considerato sicuro e affidabile (Trusted) al tempo 0, il cosiddetto TCB. Dal momento che l'amministratore ha autorità di estendere il TCB con codice arbitrario, può di fatto invalidare tutta la sicurezza del sistema, fine. In che cosa cerca di migliorare questo modello la policy KMCS ? Estendere la funzionalità Authenticode a tutto il codice da caricare nel kernel significa solo aumentare l'identificazione di chi ha scritto il codice che sta entrando nel Kernel e quindi nel TCB. Ma se non si trova un modo per poter certificare e valutare la qualità e l'affidabilità del codice che estende il TCP, non aiutiamo l'utente amministratore nelle sue valutazioni costringendolo ad essere l'anello debole della sicurezza dei suoi sistemi, come dice con ragione Larry Seltzer che chiude l'articolo di eWeek su Atsiv dicendo "the most important security device is the one sitting at the keyboard".
Comment Notification
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using
Comment Policy: No HTML allowed. URIs and line breaks are converted automatically. Your e–mail address will not show up on any public page.