Rowhammer, bug hardware sui moduli DRAM mette a rischio la sicurezza dei computer portatili

Rowhammer, bug hardware sui moduli DRAM mette a rischio la sicurezza dei computer portatili

Il team Project Zero di Google ha trovato una nuova vulnerabilità su alcuni recenti moduli DRAM DDR3 installati sui computer portatili che potrebbe compromettere la sicurezza del sistema

di pubblicata il , alle 11:01 nel canale Sicurezza
 

Project Zero ha fatto parlare di sé durante gli scorsi mesi per via di alcune manovre "aggressive" operate nei confronti di Microsoft. È un team di hacker veterani che lavora al fine di scovare bug e vulnerabilità e renderli noti in modo che vengano risolti da chi di dovere. La divisione di Google ha scoperto una nuova vulnerabilità nascosta all'interno dei moduli DRAM DDR3, invitando i produttori, già consapevoli del fenomeno da anni, a fornire informazioni su come mitigare quello che viene definito il problema "rowhammer".

Si tratta di una problematica che era stata posta all'attenzione da Intel e alcuni ricercatori della Carnegie Mellon lo scorso anno, all'interno di un documento chiamato "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors". I ricercatori avevano evidenziato come con l'aumentare della miniaturizzazione dei moduli DRAM sta diventando sempre più difficile isolare la memoria in un indirizzo per impedire la corruzione dei dati in un altro.

Con una tecnica definita rowhammering è possibile avere effetti di "accoppiamento" fra le celle vicine, causando un "bit flip", ovvero un cambiamento del valore della singola cella da 1 a 0 o viceversa. I produttori di moduli di memoria hanno sempre sostenuto che attraverso tale pratica fosse sostanzialmente impossibile eseguire attacchi mirati su una specifica macchina, ma in seguito alle novità portate alla luce da Mark Seaborn e Thomas Dullien del Project Zero scopriamo che non è così.

I due hanno infatti spiegato nei dettagli due attacchi proof-of-concept applicabili sfruttando le pratiche di rowhammering sui moduli DRAM. Con i metodi specificati è possibile ottenere i privilegi di root su macchine basate su sistemi Linux x86-64, ma trattandosi di una falla hardware potrebbe essere sfruttabile a prescindere dal sistema operativo in uso. Ad essere vulnerabili alle pratiche di rowhammering sono alcuni fra i moduli DRAM DDR3 di tre fra i maggiori produttori, non meglio specificati. Su 29 computer, fra quelle analizzati da Google, 15 notebook si sono verificati indifesi e nessun desktop.

Gli attacchi sviluppati da Project Zero hanno esiti negativi sulle macchine con moduli di memoria ECC (Error-Correcting Code), mentre i più recenti moduli LPDDR4 dovrebbero esserne immuni grazie alle feature Targeted Row Refresh e Maximum Active Count, progettate proprio per mitigare gli effetti del rowhammering. Al momento è comunque molto difficile quantificare la portata del fenomeno, potenzialmente enorme, che dovrebbe coinvolgere principalmente il pubblico consumer di dispositivi notebook.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

13 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
palleggiatore11 Marzo 2015, 13:16 #1
macchebellanotizia!

quindi vale solo per le sodimm?

permette accesso da remoto o richiede accesso fisico?
corvazo11 Marzo 2015, 16:21 #2
Se si sapessero almeno le marche e I modelli da evitare...
emanuele8311 Marzo 2015, 16:50 #3
Originariamente inviato da: corvazo
Se si sapessero almeno le marche e I modelli da evitare...


Ma per cosa? Un attacco sfruttando questo bug è non solo improbabile, ma praticamente impossibile. Occorre avere accesso a tutte le locazioni di memoria adiacenti a quella da attaccare, occorre sapere esattamente come la memoria sia organizzata a livello di dispositivo e si deve riuscire a correlare le due cose. Senza contare che allora i margini della memoria (organizzazione fisica in tabelle di transistor, per cui i bordi della tabella) sono intrinsecamente meno vulnerabili. Che succede se un dato che deve essere attaccato si trova in quella precisa locazione? Senza contare che alcuni moduli sono attaccabili ed altri no, dipende poi da cosa? Dal processo, dall’ingegnerizzazione o semplicemente dalla temperatura? Mi ci gioco le palle che chi ha fatto questa scoperta ha prima messo i dati da attaccare nelle locazioni giuste, e poi li ha attaccati. Troppe variabili, imho per preoccuparsi di un problema simile anche in ambito diverso da quello domestico.
SharpEdge11 Marzo 2015, 20:01 #4
ahahah Preoccupiamoci prima di insegnare una buona educazione informatica e di non usare password come "password" o "1234" ( Ho visto server in produzione con accessi root come quelli ).

Ci sono un trillione di altri modi più semplici ed efficaci per bucare una macchina ( basta saltare un aggiornamento e sei f*ttuto senza tanta fatica )
lucusta11 Marzo 2015, 22:51 #5
emanuele ha perfettamente ragione, ed e' anche per questo che hanno adoperato un sistema open come linux, in cui bene o male sai dov'e' mappata la memoria e sai che tipo d'informazione stai cercando di cambiare.
su un sistema proprietario prima dovresti sapere com'e' codificata la memoria, poi dovresti conoscere il codice per cambiare i dati (ma puoi andare anche a tentativi), e comunque dovresti anche sapere se le celle limitrofe al bit da cambiare possono essere utilizzate o meno... dopo tutto questo dovresti sperare che il sistema abbia realmente la vulnerabilita' HW...

un hacking cosi', da remoto, non e' inprobabile, e' semplicemente assurdo...
LMCH12 Marzo 2015, 00:15 #6
Invito chi sta postando in questa discussione a leggere [U]e comprendere[/U] l'articolo originale prima di minimizzare:
http://googleprojectzero.blogspot.it/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

Perche se si legge quell'articolo è evidente che non stavano provando la cosa su un software opensource "perche quello essendo aperto è più facile da attaccare", ma semmai perche stavano verificando e migliorando software fondamentale per Google.

Infatti il primo exploit di prova lo hanno attuato sul Native Client (NaCl) di Chrome che permette di eseguire codice nativo in condizioni controllate
e poi lo hanno reso immune a tale tipo di attacco.

Il secondo tipo di attacco invece usava un applicazione che girava in user mode ma non in un sandbox ed usa un altro metodo basato sull'allocazione di molte pagine di memoria e sulla conoscenza della struttura delle page table
(informazioni disponibili nei manuali per gli sviluppatori di tutti processori, non roba "custom" che dipende dal S.O.).

Il secondo attacco funziona su macchine "poco cariche" (con molta ram libera e relativamente poca roba in esecuzione) perche deve allocare un sufficiente quantitativo di ram che non sia paginata troppo frequentemente
per riuscire a manipolare la sua stessa page table.

In altre parole, questa classe di exploit non va ad attaccare pagine del S.O. o di altri processi, ma attacca i descrittori delle pagine per processo stesso per permettere l'accesso read/write/execute e poter generare codice malevole DOPO CHE QUELLE PAGINE HANNO SUPERATO I CHECK DEL S.O. E DI EVENTUALI ANTIVIRUS.

Questa classe di exploit si può utilizzare anche con Windows e sistemi operativi proprietari generici, anzi, non mi stupirei se a breve si scoprissero malware che ne fanno già uso.

TUTTE LE ATTUALI CPU x86 ed x86-64 SONO in teoria particolarmente vulnerabili a causa dell'istruzione non-privilegiata clflush
(ma perche lo siano devono usare ram non-ecc "vulnerabile".

Inoltre sono possibili exploit che non usano direttamente clflush in teoria applicabili anche ad altri processori.

La cosa funziona su sistemi con DRAM non-ECC e moduli di memora DDR4 LPDDR4 presentano modalita operative che se opportunamente utilizzate mitigano la gravità di tale exploit.

Notare le parola magica: mitigano, perchè è un attacco di tipo probabilistico.

Altra cosa da notare è che nell'articolo dicono esplicitamente che
le specifiche JEDEC riguardo LPDDR4 e la documentazione di almeno un produttore di DDR3 "resistente ad attacchi rowhammer" descrivono accorgimenti che hanno come unico scopo la prevenzione della situazione "patologica" alla base di tale exploit.

Significa che il meccanismo di base era già noto (anche se dal punto di vista dei produttori di ram era "solo" un tipo di corruzione di dati) e quindi non è improbabile che qualcun altro abbia già in mano tool di attacco basati su di esso.

Non sarebbe la prima volta, ad esempio quando molti anni fa fu approvato il vecchio standard crittografico DES la NSA fece in modo di inserire alcune piccole modifiche senza spiegare esattamente per quali ragioni.

Per molti anni i "civili" pensarono che fosse roba mirata ad indebolire il DES in modo che la NSA potesse crackarlo a forza bruta ... ed in parte era vero.
Ma quello che si scoprì molto più tardi era che tali modifiche avevano anche l'effetto di rendere il DES resistente alle tecniche di crittoanalisi differenziale.
La NSA la conosceva ed usava gia ...
e non voleva che altre agenzie con minor potenza di calcolo di loro potessero crackare il DES con la crittoanalisi differenziale.
rockroll12 Marzo 2015, 05:04 #7

Come va a finire con la corsa ai nanometri sotto i 14?

Appunto, la miniaturizzazione a questi livelli non mi convince proprio per niente, il rischio di interferenze sullo stato elettronico immediatamente circostante la zona interessata ad aggiornamento rende insicura una condensazione di informazioni troppo spinta, checchè ne pensi I$ e la sua legge anzi speranza di millantata progressione secondo Moore...

cdimauro12 Marzo 2015, 06:39 #8
Ti svelo un segreto: ai 14nm stanno lavorando anche altre fab, oltre Intel. Ma a te punge soltanto Intel: chissà perché...
cdimauro12 Marzo 2015, 17:34 #9
Originariamente inviato da: LMCH
TUTTE LE ATTUALI CPU x86 ed x86-64 SONO in teoria particolarmente vulnerabili a causa dell'istruzione non-privilegiata clflush
(ma perche lo siano devono usare ram non-ecc "vulnerabile".

Perché clflush dovrebbe essere privilegiata? Fa parte delle istruzioni di controllo della cache, che fa comodo avere disponibili in user-mode.
LMCH12 Marzo 2015, 18:34 #10
Originariamente inviato da: cdimauro
Perché clflush dovrebbe essere privilegiata? Fa parte delle istruzioni di controllo della cache, che fa comodo avere disponibili in user-mode.


Ho scritto che clflush non è privilegiata (quindi accessibile a qualsiasi applicazione nativa user-mode) , mica che che dovrebbe esserlo.

Poi che a causa della disponibilità di clflash sia più facile codificare un exploit rowhammer è una altra questione.

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".

La discussione è consultabile anche qui, sul forum.
 
^