Spectre colpisce ancora Linux: l'hash della password root può trapelare in pochi minuti

Una nuova variante di Spectre v2 dimostra che alcune tecniche considerate difficili da sfruttare possono ancora produrre risultati concreti sui sistemi moderni.

L’attacco, denominato Branch Target Reuse (BTR), è stato sviluppato dai ricercatori del VUSec della Vrije Universiteit Amsterdam e della Scuola Superiore Sant’Anna di Pisa.

Il metodo prende di mira il comportamento dei compilatori JIT, utilizzati da browser, runtime e kernel per generare codice durante l’esecuzione. Nei test condotti su Linux, i ricercatori hanno costruito un exploit capace di recuperare dalla memoria del kernel l’hash della password di root. La ricerca coinvolge inoltre SpiderMonkey di Firefox e GraalVM, mostrando che il problema non riguarda esclusivamente una singola implementazione software.

Come funziona il nuovo attacco BTR

Spectre v2 sfrutta l’esecuzione speculativa e i meccanismi con cui il processore predice la destinazione dei salti indiretti.

BTR introduce una condizione particolare: quando un motore JIT libera una porzione di codice e successivamente riutilizza lo stesso indirizzo per generare istruzioni differenti, il processore può conservare una previsione relativa al codice precedente. La memoria contiene quindi il nuovo programma, mentre il predittore mantiene informazioni obsolete. L’attaccante sfrutta questa desincronizzazione per provocare un’esecuzione speculativa a un offset diverso da quello previsto dal normale flusso del programma.

La dimostrazione più significativa riguarda il classic BPF del kernel Linux. I ricercatori hanno utilizzato programmi cBPF per addestrare il predittore, liberare il codice originale e ottenere il riutilizzo della regione di memoria. L’esecuzione speculativa consente quindi di leggere informazioni attraverso le tracce lasciate nella cache del processore. Il canale di esfiltrazione raggiunge otto byte al secondo, una velocità sufficiente per individuare strutture del kernel e arrivare alla memoria del processo su, nel quale l’hash della password di root era presente dopo l’autenticazione.

L’attacco non richiede neppure che sia disattivata ogni forma di hardening del BPF JIT. I ricercatori hanno infatti adattato la tecnica per aggirare il constant blinding, una protezione che modifica i valori immediati generati dal compilatore per ostacolare il JIT spraying. La prova è stata realizzata codificando le istruzioni nei valori degli offset dei salti, sfruttando una diversa interpretazione dei byte quando l’esecuzione riparte da un allineamento differente.

Impatto su Linux, Firefox e runtime JIT

Nei test end-to-end, il recupero dell’hash ha richiesto mediamente tre minuti su Intel Raptor Cove e cinque minuti su Lion Cove. Il risultato non equivale alla scoperta immediata della password in chiaro: l’hash deve essere sottoposto a un attacco offline e la possibilità di ricavare la password dipende dall’algoritmo utilizzato e dalla sua robustezza. Il rischio concreto riguarda quindi la capacità di trasformare una vulnerabilità microarchitetturale in una primitiva di lettura della memoria appartenente a un processo privilegiato.

VUSec ha verificato BTR anche in SpiderMonkey, il motore JavaScript e WebAssembly di Firefox, osservando che le predizioni residue sopravvivono al ciclo di liberazione e riallocazione del codice. Il proof of concept permette di raggiungere speculativamente dati presenti nel buffer eseguibile, ma trasformarlo in un attacco completo al browser richiede ulteriore lavoro. In GraalVM, invece, il metodo ha permesso di saltare speculativamente un controllo del sandbox, anche se la compilazione e il garbage collection del runtime hanno cancellato le predizioni prima del completamento dell’exploit.

La risposta passa quindi soprattutto dagli aggiornamenti software. Per Linux sono state introdotte mitigazioni che utilizzano IBPB quando una regione JIT cBPF viene riutilizzata; Oracle ha scelto invece di ostacolare il riuso delle aree del code cache tramite randomizzazione. Le vulnerabilità del kernel sono identificate come CVE-2026-64507 e CVE-2026-64508. I ricercatori affermano di aver osservato il comportamento su processori Intel, AMD e Arm, mentre le contromisure hardware esistenti non eliminano da sole il problema. Per gli amministratori Linux, la misura più importante resta quindi mantenere aggiornati kernel e software interessati.