Sicurezza  »  Articoli  »  Approfondimento Vulnerabilità 

I media player sono alcuni dei software più facilmente esposti alle vulnerabilità, locali e remoti. Oggi non sono più semplici riproduttori di file mp3: è cosa comune avere un unico programma in grado di leggere diversi formati di file audio e video, di riprodurre contenuti in streaming e di accedere a banche dati esterne. Se teniamo in considerazione l'elevato numero di formati e protocolli supportati, la rapidità con cui spesso i servizi devono essere aggiunti al player e l'estrema varietà dei servizi stessi, è facile capire come non sia affatto raro che vengano scoperte vulnerabilità in software di questo tipo.

La loro diffusione capillare fa sì inoltre che gli exploit scoperti diventino critici a prescindere: sia perché il fatto che gli utenti finali sono spesso persone comuni non "addette ai lavori", sia perché molti dei servizi forniti dai player non si limitano al funzionamento in locale, ma richiedono una connessione a Internet e vi è quindi una certa esposizione ad exploit remoti: pensate semplicemente ai plug-in dei rispettivi player per riprodurre contenuto multimediale all'interno di un browser.

Prima di parlare di alcuni casi reali risalenti alla recente storia dei più celebri e utilizzati media player, è bene spendere qualche parola sul concetto di buffer overflow, un tipo di vulnerabilità molto diffuso e sfruttato. Chi volesse conoscere subito le principali vulnerabilità dei Media player può saltare a pagina 2.

Stack, Heap e Buffer overflow: una premessa tecnica

Si ha un overflow quando tali dati vengono scritti oltre i limiti del buffer stesso, andando a sovrascrivere aree di memoria adiacenti con contenuti non previsti. Le conseguenze di un exploit che sfrutti un buffer overflow sono di svariato tipo: si va dal DoS (denial of service, crash inatteso dell'applicativo), all'esecuzione di codice arbitrario sulla macchina dell'utente che ha lanciato il programma, con i privilegi dell'utente stesso.

Quando un programma viene eseguito le variabili, e quindi i buffer, possono essere allocate in tre diverse zone: un'area per i dati statici, che contiene ad esempio costanti e variabili globali, un'area chiamata stack che contiene le variabili locali e i record di attivazione delle diverse funzioni, e un'area denominata heap che contiene variabili dinamiche, solitamente accedute attraverso puntatori, e alcune informazioni utili alla gestione di questa stessa area di memoria.

Figura 1: Layout della memoria

Due tipologie di buffer overflow molto diffuse sono i cosiddetti stack overflow e heap overflow, che coinvolgono aree di memoria diverse in modi diversi, pur perseguendo il medesimo scopo e sfruttando il medesimo problema: una stessa area di memoria contiene sia dati sia metadati (informazioni di gestione). Invadendo i secondi con i primi, sfruttando l'assenza dei dovuti controlli sulle dimensioni dei dati in ingresso, è possibile mandare in crash l'applicazione o, nel caso peggiore, mandare in esecuzione codice arbitrario.

Lo stack overflow è basato sul fatto che i record di attivazione delle funzioni contengono l'indirizzo di ritorno alla routine principale; questo significa che, riuscendo a scrivere su tale indirizzo, al termine della funzione il programma eseguirà il codice arbitrario inserito anziché tornare alla routine chiamante. Quello che tipicamente accade, quindi, è quanto segue: nello stack viene memorizzato un buffer dichiarato localmente dalla funzione ora in esecuzione, tale buffer viene riempito con dei dati senza i dovuti controlli, i dati riempiono il buffer e vanno oltre, fino a sovrascrivere l'indirizzo di ritorno con un altro indirizzo. Al termine della funzione, il programma salta a questo indirizzo e inizia ad eseguire una porzione di codice potenzialmente pericolosa.

Lo heap overflow, invece, è basato sul fatto che ogni blocco in cui l'area heap è suddivisa contiene dei metadati particolari: ad esempio puntatori ai blocchi precedente e successivo, dimensione della memoria allocata e un flag che indica se il blocco è in uso o meno. Quando un blocco di memoria in quest'area viene deallocato, il che avviene quando tale flag viene impostato su false, i blocchi liberi adiacenti vengono uniti, mantenendo un solo header di metadati per tutto il blocco di memoria libera. Se la quantità di memoria allocata è statica o corrotta, è possibile che si verifichi un overflow, e che dei dati siano scritti nell'header del blocco di memoria successivo; modificando i metadati ivi contenuti, però, non si può sovrascrivere un'area utilizzata direttamente come indirizzo di salto. Quello che accade è che viene sfruttato il processo di deallocazione descritto in precedenza, impostando quando liberare il blocco il cui header è stato sovrascritto e dove andare dopo la deallocazione stessa, sovrascrivendo ad esempio l'indirizzo di ritorno della routine di deallocazione di memoria (che si troverà sullo stack).

Altri articoli

Altre guide

Altre newsletter