GhostRace, un nuovo attacco alle CPU: non c'è architettura o sistema operativo che resista

GhostRace è un nuovo attacco all'esecuzione speculativa delle CPU che colpisce indistintamente tutte le architetture e i sistemi operativi. L'attacco è stato messo a punto dai ricercatori di VUSec, insieme al Systems Security Research Group di IBM Research Europe.
di Manolo De Agostini pubblicata il 18 Marzo 2024, alle 11:11 nel canale ProcessoriIBMARMAMDIntel
Si chiama GhostRace il nuovo attacco all'esecuzione speculativa delle CPU messo a punto dai ricercatori della VUSec (Vrije Universiteit di Amsterdam) e IBM (Systems Security Research Group di IBM Research Europe). L'esecuzione speculativa è quella tecnica che i processori usano per processare anticipatamente dei dati, facendo delle ipotesi verosimili (speculando, per l'appunto).
Il processore, durante il suo funzionamento, si occupa di verificare tali ipotesi e, se sono valide, ha già il risultato pronto, velocizzando quindi le operazioni. Se l'ipotesi è sbagliata, viene scartata e si esegue il calcolo in base alle condizioni effettive.
Dell'esecuzione speculativa si è iniziato a parlare nel 2018 a causa di Spectre e Meltdown, i primi attacchi che portarono l'intera industria dei PC - hardware e software - a intervenire per mitigare il problema, non senza ricadute prestazionali.
Fu un campanello d'allarme che ha portato i progettisti di architetture a rimettere il tema della sicurezza in risalto, forse parzialmente tralasciato alla ricerca delle massime prestazioni.
Da Spectre e Meltdown i principali attori dell'industria hanno cambiato approccio e, oltre a mettere loro stessi alla prova le proprie soluzioni, sollecitano ricercatori indipendenti e atenei a prenderle di mira. Per questo motivo, di tanto in tanto, vediamo spuntare nuove ricerche che illustrano attacchi che colpiscono le CPU.
How do synchronization primitives work during speculative execution? THEY DON'T!
— VUSec (@vu5ec) March 12, 2024
Disclosing #GhostRace (paper @USENIXSecurity). We turn all arch. race-free critical regions of OS/Hypervisors into Speculative Race Conditions. Joint work @vu5ec @IBMResearch: https://t.co/46Gjf2YyMF
Nel caso di GhostRace, ad esempio, si prende di mira un aspetto dell'esecuzione speculativa, ovvero le cosiddette "race conditions", ovvero quando più thread tentano di accedere a una risorsa condivisa senza un'adeguata sincronizzazione. Tutti i dettagli, per gli addetti ai lavori, si possono trovate qui.
Quando ciò avviene, si verificano vulnerabilità come "concurrent use-after-free" la cui mitigazione richiede ai sistemi operativi di affidarsi a "primitive di sincronizzazione come mutex, spinlock, ecc.". I ricercatori hanno però scoperto che "tutte le primitive di sincronizzazione comuni implementate usando i rami condizionali possono essere aggirate microarchitetturalmente su percorsi speculativi tramite un attacco Spectre V1" che trasforma regioni critiche dell'architettura non soggette a race conditions in Speculative Race Conditions (SRCs), "consentendo a malintenzionati di far trapelare informazioni dal software target".
Secondo i ricercatori, il problema riguarda tutte le architetture e i sistemi operativi in circolazione. "In sintesi, qualsiasi software, ad esempio sistema operativo, hypervisor, ecc., che implementa primitive di sincronizzazione tramite rami condizionali senza alcuna istruzione di serializzazione su quel percorso ed è in esecuzione su qualsiasi microarchitettura (ad esempio x86, ARM, RISC-V, ecc.), che consente l'esecuzione speculativa di rami condizionali, è vulnerabile agli SRC. Come in altri attacchi all'esecuzione speculativa, ciò consente la fuga di dati dal software target".
I ricercatori hanno informato sul finire del 2023 i principali produttori di CPU - Intel, AMD, ARM e IBM - nonché i manutentori del kernel Linux.
Per arginare l'attacco, i ricercatori hanno elaborato una mitigazione SRC generica per serializzare tutte le primitive di sincronizzazione interessate che richiede modifiche minime del kernel Linux, ma comporterebbe un overhead prestazionale intorno al 5%. Gli sviluppatori del kernel non hanno piani immediati per implementare la soluzione proposta perché preoccupati dell'impatto prestazionale, ma hanno scelto di adottare una mitigazione parziale che non chiude totalmente la superficie di attacco.
I produttori di hardware, invece, non si sono espressi ancora pubblicamente, se non AMD, secondo cui le mitigazioni esistenti per Spectre V1 sarebbero sufficienti per affrontare anche GhostRace.
6 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infola correzione suggerita dallo stesso VUSec (che ne ha proposta una, solo software e specifica per linux), era stata effettivamente implementata già a febbraio (sono almeno 50 commit, questo è l'ultimo), ma si tratta soltanto di una mera mitigazione che irrobustisce lo stack contro il inter process interrupt storming, il quale è a sua volta parte delle tecniche per sfruttare Ghostrace.
il 5% di potenziale impatto è saltato fuori da qui su alcuni benchmark sintetici testando questa mitigazione. ed in sostanza si sono detti "visto che non corregge na mazza e costa il 5%, lasciamola perdere".
quelli di Xen, il cui lavoro è usato a piene mani da chi fa hypervisors e virtualizzazione hanno fatto qualche bollettino con raccomandazioni varie e qualche patch, ma non risulta per ora che il problema possa scavalcare le sandbox classiche, che era la preoccupazione di gran lunga più grave.
da capire ancora la posizione di AMD che se n'è uscita quasi minimizzando il tutto (ok, è meno grave di quanto non possa apparire ad una prima occhiata), ma senza fornire studi, PoC o prove varie.
da capire anche l'impatto sul mondo IoT.
o meglio, su tutti i dispositivi smart che un minimo di potenza di calcolo ce l'hanno, che hanno "veri" sistemi operativi diffusi, da cui passano parecchi "caxxi propri" della gente, ma che non ricevono sempre aggiornamenti tempestivamente. ad esempio i chromecast, gli htpc android, i dispositivi alexa, smart tv, router/decoderTV e questo genere di cose.
Ovvero il sistema di come i calcolatori fanno ad eseguire le istruzioni?
Forse i creatori di Monza non hanno tutti i torti?
Già impiegando i memristori la Von Neumann non sarebbe più praticabile,cambiando proprio il sistema di esecuzione delle istruzioni.
o meglio, su tutti i dispositivi smart che un minimo di potenza di calcolo ce l'hanno, che hanno "veri" sistemi operativi diffusi, da cui passano parecchi "caxxi propri" della gente, ma che non ricevono sempre aggiornamenti tempestivamente. ad esempio i chromecast, gli htpc android, i dispositivi alexa, smart tv, router/decoderTV e questo genere di cose.
per me è questo il vero incubo, e sarà sempre più un problema, visto il moltiplicarsi di dispositivi iot, spesso inutilmente connessi (vedi spazzolino da denti e compagnia) ma comunque basati su hardware e software dal supporto scarso o inesistente
la correzione suggerita dallo stesso VUSec (che ne ha proposta una, solo software e specifica per linux), era stata effettivamente implementata già a febbraio (sono almeno 50 commit, questo è l'ultimo), ma si tratta soltanto di una mera mitigazione che irrobustisce lo stack contro il inter process interrupt storming, il quale è a sua volta parte delle tecniche per sfruttare Ghostrace.
il 5% di potenziale impatto è saltato fuori da qui su alcuni benchmark sintetici testando questa mitigazione. ed in sostanza si sono detti "visto che non corregge na mazza e costa il 5%, lasciamola perdere".
quelli di Xen, il cui lavoro è usato a piene mani da chi fa hypervisors e virtualizzazione hanno fatto qualche bollettino con raccomandazioni varie e qualche patch, ma non risulta per ora che il problema possa scavalcare le sandbox classiche, che era la preoccupazione di gran lunga più grave.
da capire ancora la posizione di AMD che se n'è uscita quasi minimizzando il tutto (ok, è meno grave di quanto non possa apparire ad una prima occhiata), ma senza fornire studi, PoC o prove varie.
da capire anche l'impatto sul mondo IoT.
o meglio, su tutti i dispositivi smart che un minimo di potenza di calcolo ce l'hanno, che hanno "veri" sistemi operativi diffusi, da cui passano parecchi "caxxi propri" della gente, ma che non ricevono sempre aggiornamenti tempestivamente. ad esempio i chromecast, gli htpc android, i dispositivi alexa, smart tv, router/decoderTV e questo genere di cose.
Ah ecco, ora e' tutto piu' chiaro, si uso sia Win che Linux Mint.
Ora ho capito molto di piu' di tutti sti articoli circolanti.
Grazie mille.
Per IOT, antifurti IOT e tutte le cose inutilmente collegate ad internet, beh le evito come la peste.
Di sicuro come minimo nel router di casa bisogna attivare il firewall interno che e' sempre disattivato di standard, ma come minimo..
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".