Vai al contenuto
LF Lomazzi Federico

Home/Appunti/Sicurezza

Sicurezza

Spectre e Meltdown per 20 anni dentro quasi tutte le CPU del mondo..

Lomazzi Federico 5 min di lettura

Perché non erano normali bug del software ma effetti collaterali profondamente nascosti nella microarchitettura delle CPU, nati dalle tecniche usate per renderle più veloci. La speculative execution e la branch prediction eseguivano in anticipo istruzioni che poi venivano annullate, ma lasciavano tracce misurabili nella cache. Da quelle tracce Spectre e Meltdown riuscivano ad estrarre dati che, teoricamente, avrebbero dovuto restare inaccessibili.

Logo ufficiale di Spectre, la vulnerabilità legata all'esecuzione speculativa

Se avete usato un computer costruito negli ultimi trent'anni saprete certamente che, ad ogni nuova generazione, le CPU sono diventate enormemente più veloci anche senza aumentare nella stessa misura la frequenza di clock, e dietro a questo risultato c'è una quantità impressionante di trucchi microarchitetturali che per anni abbiamo considerato semplicemente geniali. Uno dei più importanti è la speculative execution, ovvero l'esecuzione speculativa, con la quale il processore prova ad indovinare quale strada prenderà un programma ed inizia ad eseguire in anticipo le istruzioni che pensa serviranno; se la previsione è corretta abbiamo guadagnato tempo, se è sbagliata la CPU cancella il risultato e riparte dal percorso giusto. A questo si aggiunge la branch prediction, cioè la previsione dei salti, che cerca di capire in anticipo quale ramo di un programma verrà percorso. Per decenni il ragionamento è stato abbastanza semplice: se un'istruzione eseguita per errore viene poi annullata prima di diventare visibile al programma, dal punto di vista della sicurezza è come se non fosse mai esistita. Ed era proprio QUI che si nascondeva il problema.

Nel 2017 gruppi di ricercatori indipendenti, fra i quali Jann Horn del Google Project Zero, Paul Kocher ed i ricercatori della TU Graz, arrivarono a dimostrare che quell'istruzione speculativa poteva sì essere cancellata dal punto di vista logico, ma non cancellava necessariamente tutte le conseguenze fisiche prodotte dentro il processore, in particolare quelle lasciate nella cache. In pratica il programma non poteva leggere direttamente un dato protetto, però poteva costringere la CPU a toccarlo durante una speculazione e poi misurare con estrema precisione quanto tempo impiegava ad accedere a determinate zone della cache, ricostruendo indirettamente l'informazione. È un side-channel, ovvero un canale laterale, ed il concetto è quasi assurdo se lo pensiamo in termini normali: la porta resta chiusa, nessuno vi consegna la chiave e nessuno vi mostra cosa c'è nella stanza, ma riuscite ugualmente a capirlo osservando le impronte lasciate sul pavimento da qualcuno che è entrato per una frazione di secondo.

Meltdown e Spectre, però, non sono la stessa cosa. Meltdown sfrutta l'esecuzione fuori ordine e speculativa per superare in determinate CPU la separazione fondamentale fra applicazioni e memoria del sistema operativo, arrivando a leggere dati del kernel che un normale programma non dovrebbe poter vedere; il sito ufficiale dei ricercatori indicò come potenzialmente interessati praticamente tutti i processori Intel con out-of-order execution a partire dal 1995, con alcune eccezioni, mentre alcune implementazioni ARM risultarono anch'esse coinvolte. Spectre è ancora più generale e per certi versi più inquietante perché non si limita a rompere quella specifica barriera, ma induce un altro programma ad eseguire speculativamente operazioni che finiscono per rivelare i suoi stessi dati attraverso la cache, sfruttando meccanismi presenti in processori Intel, AMD ed ARM. Ed è proprio per questo che quando nel gennaio 2018 il problema divenne pubblico ci si rese conto che non riguardava semplicemente qualche modello sfortunato, ma una delle idee fondamentali con cui erano state progettate per anni quasi tutte le CPU ad alte prestazioni, dai PC ai server fino agli smartphone.

Qui però occorre fare una precisazione, perché dire che questi bug siano rimasti SEGRETI per vent'anni può far pensare che Intel, AMD, ARM o qualcun altro li conoscesse e li avesse deliberatamente nascosti, ed almeno sulla base delle informazioni pubbliche non abbiamo prove di questo. È più corretto dire che la debolezza è rimasta NASCOSTA dentro un comportamento microarchitetturale considerato normale, mentre le tecniche che la rendevano possibile erano sotto gli occhi di tutti ed erano documentate da anni. Il salto concettuale dei ricercatori fu capire che due mondi che normalmente venivano ragionati separatamente, ovvero la correttezza architetturale da una parte ed i tempi fisici della cache dall'altra, potevano essere messi insieme per trasformare una previsione sbagliata e teoricamente cancellata in una perdita reale di informazioni. Google Project Zero comunicò le vulnerabilità ad Intel, AMD ed ARM il primo giugno 2017, poi iniziò il lavoro coordinato e sotto embargo per preparare le mitigazioni prima della divulgazione pubblica del 3 gennaio 2018.

Ed a quel punto iniziò una corsa gigantesca perché una cosa del genere non si sistema come si corregge un errore dentro un'applicazione. Per Meltdown arrivarono modifiche ai sistemi operativi come KPTI, ovvero Kernel Page Table Isolation, che separavano maggiormente le tabelle delle pagine del kernel da quelle dei processi utente; per Spectre arrivarono microcode, barriere alla speculazione, modifiche ai compilatori e tecniche come Retpoline, con una quantità enorme di aggiornamenti distribuiti da produttori di CPU, sistemi operativi, browser, cloud provider e software. Le prestazioni potevano subire un impatto variabile a seconda del carico perché alcune contromisure, in pratica, costringevano il processore ad essere meno aggressivo proprio in quelle ottimizzazioni che lo avevano reso veloce. Ma Spectre era ed è più complicato da chiudere definitivamente, perché non descrive soltanto una singola falla bensì una famiglia di attacchi che sfruttano comportamenti speculativi e canali laterali, tanto che negli anni successivi sono comparsi nuovi studi, varianti ed ulteriori mitigazioni.

La parte che ancora oggi trovo incredibile è questa: per oltre vent'anni abbiamo avuto dentro milioni e poi miliardi di processori un confine di sicurezza che sembrava solidissimo perché, a livello del programma, funzionava davvero, mentre sotto quel livello la CPU eseguiva istruzioni che non avrebbe dovuto eseguire, le cancellava e lasciava comunque abbastanza tracce da permettere ad un attaccante di ricostruire informazioni riservate. Non era necessario rompere la crittografia, modificare il sistema operativo o trovare una password, bastava riuscire ad osservare il tempo impiegato da una memoria cache e trasformare differenze di pochi nanosecondi in dati. Spectre e Meltdown ci hanno ricordato una cosa che nell'informatica tendiamo ogni tanto a dimenticare, ovvero che anche quando il software dice che qualcosa NON È SUCCESSO l'hardware può avere lasciato una traccia del fatto che, per una frazione infinitesima di secondo, è successo davvero!

Logo ufficiale di Meltdown, la vulnerabilità che supera l'isolamento fra applicazioni e memoria del kernel
Logo ufficiale di Meltdown, la vulnerabilità che supera l'isolamento fra applicazioni e memoria del kernel
23 visite

Fonti

  1. Meltdown and Spectre, sito ufficiale dei ricercatori spectreattack.com
  2. Google Project Zero, Reading privileged memory with a side-channel projectzero.google
  3. Meltdown: Reading Kernel Memory from User Space, paper originale meltdownattack.com
  4. Spectre Attacks: Exploiting Speculative Execution, paper originale spectreattack.com
  5. Intel Security Advisory INTEL-SA-00088 www.intel.com
  6. Google, Answering your questions about Meltdown and Spectre blog.google

Commenti

Nessun commento, per ora.

Per commentare serve un accesso. Qui siamo tutti tecnici e colleghi!

Accedi per commentare

Scarica