Le race condition sono situazioni indesiderate che si presentano quando più thread cercano di accedere a una risorsa condivisa senza un’adeguata attività di sincronizzazione. Vulnerabilità di tipo “concurrent use-after-free” (UAF) si verificano quando un programma o il sistema operativo stesso accedono a una regione di memoria liberata (deallocata) e che potrebbe essere già stata assegnata a un’altra parte del programma oppure a un’altra entità.
I ricercatori di VUSec e IBM hanno reso nota l’esistenza di una nuova modalità di attacco chiamata GhostRace che affliggerebbe tutti i principali sistemi operativi e i processori dei vari produttori, indipendentemente dall’architettura (quindi, ad esempio sia x86 che ARM).
Quando più thread o processi interagiscono simultaneamente su una regione di memoria precedentemente liberata, possono infatti crearsi scenari complessi. La competizione tra thread per accedere alla memoria deallocata, può causare risultati imprevedibili e potenzialmente pericolosi.
Eventuali malintenzionati possono sfruttare queste vulnerabilità per sovrascrivere dati sensibili, manipolare il flusso di esecuzione dei programmi o addirittura ottenere l’esecuzione di codice arbitrario.
L’esecuzione speculativa e le primitive di sincronizzazione
Per attenuare gli effetti delle vulnerabilità di tipo UAF, i sistemi operativi si affidano a primitive di sincronizzazione come mutex, spinlock e così via. Gli autori della scoperta di GhostRace, tuttavia, spiegano che “durante l’esecuzione speculativa, le primitive di sincronizzazione semplicemente non funzionano“.
L’esecuzione speculativa è la fase in cui il processore esegue istruzioni in anticipo basandosi su previsioni svolte durante il flusso di esecuzione di un qualunque programma. In questo frangente, le primitive di sincronizzazione non funzionano come previsto. Poiché l’esecuzione speculativa non rispetta le regole di sincronizzazione standard, i thread possono accedere in maniera simultanea e quindi concorrente alle risorse condivise.
La “scoperta chiave” è che le tecniche di sincronizzazione utilizzate per proteggere le parti critiche del codice, possono essere aggirate quando il processore esegue operazioni speculative. Questo avviene attraverso un tipo di attacco noto come Spectre-v1, ben noto e risalente ormai a inizio 2018.
Furono infatti proprio le falle Spectre e Meltdown a dare il via alla scoperta di un ampio ventaglio di possibili attacchi side-channel sui processori. Di conseguenza, anche le parti del codice che dovrebbero essere al sicuro dai problemi legati alla concorrenza, diventano vulnerabili agli attacchi. Gli aggressori, proprio facendo leva su una race condition, possono ottenere informazioni riservate dal software preso di mira.
Quanto c’è da preoccuparsi con la scoperta di GhostRace
Il problema di GhostRace è che interessa di fatto l’intera platea di sistemi operativi e microprocessori oggi disponibili sul mercato. Complessivamente, GhostRace desta preoccupazione perché, sfruttando proprio le race condition, eventuali attaccanti possono estrarre informazioni riservate dalla memoria del sistema.
Inoltre, GhostRace mette in discussione l’efficacia delle tecniche di sincronizzazione tradizionali: il loro aggiramento durante l’esecuzione speculativa, può rendere vulnerabili porzioni di codice precedentemente considerate sicure.
Nuove possibilità di attacco, come l’Inter-Process Interrupt (IPI) Storming, descritta nel documento tecnico di VUSec, estende ulteriormente la finestra di sfruttamento per gli aggressori, consentendo loro di eseguire attacchi UAF certamente efficaci.
Poiché la vulnerabilità GhostRace può essere sfruttata su una vasta gamma di hardware e software, coinvolgendo sia i fornitori di hardware che i produttori di software, rappresenta una minaccia significativa per la sicurezza di sistemi informatici in molteplici contesti, inclusi data center, dispositivi IoT, sistemi embedded e altro ancora.
È ovvio che per scatenare l’attacco GhostRace, sul sistema deve andare in esecuzione codice malevolo. I canali da proteggere, quindi, restano sempre gli stessi, a meno che non emerga un exploit “zero-click” (non è necessaria l’interazione dell’utente) che consenta di sfruttare il problema da remoto eludendo ad esempio le protezioni del browser Web.
Problema già notificato agli sviluppatori
Prima di rendere pubblici i dettagli di GhostRace, i ricercatori hanno informato i principali fornitori di hardware e gli sviluppatori del kernel Linux. Ciò è avvenuto a fine 2023.
Al momento, sul versante Linux sembra che i responsabili dello sviluppo del kernel si preoccupino principalmente delle prestazioni e non vogliano rischiare di penalizzarle con una soluzione affrettata. Quando si tratta di applicare patch che implicano l’uso di aggressioni di tipo side-channel, infatti, spesso lo scotto da pagare in termini di performance può essere tutt’altro che insignificante.
Secondo VUSec, la soluzione tecnica proposta dai ricercatori appesantirebbe le prestazioni dei un 5% circa con un test su LMBench. Non si parla però di soluzioni per le altre piattaforme coinvolte.
AMD, da parte sua, sottolinea che le attuali mitigazioni per Spectre v1 dovrebbero ancora applicarsi ai potenziali exploit GhostRace e poiché si tratta di qualcosa già affrontato in passato, dovrebbe essere soltanto questione di tempo per giungere a una soluzione condivisa.
Credit immagine in apertura: “Software Techniques for Managing Speculation in AMD Processors“, AMD.