Meltdown e Spectre e la madre di tutte le vulnerabilità

Il problema non era nel programma ma nel modo in cui il processore cercava di essere veloce

Se avete seguito la sicurezza informatica nel gennaio 2018 saprete certamente che Meltdown e Spectre furono uno di quei momenti nei quali cambia improvvisamente il modo di guardare una tecnologia che fino al giorno prima sembrava semplicemente funzionare. Non si trattava della solita falla in un browser, di una libreria scritta male oppure di un buffer overflow dentro un'applicazione, ma di una classe di attacchi che sfruttava proprio alcuni dei meccanismi usati dalle CPU moderne per andare più veloci. Il 3 gennaio 2018 arrivò la divulgazione pubblica coordinata e le tre sigle che ancora oggi vale la pena ricordare sono CVE-2017-5753 e CVE-2017-5715 per Spectre, mentre CVE-2017-5754 identifica Meltdown.

Io le chiamo, con una certa libertà, LA MADRE DI TUTTE LE VULNERABILITÀ non perché siano state le prime falle hardware della storia e nemmeno perché rappresentino ancora oggi l'attacco più pericoloso in assoluto, ma perché hanno reso evidente ad un pubblico enorme una cosa molto più scomoda: il risultato architetturale di un'istruzione può essere annullato e quindi non diventare mai visibile al programma, mentre gli effetti lasciati dentro la microarchitettura possono sopravvivere abbastanza da raccontare ciò che il processore aveva fatto per pochi istanti. Da lì in avanti tutta la famiglia degli attacchi di transient execution è diventata una materia con la quale progettisti di CPU, sistemi operativi, hypervisor, browser e compilatori hanno dovuto convivere.

Prima bisogna capire che cosa significa esecuzione speculativa

Un processore moderno non aspetta sempre disciplinatamente di conoscere il risultato di ogni istruzione prima di iniziare la successiva, perché se lo facesse sprecherebbe una quantità enorme di tempo. Quando incontra un salto condizionato cerca quindi di prevedere quale strada verrà presa e comincia ad eseguire in anticipo le istruzioni che ritiene probabili, così se ha indovinato ha già fatto lavoro utile. Se invece ha sbagliato elimina quei risultati dal punto di vista architetturale e riparte dalla strada corretta.

Ed è qui che nasce il problema. Quel lavoro speculativo può non modificare registri e memoria in maniera visibile al programma, ma può avere toccato la cache, i predictor oppure altre strutture interne. In pratica il processore cancella il risultato ufficiale, ma non sempre cancella ogni impronta temporale del percorso che aveva imboccato. Un attaccante può allora misurare quelle differenze, ad esempio osservando se un certo dato viene recuperato più rapidamente perché è già finito in cache, e ricostruire indirettamente informazioni che non avrebbe dovuto poter leggere.

Questa è la parte che trovo ancora oggi affascinante. Non sto chiedendo alla CPU di restituirmi direttamente una password proibita e non sto necessariamente violando con una normale istruzione i controlli di accesso della memoria, sto facendo eseguire transitoriamente qualche cosa e poi INTERROGO LE TRACCE che quell'esecuzione ha lasciato dietro di sé.

Meltdown: quando crolla il muro fra applicazione e kernel

Meltdown è il più intuitivo dei due da raccontare. In un sistema operativo normale un programma utente non deve poter leggere la memoria riservata al kernel, anche se quella memoria può essere mappata nel suo spazio virtuale secondo modalità che ne impediscono l'accesso. Su CPU vulnerabili, l'esecuzione fuori ordine e speculativa poteva far sì che una lettura non autorizzata producesse per un brevissimo intervallo un valore utilizzabile da istruzioni successive prima che l'eccezione di protezione diventasse effettiva.

Il valore non veniva poi consegnato normalmente al programma, perché l'operazione veniva annullata. Ma poteva essere usato per influenzare la cache e quindi codificare il segreto in un side-channel misurabile. È questa la ragione del nome Meltdown: il confine di protezione che dovrebbe separare applicazione e sistema operativo viene, per così dire, sciolto.

Storicamente Meltdown riguardò soprattutto molti processori Intel con esecuzione fuori ordine ed alcuni core ARM, mentre AMD dichiarò di non essere vulnerabile alla variante classica Rogue Data Cache Load per ragioni legate alla propria architettura di paging. Questo è un punto importante perché Meltdown e Spectre vengono spesso raccontati come se fossero due nomi per la stessa identica falla presente allo stesso modo su qualsiasi CPU, mentre non è così.

Spectre: più sottile e proprio per questo più inquietante

Spectre fa una cosa diversa. Non cerca necessariamente di sfondare il muro fra user mode e kernel, ma sfrutta la predizione e l'esecuzione speculativa per convincere un pezzo di codice legittimo ad accedere transitoriamente ad un dato che, secondo la logica normale del programma, non avrebbe dovuto essere letto in quel punto. Il nome Spectre copre infatti più varianti, fra cui il Bounds Check Bypass e il Branch Target Injection originariamente associati a CVE-2017-5753 e CVE-2017-5715.

Immaginiamo un programma che controlla correttamente che un indice sia dentro i limiti di un array prima di usarlo. Architetturalmente è tutto giusto. Ma se il branch predictor viene addestrato in modo da aspettarsi ripetutamente che il controllo risulti valido, in certe condizioni il processore può iniziare speculativamente l'accesso prima che il controllo sia stato realmente risolto. Quando scopre l'errore annulla tutto. Ma ancora una volta la cache può aver già registrato abbastanza informazioni da permettere all'attaccante di capire quale dato sia stato toccato.

Spectre è quindi più generale e più fastidioso da eliminare definitivamente, perché non dipende da una singola barriera fra kernel ed applicazioni ma dal modo stesso in cui il software e la CPU collaborano per ottenere prestazioni. Intel, AMD ed ARM hanno tutti dovuto affrontare varianti della famiglia Spectre ed ancora nel 2026 continuano ad essere pubblicati lavori che studiano nuove tecniche costruite sopra meccanismi speculativi già conosciuti. Questo non significa che i computer moderni siano tutti apertamente bucati come nel 2018, significa che LA CLASSE DEL PROBLEMA NON È SPARITA.

Serve comunque del codice nemico (malevolo)

Una precisazione che secondo me va fatta perché nei racconti più allarmistici si perde facilmente: Meltdown e Spectre non sono virus che viaggiano autonomamente nella rete e leggono un computer da lontano per magia. Per sfruttare queste debolezze serve che del codice controllato dall'attaccante riesca ad essere eseguito nel contesto utile all'attacco, per esempio come programma locale, codice dentro una sandbox oppure, storicamente per alcune tecniche Spectre, codice eseguito da un browser.

Questo rende fondamentale la distinzione fra vulnerabilità ed exploit. La CPU fornisce il comportamento microarchitetturale sfruttabile, ma qualcuno deve costruire una sequenza di operazioni, creare le condizioni della speculazione, effettuare le misurazioni temporali e ricostruire il segreto. Ed è anche uno dei motivi per cui un antivirus classico non rappresenta una soluzione universale: il side-channel in sé può essere composto da operazioni che singolarmente assomigliano ad attività perfettamente lecite.

L'impatto tipico è la DIVULGAZIONE DI INFORMAZIONI. Queste tecniche nascono per leggere indirettamente dati, non per sovrascrivere da sole un file oppure formattare un disco. Naturalmente un segreto rubato può poi diventare il punto di partenza di ben altri attacchi, ed una chiave crittografica oppure un token di autenticazione valgono spesso molto più della possibilità immediata di modificare un file.

E le altre schede del browser?

Questa è probabilmente una delle domande più interessanti perché rende l'attacco molto concreto. Nel 2018 i browser vennero considerati una superficie importante per Spectre proprio perché JavaScript rappresentava codice non fidato eseguito sul computer della vittima ed i browser moderni gestivano nello stesso processo dati provenienti da origini differenti in alcune circostanze. Un side-channel capace di leggere memoria del renderer poteva quindi minacciare dati che, pur protetti dalle regole logiche del browser, si trovavano dentro lo stesso spazio di indirizzamento.

Dire però oggi che "una pagina Spectre può leggere qualsiasi password, cookie e dato di tutte le altre schede aperte" sarebbe una semplificazione troppo grossa. Il vero confine importante è QUALE MEMORIA È PRESENTE NEL PROCESSO CHE L'ATTACCANTE RIESCE A SCRUTARE. Ed è proprio per questo che Chrome introdusse Site Isolation come difesa molto forte, separando siti differenti in processi distinti e facendo in modo che il renderer di un sito ostile non riceva gran parte dei dati sensibili appartenenti ad altri siti.

Chrome ha Site Isolation attivo per tutti i siti sulle piattaforme desktop fin dalla versione 67, e la stessa filosofia di isolamento per processi è diventata una delle risposte strutturali alla lezione di Spectre. In altre parole non provo soltanto ad impedire il side-channel, cerco anche di fare in modo che, SE QUALCUNO RIESCE A LEGGERE LA MEMORIA DEL PROCESSO, dentro quel processo non ci siano i segreti degli altri siti.

Cookie, password e chiavi: cosa potrebbe essere interessante rubare davvero

Se il codice attaccante riesce ad inferire memoria che contiene dati sensibili, ciò che interessa non è necessariamente il file aperto sul desktop. Possono avere enorme valore token di sessione, porzioni di documenti, credenziali temporaneamente presenti in memoria, materiale crittografico, dati dell'applicazione ed altre informazioni che normalmente dovrebbero restare isolate dal codice non fidato.

Ma bisogna sempre evitare l'idea che Spectre sia una specie di comando universale dump_all_passwords(). L'attacco reale deve trovare un gadget speculativo utile, portare il dato sensibile nella relazione microarchitetturale sfruttabile, misurare un side-channel abbastanza pulito e ricostruire l'informazione. In laboratorio è una dimostrazione potentissima, nel mondo reale entrano rumore, mitigazioni, separazione dei processi, modifiche ai compilatori, microcodice, kernel e contromisure del browser.

La gravità non deriva quindi dal fatto che sia facile leggere tutto, ma dal fatto che è stato dimostrato che alcuni confini considerati FONDAMENTALI non erano impermeabili come si pensava.

Le correzioni a Meltdown hanno cambiato anche il modo in cui il sistema operativo usa la memoria

Una delle mitigazioni più famose contro Meltdown è KPTI (Kernel Page-Table Isolation), nata dall'evoluzione del lavoro KAISER. L'idea è separare in maniera molto più netta le page table utilizzate in user mode da quelle del kernel, evitando di lasciare mappata nel contesto utente gran parte della memoria privilegiata che Meltdown avrebbe potuto tentare di osservare.

Questo comporta però lavoro aggiuntivo quando il processore passa fra spazio utente e kernel ed è il motivo per cui nel 2018 si parlò moltissimo di possibile perdita di prestazioni. L'impatto non era un numero fisso valido per ogni computer, perché dipendeva dalla CPU e soprattutto dal tipo di workload, con carichi che effettuavano moltissime transizioni kernel-user più sensibili rispetto ad applicazioni prevalentemente CPU-bound.

Sulle generazioni successive sono arrivate inoltre mitigazioni hardware e capacità architetturali che permettono al sistema operativo di sapere se una certa CPU è immune ad alcuni dei problemi originali, riducendo in certi casi la necessità di pagare il costo delle contromisure software pensate per i processori vulnerabili.

Spectre ha richiesto una patch molto più impegnativa

Per Spectre non esiste una singola patch equivalente a "chiudi quella mappatura e abbiamo finito". Sono state introdotte tecniche come retpoline, IBRS (Indirect Branch Restricted Speculation), barriere come LFENCE in punti appropriati, controlli sulla speculazione, modifiche ai compilatori ed isolamento dei processi. La mitigazione dipende dalla variante e dal dominio che si vuole proteggere.

Questo è anche il motivo per cui oggi Intel parla esplicitamente di transient execution e pubblica documentazione che distingue diversi scenari di attacco, mentre AMD continua a pubblicare bollettini per nuove ricerche Spectre-class verificando se richiedano nuove mitigazioni oppure ricadano nelle difese già previste. Nell'agosto 2026 AMD ha per esempio classificato una ricerca sullo Speculative Return-Oriented Programming come costruita principalmente sopra Spectre Variant 1, mantenendo valida la propria guida esistente.

Ed Intel, sempre nell'agosto 2026, ha valutato TONTOU come collegato a scenari già documentati di Branch History Injection e Intra-Mode Branch Target Injection, senza indicare nuove mitigazioni. Lo cito perché rende molto bene l'idea: otto anni dopo la divulgazione originale stiamo ancora studiando COME PUÒ ESSERE ABUSATA LA SPECULAZIONE, anche se le difese e l'hardware nel frattempo sono cambiati moltissimo.

Il tuo Windows è protetto? Oggi la domanda va posta in modo un po' diverso

Nel 2018 la risposta tipica era aggiornare Windows, installare il firmware o BIOS più recente ed assicurarsi che il microcodice della CPU contenesse le mitigazioni richieste. Oggi la stessa logica rimane valida, ma non direi mai ad un utente nel 2026 "se hai Windows 10 aggiornato sei quasi certamente a posto" senza aggiungere una grossa nota, perché il supporto ordinario di Windows 10 è terminato il 14 ottobre 2025.

Un Windows 10 può continuare a ricevere aggiornamenti se appartiene ad una edizione con lifecycle ancora valido oppure se il computer è correttamente iscritto al programma ESU (Extended Security Updates). Per i normali PC non iscritti ad ESU invece continuare a vedere Windows Update funzionare non significa essere su un sistema operativo che riceve tutte le nuove correzioni di sicurezza. Ed è una distinzione molto più importante oggi di quanto fosse nella conversazione originale del 2018.

Il controllo ufficiale con PowerShell

Se voglio verificare lo stato delle mitigazioni su Windows preferisco partire dallo strumento ufficiale Microsoft, ovvero il modulo PowerShell SpeculationControl. Microsoft continua a documentarlo sia per Windows 10 sia per Windows 11 e la versione pubblicata nella PowerShell Gallery è la 1.0.19, aggiornata l'11 giugno 2025.

Il controllo può essere avviato da PowerShell installando il modulo e poi interrogando le impostazioni:

BLOCCO0

L'output non contiene soltanto un semplice "Spectre sì/no", perché negli anni il modulo è stato ampliato per riportare lo stato delle mitigazioni di più vulnerabilità di speculative execution e microarchitettura. Le voci relative a CVE-2017-5715 identificano il Branch Target Injection di Spectre v2, CVE-2017-5754 riguarda il Rogue Data Cache Load associato a Meltdown ed altre sezioni mostrano mitigazioni successive come Speculative Store Bypass, L1TF, MDS e problemi MMIO.

Microsoft specifica che le protezioni abilitate vengono mostrate come True, ma NON BISOGNA PRENDERE OGNI False COME PROVA AUTOMATICA CHE IL PC SIA VULNERABILE, perché alcune mitigazioni possono non essere richieste su una particolare CPU oppure il processore può dichiarare di non essere affetto da quella classe specifica. L'output va quindi letto insieme alla voce che spiega se l'hardware è vulnerabile e se il supporto hardware o del sistema operativo è presente.

Firmware e microcodice contano quanto Windows

Una parte delle mitigazioni Spectre richiede capacità che il sistema operativo utilizza attraverso il microcodice della CPU. Questo microcodice può arrivare tramite aggiornamenti del BIOS o UEFI del produttore del computer oppure, per alcune piattaforme e vulnerabilità, attraverso meccanismi di aggiornamento distribuiti dal sistema operativo.

Per questo limitarsi a dire "ho installato le patch Windows" non descrive sempre lo stato completo della macchina. Il controllo serio è sistema operativo supportato ed aggiornato, firmware aggiornato, microcodice corretto e mitigazioni effettivamente abilitate per quella CPU. È proprio ciò che strumenti come SpeculationControl cercano di rendere leggibile senza costringere l'utente a conoscere ogni MSR del processore.

E il vecchio InSpectre?

Nel periodo immediatamente successivo alla divulgazione divenne molto popolare InSpectre di GRC (Gibson Research Corporation), piccola utility di Steve Gibson che forniva un verdetto rapido su Meltdown, Spectre e sull'impatto prestazionale delle mitigazioni. È uno strumento storico legittimo e non va confuso con un malware soltanto perché è un eseguibile scaricabile.

Ma oggi io partirei dal modulo Microsoft. La ragione non è che InSpectre sia improvvisamente diventato pericoloso, ma che quando devo controllare nel 2026 uno stato di mitigazione che negli anni si è allargato ben oltre le tre vulnerabilità originali preferisco uno strumento mantenuto dentro l'ecosistema Windows e documentato da Microsoft. È anche una buona regola generale di sicurezza: prima di scaricare un .exe suggerito da una pagina web, controllo se esiste un metodo ufficiale che mi permette di ottenere la stessa informazione.

Antivirus e log: perché questa categoria di attacco è strana

Il sito dei ricercatori originali sottolineava già nel 2018 che distinguere l'esecuzione di Meltdown o Spectre da un programma benigno non è semplice e che un attacco può non lasciare le tracce alle quali siamo abituati nei normali log. Un antivirus può naturalmente riconoscere un malware noto che contiene un exploit conosciuto, ma non può trasformare magicamente la cache della CPU in una barriera di sicurezza.

Questa è un'altra ragione per cui le mitigazioni sono state applicate in profondità, modificando hardware, microcodice, kernel, compilatori e browser invece di delegare tutto al software antivirus. È la classica defense in depth, solo che questa volta gli strati da correggere partivano dal silicio ed arrivavano fino al JavaScript.

Perché continuo a chiamarle la madre di tutte le vulnerabilità

La cosa più importante che Meltdown e Spectre ci hanno lasciato non è il logo col processore che si scioglie oppure il fantasma con il ramo, per quanto siano diventati due simboli perfetti di quella stagione. È l'idea che LA SICUREZZA ARCHITETTURALE NON BASTA SE LA MICROARCHITETTURA PARLA DI NASCOSTO.

Un controllo dei permessi può funzionare correttamente, un'istruzione illegale può essere annullata, il programma può non ricevere formalmente nessun dato proibito e tuttavia il tempo impiegato da una successiva lettura può raccontare ciò che è successo durante un'esecuzione che secondo il modello ufficiale non avrebbe dovuto lasciare alcun risultato. È un cambio di prospettiva enorme, perché costringe a considerare cache, predictor, buffer e speculazione come parte della superficie di sicurezza.

Meltdown era in un certo senso più brutale e più semplice da chiudere con isolamento delle page table e hardware successivo. Spectre invece ha meritato fin troppo bene il proprio nome, perché continua a riapparire come principio dentro ricerche nuove e costringe ancora oggi a ragionare su quali segreti condividano lo stesso dominio di esecuzione con codice non fidato.

Ed alla fine è proprio questo che rende tutta la storia così importante anche per chi non scrive kernel o microcodice: ci ricorda che un computer non è soltanto il modello pulito che vediamo nel manuale di programmazione. Sotto esiste una macchina fisica che prevede, anticipa, memorizza, sbaglia e lascia tracce, ed a volte, guardacaso, per rubare un segreto non serve aprire la porta, ma basta misurare l'ombra che ci passa sotto . . .