Due vulnerabilità mettono in pericolo la nostra privacy e i nostri dati. Ecco come funzionano e cosa rischiamo.
È di pochissimi giorni fa la notizia di due vulnerabilità presenti praticamente in tutti i microprocessori prodotti negli ultimi 15 anni, con effetti sulla sicurezza e sulla nostra privacy davvero molto seri.
Tecnicamente le due vulnerabilità, simili ma non identiche, infrangono uno dei paradigmi alla base dei moderni sistemi computazionali, permettendo la violazione dei confini della memoria tra applicazioni e sistema operativo e tra applicazione e applicazione, esponendoci a rischi potenzialmente catastrofici.
Come è consuetudine entrambe sono state dapprima catalogate secondo gli standard MITRE come Commoun Vulnerability Exposure (o CVE), nello specifico rispettivamente CVE-2017-5754 e CVE-2017-5753/CVE-2017-5715 e successivamente battezzate con un termine semplice e autoesplicativo basato sulle proprie caratteristiche. In questo caso abbiamo quindi a che fare con Meltdown (scioglimento, in questo caso delle barriere di protezione della memoria) e Spectre (spettro, difficile da vedere, nascosto e sfuggente) che in virtù della propria natura pare ci terranno purtroppo compagnia molto a lungo. Sono stati creati due siti speculari per il rilascio di informazioni tecniche e aggiornate ai seguenti indirizzi: https://meltdownattack.com/ e https://spectreattack.com/
Entrambe le vulnerabilità derivano da un difetto di progettazione a livello hardware, quindi nei circuiti logici interni dei microprocessori che equipaggiano i nostri device, e risultano pertanto impossibili da correggere definitivamente senza sostituire fisicamente il componente. Peraltro al momento non esistono microprocessori moderni non affetti da almeno una delle due vulnerabilità, lasciandoci quindi la solo possibilità di intervenire con alcune correzioni sul software dei nostri sistemi operativi che ne mitigano (ma non ne eliminano completamente) gli effetti.
Meltdown colpisce i processori basati su architettura x86 prodotti da Intel, Spectre sia i processori x86 prodotti da Intel, sia quelli x86 prodotti da AMD (in misura minore) sia alcuni con architettura ARM serie cortex A-*, prodotti su licenza da moltissimi produttori, tra i quali spiccano i big del settore mobile coem Qualcomm, Samsung, Apple e Huawei.
Per comprendere il funzionamento delle due vulnerabilità è necessario qualche cenno di architettura degli elaboratori, senza la pretesa di essere in questa sede rigorosi o esaustivi ma fornendo le nozioni sufficienti ad apprezzare la materia.
Cenni di architettura degli elaboratori
Qualsiasi device moderno è contraddistinto dalla possibilità di poter utilizzare più applicazioni contemporaneamente: lo facciamo con il nostro pc passando da un programma all’altro senza la necessità di terminare il precedente, lo facciamo con il nostro smartphone passando da un’app all’altra con un semplice gesto. Ciò implica che il nostro dispositivo, e nello specifico il suo microprocessore (CPU), sia in grado di capire quale applicazione sia al momento in uso e quale momentaneamente resti aperta ma dormiente, gestendo il sistema in maniera coerente con quanto richiesto dall’utente.
(1) In questo caso specifico ci interessa sapere che per realizzare questo comportamento la CPU istruisce il sistema operativo al fine di dividere la memoria di sistema in più parti, una dedicata al sistema operativo stesso e le altre dedicate ognuna a una diversa applicazione in esecuzione, con la regola fondamentale che nessuna delle applicazioni possa leggere la parte di memoria riservata al sistema operativo o ad un’altra applicazione.
Questo è necessario per ovvi motivi di sicurezza: avrebbe infatti esiti potenzialmente tragici il fatto che un qualsiasi processo, anche una semplice pagina web aperta nel browser potesse comandare altre applicazioni o leggere (e magari comunicare a terzi) la nostra password che stiamo inserendo altrove, o i nostri codici con i quali stiamo verificando un’operazione bancaria sul sito del nostro istituto di credito.
Quando la CPU esegue una qualsiasi operazione per conto di una applicazione non fa altro che prendere un dato dalla parte di memoria di sistema riservata ad essa, elaborarlo e memorizzarlo nuovamente in un’altra locazione di memoria sempre di proprietà della suddetta applicazione, (2) sollevando una eccezione e rifiutandosi di eseguire il comando qualora le fosse indicata una locazione di memoria non opportuna.
(3) In caso di computazioni ricorrenti o operazioni sui dati particolarmente lunghe si utilizza una ulteriore memoria integrata nella CPU, la cosiddetta “cache”, di ridotte dimensioni ma molto veloce, collocata tra la CPU e la memoria di sistema e che permette di risparmiare molto tempo rispetto ad uno o magari più accessi alla memoria di sistema stessa.
Un altro comportamento che è necessario conoscere è la cosiddetta esecuzione (4)”out-of-order”, letteralmente “fuori ordine”. La nostra CPU ha diverse operazioni da compiere in sequenza secondo quanto stabilito da un determinato programma in esecuzione. Può tuttavia accadere che la CPU si ritrovi in attesa di un dato necessario (magari un comando dell’utente) per completare un’operazione: per non sprecare tempo utile mette temporaneamente da parte l’operazione in sospeso ed esegue la successiva, in attesa di completare la precedente quando il dato sarà disponibile.
Un’estensione dell’esecuzione out of order è la cosiddetta (5)”speculative execution”, letteralmente “esecuzione speculativa”. Se nell’esecuzione out of order la CPU passa all’operazione successiva quando si accorge di essere in attesa di un dato che non arriva, con il meccanismo della speculative execution la CPU leggendo l’elenco delle operazioni da compiere capisce già di dover saltare direttamente ad una operazione successiva perchè sulla base di precedenti computazioni ipotizza che una determinata operazione la lascerà in sospeso.Entrambe le tecniche trattano dunque operazioni “in sospeso” (6) e quindi fanno un utilizzo molto aggressivo della memoria cache, che trova il maggior vantaggio di utilizzo proprio in questi casi. L’esecuzione out of order e la speculative execution sono anche alla base delle performances elevate che vantano i sistemi moderni grazie a sistemi di parallelismo molto avanzati (quasi tutte le CPU hanno al loro interno differenti unità di elaborazioni distinte, i cosidetti “cores”) e il loro impiego è quindi divenuto fondamentale.
Come funzionano Meltdown e Spectre
La recente scoperta mette tuttavia in luce limiti importanti dell’esecuzione out of order e della speculative execution applicati alle architetture più moderne.
Per quanto detto sopra sappiamo che i dati transitano dalla memoria di sistema alla CPU e viceversa, a volte transitando nella cache, sempre senza violare i confini di memoria (2) opportunamente suddivisa (1).
Può accadere tuttavia che durante una esecuzione out of order (4) o speculative (5) la CPU salti ad una istruzione che chieda di violare tali confini, evento non necessariamente volontario nè pericolo in quanto comunemente scongiurato dal controllo della CPU al momento della scrittura del dato in memoria (2), ma non prima che il dato sia scritto nella memoria cache, che per natura sappiamo essere utilizzata in maniera aggressiva da queste due tecniche (6).
I recenti studi dimostrano che è possibile effettuare un attacco confezionando un programma malevolo ad hoc che stimoli le esecuzioni di comandi out of order o speculative in modo da leggere parti di memoria non di propria competenza caricandoli nella memoria cache (e quindi prima che la CPU effettui il controllo di appartenenza). Da qui, sfruttando la velocità e i tempi di risposta noti per design della memoria cache, già oggetto di altre vulnerabilità note, è possibile recuperare tali informazioni con un secondo programma malevolo in esecuzione, forzando la cancellazione e la riscrittura della memoria cache. Il risultato è il recupero o l’alterazione di dati di proprietà del sistema operativo o di un’altra applicazione.
Quali rischi affrontiamo e come possiamo difenderci
Potenzialmente siamo di fronte a rischi incalcolabili, qualsiasi programma in esecuzione su un nostro device può accedere ai dati di un altro programma in esecuzione sullo stesso dispositivo.Questo non vale solo per i nostri dispositivi personali dove programmi attivi contemporaneamente possono spiarsi l’un l’altro ma vale anche per i grandi provider e per i servizi cloud, sui singoli server dei quali sono in esecuzione istanze di programmi appartenenti a clienti diversi: una qualsiasi applicazione che condivide una macchina fisica con un’altra applicazione può potenzialmente leggere le informazioni di quest’ultima.
In pratica però è utile ricordare che sebbene gli effetti delle due vulnerabilità siano potenzialmente gravissimi si tratta in ogni caso di attacchi molto complessi da condurre e al momento sembra che difficilmente potranno colpire il singolo dispositivo dell’utente privato, non ci sarebbe una giustificazione economica nel farlo. Discorso invece molto diverso invece per le realtà aziendali o i sistemi condivisi dei provider.
Le armi a nostra disposizioni sono poche. Nell’impossibilità di intervenire direttamente sull’hardware e nell’evidenza di un lungo tempo di progettazione per CPU immuni a tali rischi possiamo solo affidarci ai produttori dei maggiori sistemi operativi, che hanno già tempestivamente rilasciato e continueranno a rilasciare aggiornamenti utili a mitigare le vulnerabilità, introducendo controlli più stretti sulle operazioni out of order o speculative e/o modificando il loro utilizzo della memoria cache. Intel, la più colpita, ha anche iniziato a rilasciare aggiornamenti per il microcode delle proprie CPU. Appare in ogni caso evidente che all’aumentare dell’efficacia di tali misure di contenimento si avrà un collaterale decadimento di prestazioni date le caratteristiche tecniche delle CPU al momento in commercio.
Il rilascio di informazioni e la polemica
Vulnerabilità come queste non vengono annunciate alla leggera: di norma a seconda dalla criticità esiste una sorta di embargo che si autoimpongono gli scopritori, utile a informare le parti coinvolte e porvi rimedio prima del rilascio pubblico di informazioni che potrebbero dare il via a un’ondata di malware che le sfrutti. Non c’è nulla di poco chiaro o sospetto in questo, ed è il motivo per il quale le scoperte di questo genere sono note ad una cerchia ristretta di esperti del settore prima che la notizia sia di dominio pubblico.
Anche in questo caso i ricercatori coinvolti hanno informato i produttori di CPU che si sono coordinati con i produttori di sistemi operativi per mitigarne gli effetti.
Tuttavia è sospetto il comportamento del CEO di Intel che ha venduto tutte le azioni delle quali poteva legalmente disfarsi senza una comunicazione pubblica con tempistiche che potrebbero lasciar intendere una conoscenza pregressa del problema e un tentativo di insabbiamento. Ma sarà una vicenda da dibattere ampiamente e ancora tutta da dimostrare.
Cosa ci insegna questa storia
Le recenti scoperte insegnano che la sicurezza e la privacy devono essere i primi criteri di progettazione di qualsiasi sistema fin nella sua più elementare implementazione e che non possono mai essere messe in secondo piano in nome delle prestazioni. Il concetto di privacy by design imposto solo recentemente dal legislatore assume drammaticamente in questo un caso un carattere fondamentale, imponendosi prepotentemente come concetto cardine e insostituibile non solo delle infrastrutture ad alto livello deputate alla raccolta dei dati ma anche dei mattoni fondamentali che vanno a costituirne le fondamenta.
Nonostante gli sforzi di diversi produttori per mitigare l’impatto di queste vulnerabilità resterà il problema, come sempre, dei devices poco mantenuti dai propri utilizzatori o, nel caso di device mobili, dimenticati invece dai produttori, che continueranno per tutta la propria vita utile a presentare queste così come altre vulnerabilità mai risolte.
Casi di questo tipo dovrebbero far nascere nel consumatore un interesse verso la serietà del costruttore del proprio dispositivo, e verso il rispetto da parte sua dei criteri di sicurezza e privacy by design. Concetti che spesso entrano in collisione con la convenienza economica, che sempre più spesso e a torto è l’unico driver nell’acquisto di devices ai quali affidiamo di fatto la nostra vita.
