Branch Target Reuse: la variante di Spectre-v2 che sfrutta i motori JIT su Intel, AMD e Arm

Ricercatori di VUSec (Vrije Universiteit Amsterdam) e della Scuola Superiore Sant’Anna di Pisa hanno reso pubblica Branch Target Reuse, una variante di Spectre-v2 che sfrutta predizioni di salto obsolete nei motori JIT. Sul kernel Linux l’attacco ha estratto l’hash della password di root da una CPU Intel moderna, aggirando le mitigazioni attive prima della correzione specifica introdotta a luglio. Quelle correzioni sono ora disponibili e già riportate sui kernel stabili. AMD sostiene che bastino le indicazioni già esistenti per Spectre-v2.

Le vulnerabilità microarchitetturali tornano nell’agenda dei responsabili della sicurezza. L’embargo su Branch Target Reuse (BTR) è caduto il 29 settembre 2026 nel primo pomeriggio negli Stati Uniti, la sera in Italia. L’attacco è descritto sulla pagina di progetto del gruppo VUSec e nel paper Branch Target Reuse: Practical Spectre-v2 Attacks in JIT Engines via Stale Branch Prediction Entries, accettato alla ACM Conference on Computer and Communications Security (CCS) 2026 e in programma a novembre. Il paper e il codice sono pubblici.

Gli autori sono Sander Wiebing, Yuhui Zhu, Alessandro Biondi e Cristiano Giuffrida. Appartengono al gruppo Systems and Network Security (VUSec) della Vrije Universiteit Amsterdam e alla Scuola Superiore Sant’Anna di Pisa. La vulnerabilità si colloca nella famiglia aperta nel 2018 da Meltdown e Spectre.

Tra i finanziatori figurano:

• AWS, con il progetto Themis;
• l’ente olandese per la ricerca NWO, con il progetto INTERSECT e il Dutch Prize for ICT research;
• il programma Horizon Europe, con il progetto RESCALE (grant n. 101120962);
• il progetto SERICS (PE00000014) del PNRR, programma MUR.

Branch Target Reuse, perché è una notizia importante

Dal 2018 si riteneva che il codice automodificante, con cui i motori JIT generano istruzioni al volo, rendesse impraticabili attacchi di questo tipo. Giuffrida ha spiegato a BleepingComputer che BTR dimostra il contrario: gli attacchi di esecuzione transiente basati sul codice automodificante sono praticabili in ambienti reali e permettono di esfiltrare l’hash della password di root.

Da violazioni spaziali a violazioni temporali: il primo esempio di attacco Spectre-v2 pratico in-place

A The Hacker News Giuffrida ha descritto BTR come il primo esempio di attacco Spectre-v2 pratico in-place, che usa lo stesso salto indiretto sia per addestrare il predittore sia per l’attacco. Secondo il ricercatore, gli attacchi tradizionali sfruttano violazioni spaziali, cioè dirottano un salto verso una destinazione diversa, e questo si riteneva difficile da ottenere su un solo salto. In BTR il salto e la destinazione restano gli stessi: cambia il significato della destinazione, cioè il codice che vi si trova. È una violazione temporale.

Non un ritorno dopo una pausa

BTR non arriva dopo un lungo silenzio. Come ricorda The Hacker News, circa due mesi prima i ricercatori del MIT CSAIL Daniël Trujillo e Mengjia Yan avevano divulgato Interrupt Injection, tecnica che aggira le difese Spectre-v2 e legge memoria arbitraria del kernel su sistemi Linux con CPU Intel e AMD. Il filone degli attacchi side channel e alla cache resta attivo.

Il meccanismo: predizioni che sopravvivono al codice

BTR non attacca il codice: attacca ciò che la CPU ricorda del codice. I motori just in time (JIT) generano ed eliminano di continuo codice nativo e riusano le stesse regioni della cache del codice. Le CPU moderne ripristinano la coerenza del codice dopo ogni modifica. Non invalidano però necessariamente le voci del predittore dei salti indiretti (Branch Target Buffer, BTB).

Quando la cache del codice viene ripopolata, una voce obsoleta può ancora puntare al vecchio punto di ingresso. La CPU vi salta in modo speculativo, ma a quell’indirizzo ora c’è codice nuovo, letto da una posizione non prevista. In questo modo l’attaccante può aggirare le protezioni software. Può anche eseguire sequenze di istruzioni disallineate (gadget) che ha predisposto nel nuovo codice.

La primitiva speculative execute-after-free

I ricercatori chiamano il risultato primitiva speculative execute-after-free. Si può leggerla come l’equivalente microarchitetturale di un use after free. La differenza è che l’esecuzione resta speculativa e i dati si ricavano solo attraverso un canale laterale sulla cache. Il problema si sposta così dal codice generato al ciclo di vita della memoria che lo ospita, cioè a un comportamento legittimo di ogni motore JIT.

Tre bersagli, tre gradi di sfruttabilità

Kernel Linux: due exploit completi su cBPF

Sul kernel Linux il bersaglio è il JIT del classic BPF (cBPF). Il più potente eBPF è riservato agli utenti privilegiati, mentre cBPF resta disponibile ai programmi non privilegiati. Proprio per i suoi limiti, due soli registri a 32 bit, solo salti in avanti e nessun dereferenziamento di registri, è stato storicamente considerato abbastanza sicuro per i filtri in spazio utente. Per questo è ancora largamente usato in Linux Socket Filtering, nei filtri seccomp e nei percorsi di filtraggio pacchetti di software come Docker e Chrome, oltre che nel filtraggio di rete a elevata capacità.

Il bypass della constant blinding

Gli autori hanno costruito due exploit completi. Il primo funziona sulla configurazione predefinita. Il secondo funziona anche con l’irrobustimento bpf_jit_harden attivo, che applica constant blinding ai valori immediati. L’opzione è disattivata per impostazione predefinita, come indicano i ricercatori, ma alcune distribuzioni e configurazioni irrobustite la abilitano: chi l’ha attiva non è al riparo, perché il secondo exploit la aggira adattando a cBPF, per la prima volta, la tecnica di codifica delle istruzioni negli offset di salto introdotta da Maisuradze e altri nel 2016.

L’hash della password di root, in pochi minuti

Sulle CPU Intel moderne l’exploit legge memoria arbitraria del kernel e aggira le mitigazioni attive, quelle presenti prima della correzione specifica entrata nel kernel a luglio. Nella dimostrazione ha estratto l’hash della password di root dalla memoria di un processo su in esecuzione, a circa 8 byte al secondo, camminando la lista dei task del kernel e poi le tabelle delle pagine. Secondo BleepingComputer, che attribuisce il dato ai ricercatori, servono in media 3 minuti su processori Raptor Cove e 5 su Lion Cove. The Hacker News e SecurityWeek precisano che il sistema era pienamente aggiornato, con le protezioni predefinite attive.

Un hash non è la password in chiaro: per ricavarla bisogna forzarlo offline, e la riuscita dipende dall’algoritmo e dalla robustezza della password. Resta il fatto che la lettura di memoria arbitraria del kernel da codice non privilegiato apre la strada alle tecniche di privilege escalation su Linux.

SpiderMonkey: lo scenario della pagina web malevola

Su SpiderMonkey, il motore JavaScript e WebAssembly di Firefox, lo scenario è una pagina web malevola. Firefox non ha ancora completato l’isolamento dei siti, quindi altre schede possono trovarsi nello stesso spazio di indirizzi. Sulle CPU Intel le voci obsolete sopravvivono all’intero ciclo di deallocazione e riallocazione. I ricercatori stimano una velocità di alcune decine di byte al secondo, ma non hanno realizzato l’exploit completo nel browser. Per le postazioni resta un tema di endpoint security più che di perimetro.

GraalVM: la sandbox per codice non fidato

Su GraalVM, il runtime multilinguaggio di Oracle, il bersaglio è la sandbox per codice non fidato, come plugin o script forniti dagli utenti. Nella modalità più rigorosa ogni accesso alla memoria viene mascherato per resistere a Spectre. BTR permette di saltare il mascheramento in modo speculativo. Negli esperimenti, però, la compilazione e la garbage collection del motore hanno cancellato le voci prima che fossero sfruttabili. Secondo gli autori questo limite non sembra strutturale.

I ricercatori hanno osservato il comportamento su tutte le CPU testate, di Intel, AMD e Arm. Scrivono che nessuna CPU attuale ha un meccanismo per mantenere il predittore allineato allo stato reale del codice.

Mitigazioni disponibili

La divulgazione è stata coordinata con i produttori, che hanno riconosciuto i risultati. I produttori di processori hanno indicato che i meccanismi di mitigazione esistono già, come la barriera IBPB (Indirect Branch Predictor Barrier), e che le contromisure spettano al software.

Kernel Linux: barriera IBPB e due CVE

Per x86 il kernel Linux ha introdotto una barriera IBPB su tutti i core. Scatta quando un programma cBPF riusa una regione già occupata da codice BPF eseguito, e il riuso viene scoraggiato come ottimizzazione. La mitigazione si applica indipendentemente dal fatto che IBT sia attiva. Le correzioni sono identificate come CVE-2026-64507, “x86/bugs: Enable IBPB flush on BPF JIT allocation”, e CVE-2026-64508, “bpf: Support for hardening against JIT spraying”.

Secondo Phoronix, le modifiche sono entrate nel ciclo di sviluppo di Linux 7.2 a luglio, quando la divulgazione è avvenuta in forma privata, e sono già state riportate sui kernel stabili. È un dato rilevante per il patch management: non serve attendere una nuova release.

Oracle e Mozilla

Oracle ha randomizzato la posizione della cache del codice in GraalVM per ostacolare il riuso delle regioni. Mozilla ha valutato difese basate su IBPB, ma per ora privilegia il completamento dell’isolamento dei siti.

IBT e BTI: alzano l’asticella, non escludono il rischio

Le protezioni hardware IBT (x86) e BTI (Arm) richiedono che il bersaglio di un salto indiretto inizi con una istruzione endbr64 o BTI. Sulle CPU Intel meno recenti una o più istruzioni possono però essere eseguite in modo speculativo prima di quel controllo: Lion Cove è la prima generazione Intel in cui i ricercatori non hanno trovato questa finestra.

Anche sulle implementazioni prive della finestra, l’attaccante può iniettare nel codice compilato byte che codificano endbr64 e raggiungerli per esecuzione disallineata, trasformandoli in un punto di atterraggio valido. I ricercatori ci sono riusciti solo con la constant blinding disattivata: per loro IBT senza finestra, combinata con la constant blinding, è una difesa molto più solida. È l’indicazione di configurazione più utile che emerge dalla ricerca.

Le posizioni dei produttori

Interpellata da SecurityWeek, AMD ha dichiarato che la ricerca non rivela una nuova vulnerabilità nei suoi prodotti. Secondo l’azienda, la tecnica è coperta dalle indicazioni già pubblicate per Spectre-v2. Intel e Arm non hanno risposto alla testata.

La replica di AMD, letta alla luce dei fatti

La posizione di AMD è coerente con quella comune dei produttori riportata da VUSec: il meccanismo di mitigazione, IBPB, esisteva già e l’applicazione spetta al software. La correzione del kernel fa esattamente questo, cioè emette un IBPB. Non è quindi una smentita della ricerca, è una diversa attribuzione di responsabilità.

Resta però il dato di fatto. Su Linux l’exploit ha aggirato le mitigazioni attive per impostazione predefinita, e per fermarlo è servita una modifica nuova del kernel. Secondo The Hacker News, BTR aggira anche le mitigazioni introdotte per l’attacco Training Solo (CVE-2024-28956 e CVE-2025-24495); Giuffrida precisa che la portata resta limitata ai motori JIT, ma aggiunge che, poiché i kernel oggi eseguono motori JIT come cBPF, l’estensione finale è simile.

Per chi gestisce i sistemi la conseguenza pratica è una sola: non basta verificare che le mitigazioni Spectre-v2 note siano attive, serve un kernel che includa le correzioni di luglio.

Che cosa significa per chi gestisce infrastrutture condivise

Il modello di attacco e i contesti esposti

Il modello di attacco presuppone che l’attaccante esegua codice non privilegiato in un motore JIT sulla macchina bersaglio, con l’obiettivo di leggere dati sensibili dell’ambiente ospite. Senza questa possibilità, BTR non si sfrutta da rete. L’esposizione va quindi valutata dove codice non fidato gira accanto a dati sensibili.

Alla luce della ricerca, i contesti più rilevanti sono tre:

• server Linux che ospitano carichi di più soggetti sullo stesso kernel, come le piattaforme di container, dove cBPF è raggiungibile da processi non privilegiati; è lo stesso schema di rischio che emerge dalle falle del kernel che concedono root in ambienti multi-tenant
• postazioni in cui lo stesso browser serve per navigare e per accedere a dati di valore
• runtime che eseguono in sandbox codice fornito da terzi, come GraalVM

La ricerca non ha dimostrato attacchi tra macchine virtuali, né su runtime Java diversi da GraalVM. Per gli ambienti in cui l’isolamento del tenant è un requisito contrattuale resta aperto il tema del confidential computing, che affronta lo stesso problema da un’altra direzione.

Tre azioni nel breve periodo

Nel breve periodo, a nostro giudizio, le azioni ragionevoli sono tre. La prima è l’inventario dei sistemi in cui codice non fidato può influenzare un motore JIT, a partire dai nodi che eseguono carichi di terzi e dagli ambienti orchestrati.

La seconda è la verifica della versione del kernel: poiché le correzioni sono state riportate sui rami stabili, un aggiornamento successivo a luglio le contiene già, mentre restano scoperti i kernel congelati su versioni precedenti, caso frequente sui nodi di calcolo e negli apparati. Nella stessa verifica conviene controllare che le mitigazioni Spectre-v2 non siano state disattivate per ragioni prestazionali.

La terza riguarda i fornitori di servizi condivisi: chiedere quali correzioni sono applicate ai kernel che ospitano carichi di più clienti, e con quale impatto dichiarato sulle prestazioni.

Una decisione di governance, non solo di aggiornamento

Resta il nodo strutturale che ogni variante di Spectre riporta in evidenza. Le mitigazioni hanno un costo in prestazioni. Scegliere se applicarle o accettare il rischio residuo è quindi una decisione di governance, non solo di aggiornamento. Nel quadro degli adempimenti NIS2 conviene documentarla come tale nel processo di gestione del rischio.

Gli stessi ricercatori avvertono che le CPU moderne non risincronizzano tutto lo stato microarchitetturale quando il codice viene riscritto, e che non esiste una soluzione semplice, perché sincronizzare ogni struttura è costoso. Problemi simili a BTR, quindi, potrebbero emergere in futuro.

Il contributo della ricerca italiana

La presenza della Scuola Superiore Sant’Anna tra gli autori, con il finanziamento del progetto SERICS del PNRR, conferma il contributo della ricerca italiana alla sicurezza hardware e, in particolare, al filone microarchitetturale. È un ambito con ricadute dirette su tutta la catena hardware e software.

https://www.ictsecuritymagazine.com/notizie/spectre-v2-branch-target-reuse-motori-jit/