Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/rowhammer-bug-hardware-sui-moduli-dram-mette-a-rischio-la-sicurezza-dei-computer-portatili_56406.html

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

Click sul link per visualizzare la notizia.

macchebellanotizia!

quindi vale solo per le sodimm?

permette accesso da remoto o richiede accesso fisico?

Se si sapessero almeno le marche e I modelli da evitare...

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.

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 )

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

Invito chi sta postando in questa discussione a leggere e comprendere 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. :uh:

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 :fuck: potessero crackare il DES con la crittoanalisi differenziale. :Perfido:

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

Ti svelo un segreto: ai 14nm stanno lavorando anche altre fab, oltre Intel. Ma a te punge soltanto Intel: chissà perché...

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.

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.

http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
Grazie, Antonio. L'articolo è molto interessante.

Rispondo sotto, perché riguarda anche LMCH.
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.
Da come avevi scritto sembrava che il problema nascesse proprio dal fatto che clflush fosse non privilegiata. Da cui la mia domanda.

Come hai detto adesso, non è lei il problema, infatti. Il difetto si verifica anche senza clflush. Quest'ultima consente "soltanto" di arrivarci molto più velocemente, a causa del lavoro che fa (e che rimane utile).

Comunque dalla pubblicazione si legge che hanno usato una versione modificata di memtest86+. Il che, a fini della pubblicazione, rappresenta assolutamente la scelta migliore (nessun s.o., pieno controllo dell'hardware e, dunque, delle richieste inviate alla memoria). Ma in un normale sistema è decisamente difficile riuscire a mettere in atto questa tecnica, e ancor più riuscire a ottenere un exploit sfruttabile.

Con ciò non voglio dire che non bisogna trascurarlo, sia chiaro. Rimane un problema molto grave.

Comunque dalla pubblicazione si legge che hanno usato una versione modificata di memtest86+. Il che, a fini della pubblicazione, rappresenta assolutamente la scelta migliore (nessun s.o., pieno controllo dell'hardware e, dunque, delle richieste inviate alla memoria). Ma in un normale sistema è decisamente difficile riuscire a mettere in atto questa tecnica, e ancor più riuscire a ottenere un exploit sfruttabile.

Con ciò non voglio dire che non bisogna trascurarlo, sia chiaro. Rimane un problema molto grave.


Hai letto la pubblicazione (http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf) che descrive le condizioni di modifica dello stato delle DRAM, in cui è stato utilizzato Memtest86+ per produrre l'errore ma non per ottenere un exploit basato su di esso.

Degli exploit funzionanti vengono invece descritti nell'articolo di Mark Seaborn e Thomas Dullien (http://googleprojectzero.blogspot.it/2015/03/exploiting-dram-rowhammer-bug-to-gain.html) (quello che consigliavo di leggere).


Seaborn e Dullien hanno realizzato un "apparentemente innocuo" plugin NaCl che usando clflush trapana il sandbox NaCl di ChromeOS dando a se stesso accesso in scrittura alle pagine del codice e salendo di privilegio.
Per questo motivo hanno poi modificato il software di verifica e validazione pre-esecuzione di NaCl in modo da non permettere i clflush.

Poi hanno realizzato un altro programma che gira in user mode su Linux e che su macchine con sufficiente ram libera e con poco carico riesce a sfruttare l'exploit, salire di privilegio e guadagnare accesso in scrittura a tutta la ram fisicamente presente. :eek:

Nulla vieta di usare approcci analoghi anche su Windows, in particolari inserendo il codice che sfrutta l'exploit in programmi che si presentano come utility di test, videogiochi o altro software che non sia troppo sospetto se alloca molta ram o caricano molto la cpu.

Questo perche non serve l'accesso ai sorgenti del SO o delle applicazioni per ottenere le informazioni riguardo cpu e SO necessarie per sviluppare exploit rowhammer.

Amen. :D A breve arriverò anche per Windows, sebbene sia un po' più complicato.