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.