Spectre e Meltdown sono indubbiamente la notizia di queste ore. I bug resi pubblici dai ricercatori di Google Project Zero hanno infatto molto da far discutere: sono decisamente importanti - c'è chi li ha già definiti come un momento cruciale nella storia della sicurezza informatica - e non è immediato a tutti come funzionino, quali processori colpiscano e come si possano eliminare. Il tema tecnico sottostante non è banale e i vendor coinvolti non sono stati, secondo i critici, molto trasparenti nell'affrontare la crisi e nello spiegare come e perché i loro prodotti sarebbero coinvolti o meno.

Come funzionano Spectre e Meltdown? Come spiegano i ricercatori, si tratta in effetti di tre varianti di uno stesso problema, derivante paradossalmente da una funzione molto utile per l'esecuzione veloce delle applicazioni: la possibilità di eseguire le istruzioni in maniera non sequenziale. Si tratta della cosiddetta speculative execution: quando il flusso di controllo di un programma varia in funzione di una condizione che richiede qualche ciclo per definirsi, il processore "ipotizza" quali istruzioni saranno eseguite dopo quella attuale, le carica dalla memoria e le esegue. Se l'ipotesi è corretta ha risparmiato tempo, altrimenti annulla le operazioni eseguite, ritorna allo stato precedente e carica le istruzioni realmente necessarie.



Spectre e Meltdown sfruttano in modi diversi una vulnerabilità della speculative execution che non appare a livello logico ma che evidentemente esiste: è possibile ingannare una CPU sfruttando le sue funzioni predittive e, così, accedere a zone della memoria che appartengono al kernel del sistema operativo. Questo permette ad esempio di accedere ai dati di altri processi e di altre macchine virtuali in un sistema virtualizzato (anche in un ambiente cloud). In questo sta la minaccia della variante denominata Meltdown.

Spectre è un exploit molto più insidioso perché potenzialmente più diffuso e molto più complesso da eliminare. Ne esistono due varianti: la prima permette a un processo di estrarre informazioni da altri processi, anche in ambienti virtualizzati; la seconda di ricavarle dal processo stesso, cosa che sembra inutile ma che ha un'applicazione molto importante (il codice JavaScript di una pagina web può ad esempio leggere tutta la memoria del browser che l'ha caricata). Spectre è più complesso da realizzare rispetto a Meltdown, per fortuna, ma secondo i ricercatori per debellarlo completamente serve un redesign dell'architettura dei processori e una rivisitazione dei loro set di istruzioni.

A che punto siamo con Spectre e Meltdown

I ricercatori hanno dimostrato che Meldown colpisce tutti i processori Intel che usano la speculative execution, in primis tutti quelli a 64 bit prodotti dal 2011 in poi. Tocca anche i processoti ARM basati sui core Cortex A15, A57, A72 e A75. Quindi device mobili, desktop, server, portatili, subnotebook... tutti sono potenziali bersagli tranne - almeno per ciò che si sa al momento - i sistemi che adottano processori AMD. Le maggiori software house hanno già distribuito patch dei loro sistemi operativi che bloccano Meltdown, anche se queste patch hanno putroppo un impatto sulle prestazioni del sistema così protetto.

Queste patch vanno applicate anche alle macchine virtuali in ambienti cloud, cosa che i principali cloud provider stanno già facendo direttamente o stanno esplicitamente invitando i loro utenti a fare, quando necessario.



Spectre è, come accennato, questione più complessa. In teoria può interessare qualsiasi processore Intel, AMD o ARM con speculative execution, nella pratica sono stati creati exploit di test per processori Intel Xeon di generazione Haswell, AMD di tipo FX e PRO, ARM Cortex A57. Alcune patch sono già in fase di sviluppo per contenere i possibili danni di Spectre, specialmente per la seconda versione e per il pericolo che rappresenta sul Web.

L'opinione più diffusa tra i tecnici indipendenti è però che Spectre sia un problema di grande portata, dato che si tratta di una vulnerabilità potenziale della microarchitettura dei processori e non dei sistemi operativi. Si può limitare con patch degli OS e ricompilando le applicazioni perché siano più sicure (il che richiede aggiornamenti ai compilatori stessi) ma spinge probabilmente anche a una rivisitazione del modello architetturale standard.