Nelle scorse ore Apple ha rilascito le patch per i suoi sistemi operativi (qui per macOS e qui per iOS) che rendono sicure le due piattaforme. Più o meno tutti i produttori di sistemi operativi stanno facendo lo stesso. Se gli apparecchi con processori realizzati negli ultimi venti anni sono aggiornati dal lato software, la possibilità per un attaccante di creare un exploit funzionante per questa vulnerabilità scoperta dai ricercatori di Google (che secondo Intel colpisce tutti i produttori di CPU) è ridotta al minimo o a zero. Apple dal canto suo aveva già realizzato un aggiornamento e protetto anche Safari per la percentuale di insicurezza che lo riguarda.
A questo punto sono aperti due fronti di discussione. Il primo è relativo alle conseguenze (e anche al comportamento apparentemente scorretto del Ceo di Intel, che avrebbe venduto 24 milioni di dollari in azioni dell’azienda prima dell’annuncio delle vulnerabilità), l’altro alle cause. Entrambi sono interessanti. Una prima conseguenza indiretta di questa vulnerabilità è quella relativa alle performance dei processori, come vedremo tra un attimo. Perché le patch che risolvono il problema impattano sul modo in cui funzionano le moderne CPU e sono foriere di rallentamenti e peggioramenti della qualità del lavoro del processore. C’è chi sta rilevando un crollo prestazionale “impressionante” per quanto riguarda i server, e non solo i personal computer, colpiti ad esempio in ambiente Windows per i giochi DirectX fino al 30%.
E veniamo al punto centrale, cioè il funzionamento effettivo di questo problema di sicurezza e le sue conseguenze. La base è molto semplice: negli anni le CPU sono state costruite da Intel, AMD, ARM e dagli altri produttori avendo in mente soprattutto modi per dare più prestazione e non per la sicurezza. Questa vulnerabilità, di cui Spectre e Meltdown sono due manifestazioni dello stesso problema, deriva dall’hardware del calcolo, non dal sistema operativo o dalle applicazioni.
Il punto centrale è la performance: i processori moderni per funzionare al massimo della velocità cercano di ottimizzare ed evitare i colli di bottiglia. Questo vuol dire che le CPU cercano di evitare lo stato in cui “aspettano”, prendendo decisioni basate su inferenza statistica su calcoli di bassissimo livello: questa tecnologia si chiama “esecuzione speculativa”. Cosa vuol dire: le CPU cercano di svolgere in anticipo entrambe le operazioni di calcolo e memoria che si possono presentare durante l’esecuzione di un programma, e poi mantengono quella che effettivamente serve e scaricano quell’altra dalla cache. Dato che i processori hanno più centri di calcolo questo modo è più efficiente perché consente di sfruttare al massimo l’architettura multicore del processore e ottenere un funzionamento complessivamente più rapido.
Qual è il problema: eseguendo parti di codice che poi non servono e vengono scaricate, il processore viola una divisione degli spazi della memoria fondamentale: lo spazio utente e quello del kernel, cioè del sistema. Con tecniche di programmazione sofisticate si possono iniettare operazioni che “scoprono” gli indirizzi della memoria utilizzati per questi calcoli e registrati nella cache, che poi verranno scaricati, e che vengono passate indietro al programma dell’attaccante. In questo modo, sia con software locali che con attacchi ai browser tramite l’esecuzione remota con JavaScript, si può utilizzare la funzionalità di parallelizzazione del calcolo predittivo (dell’esecuzione speculativa) per “saltare” al di fuori della sandbox di un singolo programma e attaccare il resto della memoria.
Gli attacchi possono essere di due tipi: possono “sciogliere” la barriera che separa lo user space dal kernel space (questo è il caso di “Meltdown”, che “fonde” la barriera tra i due) oppure l’attaccante riesce a passare dalla sua app alle altre app, separate dalla sandbox, una barriera che viene invece penetrata come se si avesse a che fare con un fantasma che passa attraverso i muri (da cui il nome “Spectre”).
Vedendola in un altro modo, come suggerisce ad esempio l’autore di XKCD, l’approccio che i designer delle CPU hanno utilizzato per l’esecuzione speculativa ricorda quello dell’etica e della meccanica quantistica: il problema del tram (o “trolley problem”). Come spiega Wikipedia
un autista di un tram conduce un veicolo capace solo di cambiare rotaia (tramite deviatoio), senza la possibilità di frenare. Sul binario percorso si trovano cinque persone legate e incapaci di muoversi e il tram è diretto verso di loro. Tra il tram e le persone legate si diparte un secondo binario parallelo, sul quale è presente una persona legata e impossibilitata a muoversi. La persona nei pressi del deviatoio si trova di fronte un’alternativa che comporta due sole opzioni: lasciare che il tram prosegua dritto la sua corsa, uccidendo le cinque persone, oppure azionare lo scambio e ucciderne una sola.
La soluzione dei progettisti di CPU è stata quella di spedire due tram su entrambi i binari, mentre aspettano la scelta del software su quale istruzione debba essere effettivamente eseguita, e poi cancellare il “tram fantasma”, cioè il calcolo non necessario, una volta che è stata presa la decisione. Il tram fantasma dovrebbe scomparire e non lasciare conseguenze, ma per il modo con il quale sono progettate le CPU (con buffer e cache di memoria di vari livelli per accelerare l’esecuzione delle istruzioni) in realtà si può continuare a guidare il tram verso spazi di memoria riservati al sistema operativo o alle altre applicazioni.
Esistono decine di altre vulnerabilità che hanno a che fare con l’architettura hardware dei processori e dei computer oppure delle loro memorie Ram, come ad esempio Rowhammer: mettendo una fila di celle di memoria della Ram a cui si ha accesso su on e off (1 e 0) molto rapidamente, è possibile utilizzare una forma di inferenza elettrica per cambiare lo stato (1 e 0) di altre celle di memoria fisicamente contigue e prendere quindi possesso di altri indirizzi di memoria protetti. Una vulnerabilità scoperta nel 2015 che permette ad esempio di guadagnare il controllo come root dei telefoni Android. Anche qui, come per Meltdown e Spectre, il problema è aver pensato alle performance dell’hardware e non alla sua sicurezza.
