TONTOU, l’attacco che riapre la falla tra le difese Spectre v2 e il loro utilizzo

La finestra di due istruzioni

Secondo i ricercatori del MIT CSAIL Daniël Trujillo, dottorando, e Mengjia Yan, professoressa associata, la supposizione alla base delle mitigazioni era che l’attaccante non potesse intervenire in quell’intervallo estremamente breve.

Su AMD Safe RET, la finestra può essere larga appena due istruzioni . Un processo non privilegiato può programmare un’interruzione hardware con una tempistica sufficientemente precisa da farla arrivare proprio in quel passaggio. La tecnica, chiamata INTERRUPT INJECTION, consente di ripopolare o “riavvelenare” il branch predictor dopo l’esecuzione della difesa, ma prima che il kernel ne utilizzi lo stato .

Il risultato è un nuovo canale per l’esecuzione speculativa, nonostante le mitigazioni Spectre v2 siano attive. L’attacco richiede che sulla macchina bersaglio venga eseguito codice nello spazio utente, ma non richiede privilegi elevati .

L’impatto dimostrato su AMD Zen 2

Il team ha realizzato un exploit completo e lo ha testato su diverse generazioni di processori:

• Intel Cascade Lake Refresh;
• Intel Arrow Lake;
• AMD Zen 2;
• AMD Zen 4 .

Il risultato più significativo è stato ottenuto su un sistema AMD Zen 2 con Linux 6.14.0-37-generic, 16 GB di RAM e le protezioni Spectre v2 predefinite attive. In questo ambiente, l’exploit ha fatto fuoriuscire memoria arbitraria del kernel a 5,47 byte al secondo, con un’accuratezza del 91,97% .

La dimostrazione è arrivata fino al file /etc/shadow, utilizzato da Linux per conservare gli hash delle password. I ricercatori sono riusciti a individuarlo e a estrarne il contenuto in cinque casi su dieci; ogni tentativo è durato circa 18 minuti .

Il dato non significa che qualunque computer Linux possa essere compromesso automaticamente: la prova richiede condizioni specifiche, codice eseguito localmente e un’attività di temporizzazione molto precisa. Mostra però che una mitigazione considerata attiva può ancora lasciare spazio a una fuga di dati dal kernel.

Cosa è emerso sui processori Intel

I test hanno mostrato un bypass parziale di eIBRS sulle piattaforme Intel Cascade Lake Refresh e Arrow Lake, anche se la superficie d’attacco non coincide con quella osservata nel caso AMD Safe RET .

Per AMD Zen 4, invece, i ricercatori non hanno confermato con lo stesso metodo un reindirizzamento di ramo riuscito . Le evidenze, quindi, non indicano un impatto identico su tutti i processori AMD e Intel testati: TONTOU descrive una classe di problemi, mentre la riuscita pratica dipende dall’architettura e dall’implementazione della mitigazione.

La risposta di AMD e del kernel Linux

La divulgazione coordinata ad AMD, Intel e Arm è iniziata il 5 febbraio 2026 . Nel caso AMD, la risposta si è concentrata sull’implementazione Linux di Safe RET, usata come mitigazione per il problema Speculative Return Stack Overflow (SRSO), più che sull’architettura dei processori considerata in astratto .

La sequenza degli interventi è stata la seguente:

• il 2 giugno 2026 è stata inserita una correzione nel kernel Linux, firmata da Borislav Petkov di AMD, con il titolo “x86/bugs: Make Safe-RET robust against interrupt injection” ;
• il 5 agosto 2026 la patch è stata accettata nel kernel Linux principale ;
• il 6 agosto 2026 AMD ha pubblicato il bollettino AMD-SB-7061, “Safe RET Interrupt Vulnerability”, indicando come interessate le generazioni Zen 1–Zen 4 ;
• la correzione per CVE-2026-68480 è stata distribuita nelle versioni Linux 7.1.7, 6.18.43, 6.6.149 e 6.1.181 .

Intel ha riconosciuto i risultati durante la divulgazione coordinata e ha assegnato un premio tramite il proprio programma bug bounty. L’azienda ha tuttavia comunicato ai ricercatori che non avrebbe sviluppato ulteriori mitigazioni, citando tra gli altri fattori la disponibilità dei cosiddetti disclosure gadget necessari per un attacco realistico .

I risultati sono stati presentati da Trujillo e Yan a Black Hat USA il 6 agosto 2026; il lavoro completo è stato inoltre accettato per USENIX Security 2026 .

Il problema più ampio: una difesa non è un’operazione atomica

TONTOU mette in discussione un presupposto preciso delle mitigazioni basate sulla neutralizzazione: trattare la pulizia del branch predictor e il suo successivo utilizzo come se fossero, dal punto di vista dell’attaccante, un’unica operazione indivisibile.

La ricerca mostra invece che tra i due momenti può esistere una condizione di gara a livello microarchitetturale. Una patch del kernel può chiudere la finestra specifica sfruttata dall’injection di interruzioni su AMD Zen, ma il risultato suggerisce anche una lezione più generale: la sicurezza dei processori moderni richiede una combinazione di progettazione hardware, mitigazioni del sistema operativo e verifiche continue delle ipotesi su cui tali difese si basano.