ArsTechnica ha pubblicato l'altro ieri un articoletto davvero interessante, sul quale i progettisti dei sistemi operativi non dovrebbero dormire sopra.

{mosgoogle right}

L'incontro annuale Usenix ha luogo per manifestare ogni idea: dai flaw alle previsioni su quali problemi di sicurezza potranno emergere in futuro. Un gran bell'esempio di questo intendimento è stato dato da Dan Tsafrir, Yoav Etsion e Dror G. Feitelson con la loro documentazione (PDF) intitolata "Monopolizzare segretamente la CPU senza alcun privilegio di superutente".

Il team ha presentato un programma per sistemi basati su Unix - anche se la stessa tecnica potrebbe benissimo essere adottata in qualsiasi moderno sistema multitasking - che permette ad uno specifico task di "barare" e assorbire più cicli macchina di quanti normalmente il sistema operativo gli concederebbe.

Le manchevolezze dei sistemi di sicurezza sono di due categorie: permettono l'azione ostile (un programma fa qualcosa che l'utente non vorrebbe che facesse, come inviare spam) oppure permettono l'occultamento (il programma tenta di nascondere azioni ostili per renderle non identificabili dall'utente). Le più note azioni di lavoro occulto, come i rootkit, riescono solo avendo pieno accesso amministrativo al computer.

L'utility descritta nella "paper" in qualche modo "bara": raggiunge il risultato pur girando in un normale livello non amministrativo. In teoria, dice il documento, un programma potrebbe benissimo nascondersi facendo in modo di attivarsi immediatamente dopo un "interrupt tick" (l'attimo di avvio di un interrupt: la maggior parte dei sistemi operativi generano tale tick basandosi sull'orologio di sistema e avviano la routine di interrupt ogni manciata di millisecondi), dopodiché porsi in stato di "sleep" (dormiente) fino a un attimo prima l'avvio del successivo tick. Grazie a questa tecnica, i normali programmi di "task accounting" (controllo programmi in esecuzione, come il Task Manager di Windows) dei sistemi operativi non riuscirebbero in alcun modo ad evidenziare la presenza di tale programma.

Il documento continua indicando che fare in modo tale che un programma giri proprio in quelle fasi (da dopo il tick a subito prima del successivo) è "tecnicamente impossibile". Invece, diversi metodi vengono dimostrati come capaci di "barare" in questo senso, evidenziando che si avvicinano molto all'ottenere questo comportamento, tipico delle situazioni di funzionamento in modalità superutente, senza mai arrivare a doverlo essere davvero. La tecnica impiega un timer molto più preciso del normale interrupt del sistema, chiamato cycle counter (contatore di cicli): si tratta di una istruzione in assembler che può essere data alla CPU anche in modalità utente.

Sono stati analizzati sette diversi sistemi operativi nel documento come potenziali obbiettivi di un siffatto attacco. Dei sette, solo Mac OSX è stato trovato immune dall'azione: non perché sia basato su un'architettura migliore ma solo in quanto utilizza un diverso algoritmo di schedulazione per i propri timer. Altri sistemi ritenuti immuni sono i sistemi operativi real-time come QNX, che garantisce l'esecuzione dei programmi entro tempi prestabiliti.

L'exploit potrebbe o meno trovare applicazioni in campo malware: mentre è evidente che riesce a sottrarsi dall'essere identificato dai Task Manager della situazione, ha ad esempio la possibilità di sottrarre, comunque, cicli macchina con il risultato di rallentare il computer. Tale circostanza insospettirebbe senz'altro l'utilizzatore, tuttavia la tecnica potrebbe essere "saggiamente" impiegata per "barare solo un po'", rendendo però l'applicazione molto difficile da identificare. Gli autori concludono dicendo che, secondo loro, si potrebbero proteggere i sistemi operativi da simili circostanze ma solo a pesanti costi in termini di performance.

Condividere questa pagina su: