Interrupt Injection aggira le difese Spectre v2 su processori AMD e Intel

🛡️ Executive Summary

• Interrupt Injection inserisce un interrupt tra la neutralizzazione del branch predictor e il suo utilizzo, riaprendo una finestra per attacchi Spectre v2.
• Su AMD Zen 2, i ricercatori hanno letto memoria arbitraria del kernel Linux a 5,47 byte al secondo con accuratezza del 91,97%.
• La mitigazione richiede aggiornamenti del sistema operativo e una nuova neutralizzazione del predittore prima del ritorno dall’handler dell’interrupt.

Una nuova tecnica denominata Interrupt Injection permette a un programma Linux privo di privilegi di colpire il breve intervallo compreso tra la neutralizzazione del branch predictor e il suo successivo utilizzo da parte del kernel. I ricercatori del MIT CSAIL hanno ottenuto errori di predizione su processori AMD e Intel, costruendo su AMD Zen 2 un exploit capace di leggere memoria arbitraria del kernel Linux. La ricerca amplia la superficie già evidenziata dalla Native Branch History Injection contro Spectre v2 e da Pathfinder sulle CPU Intel, mostrando che anche gli interrupt possono interferire con difese microarchitetturali già attive.

Interrupt Injection sfrutta la finestra lasciata dalle mitigazioni

Le mitigazioni contro Spectre v2 cercano di impedire che un processo controllato dall’attaccante condizioni le previsioni utilizzate durante l’esecuzione di codice privilegiato. Il sistema operativo o il processore neutralizzano lo stato del Branch Target Buffer, del Branch History Buffer o del Return Stack Buffer, eliminando le informazioni che potrebbero dirigere speculativamente il kernel verso un gadget capace di esporre dati protetti. Il problema è che la neutralizzazione e l’utilizzo dello stato non possono verificarsi nello stesso istante: tra le due operazioni rimane una finestra temporale, talvolta larga appena poche istruzioni, nella quale un evento asincrono può contaminare nuovamente il predittore. Daniël Trujillo e Mengjia Yan definiscono questa classe di attacchi TONTOU, acronimo di Time-of-Neutralization to Time-of-Use, nel paper tecnico pubblicato dal MIT CSAIL. Il principio richiama le race condition TOCTOU del software, ma viene applicato allo stato microarchitetturale della CPU: una difesa può risultare corretta nel momento in cui viene eseguita e non esserlo più quando il kernel utilizza il componente appena ripulito. La scoperta si colloca nello stesso filone di Indirector sui processori Intel di fascia alta e della più recente VMScape negli ambienti cloud AMD, due ricerche che hanno mostrato come differenti strutture di predizione possano continuare a produrre percorsi speculativi sfruttabili nonostante anni di interventi hardware e software.

Un timer inserisce codice dopo la pulizia del predittore

Interrupt Injection fornisce agli attaccanti una tecnica concreta per entrare nella finestra TONTOU. Un programma locale può impostare timer con precisione nell’ordine dei nanosecondi e provocare un interrupt mentre il kernel si trova tra la neutralizzazione e l’istruzione che dovrebbe utilizzare lo stato protetto. La CPU sospende il normale flusso di esecuzione, passa all’handler dell’interrupt e successivamente ritorna nel punto interrotto. Durante questa deviazione, le istruzioni eseguite dall’handler possono aggiornare nuovamente il branch predictor, trasformando il percorso di gestione dell’interrupt in un gadget di addestramento. Quando il controllo torna alla sequenza protetta, la mitigazione è già stata eseguita, ma il predittore non si trova più nello stato garantito dalla difesa. L’attacco non disabilita direttamente Spectre v2: interviene tra la protezione e il suo utilizzo, riaprendo il canale speculativo. Il meccanismo aiuta a comprendere perché vulnerabilità come Zenbleed su AMD Zen 2 e REPTAR sui processori Intel non possano essere affrontate osservando soltanto il risultato architetturale delle istruzioni: cache, predittori, buffer e sequenze transitorie continuano a produrre stati invisibili al programma ma misurabili attraverso canali laterali. La ricostruzione pubblicata dal MIT CSAIL conferma che i ricercatori hanno ottenuto misprediction su più generazioni AMD e Intel, superando protezioni implementate sia nel software sia nei processori più recenti.

Safe RET viene superata su AMD Zen 2

La dimostrazione più completa riguarda Safe RET, mitigazione predefinita del kernel Linux contro lo Speculative Return Stack Overflow, tracciato come CVE-2023-20569. Safe RET forza i ritorni del kernel verso una destinazione speculativa controllata, neutralizzando il contenuto del Return Stack Buffer immediatamente prima dell’istruzione ret. Su AMD Zen 2, tuttavia, tra la chiamata utilizzata per ripulire il buffer e il ritorno protetto rimane una finestra di appena due istruzioni e sei byte. I ricercatori hanno aumentato le probabilità di intercettarla utilizzando un thread sul core logico gemello per espellere quelle istruzioni dalle cache L1 e L2, rallentandone il recupero, e scegliendo la system call write, che lasciava sotto il controllo del processo due registri utili all’exploit. Gli interrupt sono entrati nella finestra nel 5-12% dei tentativi, mentre circa il 2% delle esecuzioni ha conservato anche lo stato dei registri necessario a proseguire l’attacco. L’handler ha quindi riavvelenato il Return Stack Buffer mediante Inception, vulnerabilità già descritta nell’analisi sull’attacco che compromette i processori AMD Zen. La differenza è decisiva: Inception viene applicata dopo la pulizia di Safe RET, rendendo nuovamente utilizzabile una primitiva che la mitigazione avrebbe dovuto neutralizzare. La documentazione ufficiale del kernel Linux su SRSO e Safe RET chiarisce che la protezione interessa le transizioni da utente a kernel e da guest a host, richiede microcodice aggiornato e può essere verificata tramite il file /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow. (Documentazione del Kernel Linux)

L’exploit legge la memoria protetta del kernel Linux

Dopo avere superato Safe RET, i ricercatori hanno costruito un exploit end-to-end capace di leggere memoria arbitraria del kernel a 5,47 byte al secondo, con un’accuratezza del 91,97%. La velocità è contenuta, ma sufficiente per estrarre informazioni mirate e aggirare difese complementari. Nei test, l’attacco ha eliminato la randomizzazione degli indirizzi del kernel in circa nove minuti, riuscendo in tutti e dieci i tentativi, e ha individuato e copiato /etc/shadow in cinque prove su dieci. Il file contiene gli hash delle password degli account locali e rappresenta una dimostrazione concreta della capacità di raggiungere dati che un normale processo non dovrebbe poter leggere. Non si tratta però di un attacco remoto: servono esecuzione di codice locale, controllo accurato dei timer, conoscenza della microarchitettura e gadget compatibili nel kernel. Il rischio è quindi maggiore nei server multiutente, nei sistemi di sviluppo condivisi e nelle infrastrutture cloud dove workload appartenenti a soggetti differenti possono convivere sullo stesso hardware. È una condizione già emersa con la vulnerabilità Sinkclose nei processori AMD e con gli attacchi contro CPU Intel, AMD e ambienti cloud, nei quali un accesso iniziale limitato può diventare il punto di partenza per raggiungere livelli di privilegio o domini di memoria più sensibili. Il paper precisa inoltre che su Intel Arrow Lake e Cascade Lake Refresh sono state ottenute misprediction, ma non una fuga completa di dati: l’exploitabilità end-to-end richiede un gadget di disclosure valido già presente nel kernel.

AMD conferma Zen 1-Zen 4 e Linux distribuisce la correzione

AMD ha pubblicato il bollettino AMD-SB-7061 dedicato alla Safe RET Interrupt Vulnerability, indicando come interessati i processori basati sulle architetture Zen 1, Zen 2, Zen 3 e Zen 4. Il comportamento è stato dimostrato direttamente su Zen 1 e Zen 2, mentre per Zen 3 e Zen 4 il coinvolgimento viene indicato come possibile ma non provato nello stesso modo. Il produttore ritiene che il problema sia associato all’implementazione Linux della mitigazione Safe RET e non ha assegnato un nuovo codice CVE. La patch del kernel, intitolata “x86/bugs: Make Safe-RET robust against interrupt injection”, modifica il ripristino dello stato dopo l’interrupt per evitare che la sequenza di ritorno utilizzi un predittore nuovamente contaminato. L’intervento viene distribuito attraverso i normali aggiornamenti del sistema operativo, rendendo necessario installare kernel e microcodice più recenti. Il precedente rilascio degli aggiornamenti Debian per Downfall e Inception aveva già mostrato che le vulnerabilità delle CPU richiedono un coordinamento tra produttore, manutentori del kernel e distribuzioni, mentre le patch Linux dedicate ai processori AMD Zen confermano che la correzione effettiva dipende spesso dalla combinazione di software e firmware. Gli amministratori devono quindi aggiornare il sistema, riavviare sulla nuova versione del kernel e verificare lo stato delle mitigazioni esposte tramite sysfs, evitando di considerare sufficiente la sola presenza nominale di Safe RET. (AMD)

Gli interrupt entrano nel modello di sicurezza delle CPU

Interrupt Injection modifica il modo in cui devono essere progettate e valutate le mitigazioni contro l’esecuzione speculativa. Ripulire il branch predictor non è sufficiente quando un interrupt può eseguire istruzioni prima dell’utilizzo dello stato neutralizzato. Una possibile difesa consiste nell’effettuare una seconda pulizia al termine dell’handler, ma il paper avverte che la stessa strategia non produce necessariamente risultati identici su tutte le CPU: su alcune piattaforme Intel, lasciare uno stato standardizzato potrebbe perfino rendere più prevedibile la preparazione dell’attacco. Un’altra soluzione sarebbe bloccare gli interrupt durante la finestra critica, con un costo potenzialmente elevato in termini di latenza e prestazioni. Le mitigazioni devono quindi essere adattate alla singola microarchitettura, come già accaduto con le protezioni di Tails contro Spectre v4 e con gli interventi contro GPUBreach e i side channel sulle GPU NVIDIA. Il risultato più importante della ricerca non è soltanto l’exploit su Zen 2, ma l’individuazione di una nuova assunzione fragile: qualsiasi codice eseguito tra neutralizzazione e utilizzo diventa parte della superficie di attacco. Da questo momento, interrupt, eccezioni e percorsi di ritorno non possono più essere trattati come elementi esterni alle difese Spectre v2, ma devono essere inclusi direttamente nella loro progettazione e verifica.