CPU Intel, un nuovo attacco prende di mira il ring bus. Niente paura
Con un attacco ribattezzato Lord of the Ring(s), un trio di ricercatori evidenzia una nuova vulnerabilità nelle CPU Intel degli scorsi anni. Questa volta a essere preso di mira da un attacco side channel è il ring bus, l'interconnessione che mette in comunicazione le varie parti di una CPU.
di Manolo De Agostini pubblicata il 08 Marzo 2021, alle 17:41 nel canale ProcessoriIntelCore
Un gruppo di ricercatori della University of Illinois at Urbana-Champaign, di cui fa parte anche l'italiano Riccardo Paccagnella, ha pubblicato uno studio intitolato "Lord of the Ring(s): Side Channel Attacks on the CPU On-Chip Ring Interconnect Are Practical" in cui si evidenzia l'esistenza di una nuova vulnerabilità delle CPU Intel, più precisamente i progetti Coffee Lake e Skylake (la dimostrazione è avvenuta su un Core i7-9700 e un Core i7-6700K).
L'attacco (side channel) permette di ottenere dati sensibili dal cosiddetto "ring bus", un'interconnessione introdotta da Intel con la microarchitettura Nehalem-EX e alla base della maggior parte dei processori dell'azienda degli ultimi anni. Questa interconnessione ad alto bandwidth on-die consente a tutti i componenti della CPU di "parlarsi" tra loro: core, cache LLC, l'uncore (system agent) e la GPU integrata.
Questo nuovo attacco consente di monitorare il tempo che passa tra la pressione di un tasto e un'altra, quindi in teoria potrebbe favorire la ricostruzione di una password e/o altre informazioni. Inoltre, può agevolare l'estrazione di bit crittografici dalle implementazioni di EdDSA e RSA già vulnerabili agli attacchi side channel.
Quanto è pericolosa questa vulnerabilità? Non molto, tanto che è stata classificata da Intel come a basso rischio e inserita nella gamma di attacchi side channel tradizionali (per cui Intel prevede diverse contromisure, come indicato qui e qui). Bisogna inoltre aggiungere che la stessa società - insieme alla National Science Foundation - ha supportato questa ricerca. Solo un malintenzionato molto esperto può mettere a segno un attacco di questo tipo, e al tempo stesso deve avere accesso fisico al dispositivo da colpire e svolgere codice senza privilegi.
L'attacco è molto complesso perché è necessario sapere come funziona il ring bus della CPU Intel, e questa non è un'informazione di dominio pubblico, ma richiede del reverse engineering. Inoltre, Lord of the Ring(s) è un attacco basato su contese che richiede di monitorare la latenza di diversi processi che accedono simultaneamente alla memoria. Un compito nient'affatto semplice, poiché ci sono molti processi che creano un "rumore" significativo che deve essere identificato e filtrato, e gli eventi importanti, come i mancati riscontri (miss) nella cache privata, non sono così comuni.
"Abbiamo introdotto il primo attacco side-channel microarchitetturale che sfrutta la contesa sull'interconnessione ring della CPU. Ci sono due sfide che rendono particolarmente difficile sfruttare questo canale. La prima è che si sa poco del funzionamento e dell'architettura dell'interconnessione ring", si legge nell'abstract del paper su ArviX.
"La seconda è che l'informazione che può essere appresa da un attaccante tramite la contesa è di natura rumorosa, e ha una granularità spaziale grossolana. Per risolvere la prima sfida, eseguiamo un accurato reverse engineering dei sofisticati protocolli che gestiscono la comunicazione sull'interconnessione ring. Con questa conoscenza, costruiamo un canale cross-core nascosto sull'interconnessione ring con una capacità di oltre 4 Mbps da un singolo thread, il più grande fino ad oggi per un canale cross-core che non sfrutta la memoria condivisa".
"Per affrontare la seconda sfida, sfruttiamo i modelli temporali a grana fine della contesa sul ring bus per dedurre i segreti di un programma vittima. Dimostriamo il nostro attacco estraendo i bit chiave dalle implementazioni vulnerabili di EdDSA e RSA, nonché deducendo la tempistica precisa delle sequenze di tasti digitate da un utente vittima".
"È importante sottolineare che, a differenza degli attacchi precedenti, i nostri attacchi non si basano sulla condivisione di memoria, set di cache, risorse private del core o strutture uncore specifiche", ha ulteriormente chiarito Riccardo Paccagnella, uno degli autori dello studio, su Twitter. "Di conseguenza, sono difficili da mitigare utilizzando le attuali tecniche di isolamento del dominio (domain isolation)".
Al momento non è chiaro se i chip Intel più recenti basati su interconnessione mesh siano suscettibili a questo attacco ma, come scritto più sopra, non c'è da preoccuparsi, non sembra esserci il pericolo di un attacco su vasta scala all'orizzonte.
Anzi, in un certo qual modo è importante che ricerche come queste emergano, in modo da permettere a Intel di identificare vulnerabilità prima che possano tramutarsi in problemi reali e di difficile gestione come visto con Spectre, Meltdown e le loro varianti negli anni successivi. Proprio dopo quei casi Intel ha rafforzato il team che si occupa di sicurezza e istituito un programma di bug bounty per incentivare i ricercatori a rintracciare vulnerabilità nei suoi prodotti in cambio di un giusto riconoscimento in denaro.
4 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoora, Intel lo derubrica ad attacco side-channel classico non critico.
ok, ci sta.
tuttavia, non molto tempo fa è stato scoperto e ben illustrato come le CPU Intel siano, in circostanze tutt'ltro che rare, piuttosto aggressive ed ottimiste riguardo la hardware store elimination (scusate ma non ho idea di come si traduca in italiano)
il problema è che così rompono l'invarianza temporale di parecchia roba. in soldoni i task non sono tutti più esprimibili in t O(1), ma iniziano a divergere. questo offre il fianco a sistemi per filtrare via tanto rumore ed estrarre il dato dal pacchetto immesso sul bus, che poi è il succo dell'attacco.
dunque, è complesso ed ok, ed aggiungo pure che in realtà già si sapeva che siamo ancora lontani dalla totale tempo invarianza (stesso vale per AMD). tuttavia, adesso questa cosa è stata fatta palese, la matassa del ring bus intel sta iniziando a venir dipanata, c'è una dimostrazione eseguita, studi avviati, paper pubblicati e POC su github.
è un problema tutto hardware e nessuno, quasi certamente nemmeno intel, sa quanto in là si può andare semplicementi "mettendosi lì a guardare il bus".
altra cosa, non è vero che serve accesso fisico alla macchina.
questo è quello che si credeva a settembre quando la prima parte del paper fu pubblicata. se ben ricordo è stato proprio christopher fletcher co-autore del paper originale a dimostrare come l'attacco possa esser pilotato anche da un vcore farlocco per sniffare a distanza il bus della cpu reale su un hypervisor sottostante. c'era un articoletto breve su InfoQ al riguardo, se lo ritrovo lo posto (questo ad onor del vero è più che mitigabile via SW, pagando prestazione s'intende)
in ultimo, in linea del tutto teorica, il mesh di intel soffre dello stesso problema per il semplice fatto che anche se lo chiamano mesh, non è mesh: è solo un doppio ring con un message dispatcher davanti.
un mesh vero e proprio non credo sia riuscito ad implementarlo ancora nessuno
ora, Intel lo derubrica ad attacco side-channel classico non critico.
ok, ci sta.
tuttavia, non molto tempo fa è stato scoperto e ben illustrato come le CPU Intel siano, in circostanze tutt'ltro che rare, piuttosto aggressive ed ottimiste riguardo la hardware store elimination (scusate ma non ho idea di come si traduca in italiano)
il problema è che così rompono l'invarianza temporale di parecchia roba. in soldoni i task non sono tutti più esprimibili in t O(1), ma iniziano a divergere. questo offre il fianco a sistemi per filtrare via tanto rumore ed estrarre il dato dal pacchetto immesso sul bus, che poi è il succo dell'attacco.
dunque, è complesso ed ok, ed aggiungo pure che in realtà già si sapeva che siamo ancora lontani dalla totale tempo invarianza (stesso vale per AMD). tuttavia, adesso questa cosa è stata fatta palese, la matassa del ring bus intel sta iniziando a venir dipanata, c'è una dimostrazione eseguita, studi avviati, paper pubblicati e POC su github.
è un problema tutto hardware e nessuno, quasi certamente nemmeno intel, sa quanto in là si può andare semplicementi "mettendosi lì a guardare il bus".
altra cosa, non è vero che serve accesso fisico alla macchina.
questo è quello che si credeva a settembre quando la prima parte del paper fu pubblicata. se ben ricordo è stato proprio christopher fletcher co-autore del paper originale a dimostrare come l'attacco possa esser pilotato anche da un vcore farlocco per sniffare a distanza il bus della cpu reale su un hypervisor sottostante. c'era un articoletto breve su InfoQ al riguardo, se lo ritrovo lo posto (questo ad onor del vero è più che mitigabile via SW, pagando prestazione s'intende)
in ultimo, in linea del tutto teorica, il mesh di intel soffre dello stesso problema per il semplice fatto che anche se lo chiamano mesh, non è mesh: è solo un doppio ring con un message dispatcher davanti.
un mesh vero e proprio non credo sia riuscito ad implementarlo ancora nessuno
Questo è un signor commento
Come consulente informatico ormai mi trovo davanti quotidianamente giovani programmatroti che parlano in allegria di sviluppare server in node.js e NoSQL. Mi domando in quanti capiscano la metà di quello che hai scritto...
Per questi scopi è legale.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".