Cos'è il bug DRAM Rowhammer e come dovrei trattarlo?

I chip DRAM sono molto stretti. La ricerca ha dimostrato che i bit vicini possono essere capovolti casualmente.

Qual è la probabilità che il bug si attivi casualmente in un chip DRAM di livello server con ECC (la carta CMU-Intel cita ad esempio il numero 9.4x10 ^ -14 per un chip sconosciuto per un errore nell'arco di un anno)?
Come faccio a sapere se il bug è stato corretto prima di acquistare memoria?
Cosa devo fare per contrastare i tentativi malevoli di eseguire l'escalation dei privilegi da, ad esempio, inquilini o utenti non privilegiati, ad esempio su CentOS 7?

Riferimenti:

— Cacciatore di cervi
fonte

Dato che i dettagli dell'exploit non sono ancora sottoposti a embargo, non sono sicuro che ci saranno molte informazioni disponibili oltre a ciò che Google ti ha già fornito.

— fukawi2

A quanto ho capito, la frequenza di aggiornamento della memoria riduce drasticamente le probabilità di successo del bit-flip, e le versioni più recenti del BIOS hanno abbassato le frequenze di aggiornamento per cercare di mitigare il rischio. Quindi l'aggiornamento del BIOS potrebbe essere un buon primo passo?

— Reagisce il

@ fukawi2, quali dettagli dell'exploit sono stati / sono sottoposti a embargo? Il codice completo per gli exploit di proof of concept è stato rilasciato con il post sul blog.

— Mark Seaborn,

@MarkSeaborn Non ricordo nemmeno ora, questo è stato 3 mesi fa e riesco a malapena a ricordare la colazione.

— fukawi2,

Risposte:

Il documento CMU-Intel che hai citato mostra (a pagina 5) che il tasso di errore dipende fortemente dal numero di parte / dalla data di fabbricazione del modulo DRAM e varia di un fattore 10-1000. Ci sono anche alcune indicazioni che il problema è molto meno pronunciato nei chip prodotti di recente (2014).

Il numero "9.4x10 ^ -14" che hai citato è stato utilizzato nel contesto di un meccanismo di mitigazione teorico proposto chiamato "PARA" (che potrebbe essere simile a un meccanismo di mitigazione esistente pTRR (pseudo target Row Refresh)) ed è irrilevante per il tuo domanda, perché PARA non ha nulla a che fare con ECC.

Un secondo documento CMU-Intel (pagina 10) menziona gli effetti di diversi algoritmi ECC sulla riduzione degli errori (fattore da 10 ^ 2 a 10 ^ 5, probabilmente molto di più con sofisticati test di memoria e "guardbanding").

ECC trasforma efficacemente l'exploit Row Hammer in un attacco DOS. Gli errori a 1 bit verranno corretti da ECC e non appena verrà rilevato un errore a 2 bit non correggibile, il sistema si arresterà (presupponendo ECC SECDED).

Una soluzione è acquistare hardware che supporti pTRR o TRR. Vedi l' attuale post sul blog di Cisco su Row Hammer . Almeno alcuni produttori sembrano avere uno di questi meccanismi di mitigazione integrati nei loro moduli DRAM, ma lo tengono nascosto nelle loro specifiche. Per rispondere alla tua domanda: chiedi al venditore.

Anche frequenze di aggiornamento più veloci (32ms anziché 64ms) e intervalli aggressivi di Patrol Scrub aiutano, ma avrebbero un impatto sulle prestazioni. Ma non conosco alcun hardware server che permetta di mettere a punto questi parametri.

Immagino che non ci sia molto da fare sul lato del sistema operativo se non terminare i processi sospetti con un utilizzo costante della CPU elevato e mancati errori nella cache.

— Daniel
fonte

La situazione sembra ancora abbastanza poco chiara, quindi non credo che le tue domande possano avere una risposta diretta, ma ecco alcune informazioni relativamente recenti come risposta parziale. Per notizie, segui la mailing list di Rowhammer-discuss .

Non sono sicuro che al momento sia possibile disporre di informazioni pubbliche per evitare l'acquisto di RAM vulnerabili, né per prevedere facilmente i tassi di errore nell'hardware esistente. I produttori non sono stati aperti con informazioni su come i loro prodotti sono interessati. È possibile testare la memoria già acquistata utilizzando strumenti software, ma è necessario tenere presente che l'esecuzione di tali strumenti per periodi significativi (ore) può degradare permanentemente la RAM e causare errori nell'esecuzione del software.

Le "società di memoria senza nome" hanno tentato di pagare una bustarella in cambio del software Passmark che non rilasciava un test del martello pneumatico nel loro strumento Memtest86.

È stato segnalato che l'hardware Intel Skylake è più vulnerabile, non meno , a martello pneumatico a causa dell'aggiunta di una nuova clflushoptistruzione. Questo è già stato sfruttato in rowhammer.js

Daniel Gruss risponde ad alcune domande qui sulla mitigazione di dicembre 2015 (coautore del documento rowhammer.js ) in questo discorso :

Mentre una parte della RAM ECC è meno vulnerabile della RAM non ECC a Rowhammer, un'altra RAM ECC è più vulnerabile della RAM non ECC ( collegamento alla domanda nel video )
Il passaggio a una frequenza di aggiornamento più veloce è sufficiente per impedire il colpo di ariete con la maggior parte ma non tutto l'hardware, ma non tutti i BIOS consentono di modificare la frequenza di aggiornamento ( collegamento alla domanda nel video ).

Come contromisura, potrebbe essere possibile rilevare attacchi di martello a remi in corso, ma non so che sia stato fatto.

— Croad Langshan
fonte