{"id":30189,"date":"2025-10-10T10:23:37","date_gmt":"2025-10-10T08:23:37","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=30189"},"modified":"2025-10-10T10:23:37","modified_gmt":"2025-10-10T08:23:37","slug":"phoenix-rowhammer-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/phoenix-rowhammer-attack\/30189\/","title":{"rendered":"Phoenix: un attacco Rowhammer alle memorie DDR5"},"content":{"rendered":"

I ricercatori dell\u2019ETH di Zurigo (l\u2019Istituto Federale Svizzero di Tecnologia) hanno pubblicato a settembre 2025 un documento<\/a> su Phoenix, una modifica dell\u2019attacco Rowhammer che agisce sui moduli di memoria DDR5. Gli autori hanno dimostrato l\u2019efficacia del nuovo attacco contro 15 moduli testati, proponendo anche tre casi d\u2019uso pratici: lettura e scrittura dei dati dalla memoria, furto di una chiave di criptaggio privata archiviata in memoria e aggiramento delle protezioni dell\u2019utilit\u00e0 sudo di Linux per scalare i privilegi.<\/p>\n

L\u2019attacco Rowhammer: una breve storia<\/h2>\n

Per comprendere questo studio piuttosto complesso, \u00e8 necessario prima rivisitare brevemente la storia di Rowhammer. L\u2019attacco Rowhammer \u00e8 stato descritto per la prima volta in un documento di ricerca<\/a> del 2014. All\u2019epoca, i ricercatori sia della Carnegie Mellon University che di Intel dimostrarono come l\u2019accesso ripetuto a righe di celle di memoria potesse causare variazioni di valore nelle celle di memoria adiacenti. Queste celle adiacenti potrebbero contenere dati critici, la cui alterazione potrebbe avere gravi ripercussioni (come l\u2019escalation dei privilegi).<\/p>\n

Questo accade perch\u00e9 ogni cella di un chip di memoria \u00e8 essenzialmente un condensatore: un semplice componente in grado di mantenere una carica elettrica solo per un breve periodo. La memoria \u00e8 volatile per questo motivo: spegnendo il computer o il server, i dati scompaiono. E per lo stesso motivo, la carica nelle celle deve essere aggiornata frequentemente anche se nessun processo sta effettivamente accedendo a una data regione di memoria<\/em>.<\/p>\n

Le celle di memoria non sono isolate, ma sono organizzate in righe e colonne interconnesse in modi che possono causare interferenze. L\u2019accesso a una riga pu\u00f2 influire su una riga adiacente: ad esempio, l\u2019aggiornamento di una riga pu\u00f2 danneggiare i dati di un\u2019altra riga. Per anni questo effetto era noto solo ai produttori di memorie, che facevano del proprio meglio per attenuarlo al fine di migliorare l\u2019affidabilit\u00e0. Per\u00f2, man mano che l\u2019industria trovava modi di rimpicciolire le celle, e quindi ammassarle pi\u00f9 strettamente tra loro, l\u2019effetto \u201cmartello\u201d apriva il fianco ad attacchi del mondo reale.<\/p>\n

Dopo la dimostrazione dell\u2019attacco Rowhammer, gli sviluppatori di memorie hanno iniziato a introdurre difese, fino a produrre la tecnologia hardware Target Row Refresh (TRR). La TRR \u00e8 semplice, in teoria: monitora accessi aggressivi alle righe e, se rilevati, aggiorna forzatamente le righe adiacenti. Nella pratica per\u00f2 non si \u00e8 rivelata molto efficace. Nel 2021 venne descritto Blacksmith<\/a>, un attacco che aggirava il TRR sfruttando modelli pi\u00f9 sofisticati di accesso alle celle di memoria.<\/p>\n

Gli sviluppatori hanno reagito aggiungendo difese ancora pi\u00f9 avanzate contro gli attacchi di tipo Rowhammer nei moduli DDR5 e aumentando la frequenza di aggiornamento forzata. Per contrastare eventuali nuovi attacchi, i produttori non hanno divulgato le contromisure attuate. Ci\u00f2 ha indotto molti a ritenere che le DDR5 avessero effettivamente risolto il problema Rowhammer. Invece, proprio l\u2019anno scorso, sempre i ricercatori dell\u2019ETH di Zurigo sono riusciti ad attaccare con successo<\/a> i moduli DDR5, pur se in condizioni specifiche: la memoria doveva essere accoppiata con CPU AMD Zen 2 o Zen 3, lasciando comunque intatti alcuni moduli.<\/p>\n

Caratteristiche del nuovo attacco<\/h2>\n

Per sviluppare Phoenix, i ricercatori hanno eseguito il reverse engineering della tecnologia TRR. Ne hanno analizzato il comportamento in base a vari modelli di accesso alle righe di memoria e hanno verificato se la protezione venisse attivata per le righe adiacenti. \u00c8 risultato che la TRR \u00e8 diventata significativamente pi\u00f9 complessa e i modelli di accesso precedentemente noti non funzionavano pi\u00f9: ora la protezione contrassegnava correttamente tali modelli come potenzialmente pericolosi e forzava l\u2019aggiornamento delle righe adiacenti. Il risultato \u00e8 stata la scoperta che dopo 128 accessi alla memoria tracciati dalla TRR compare una \u201cfinestra di opportunit\u00e0\u201d di 64 accessi, durante la quale le difese risultano indebolite. Sebbene il sistema di protezione non incorra in un errore completo, le sue reazioni sono insufficienti per impedire una modifica del valore in una cella di memoria. La seconda finestra si presenta dopo l\u2019accesso alle celle di memoria su 2608 intervalli di aggiornamento.<\/p>\n

I ricercatori hanno quindi studiato in dettaglio questi punti vulnerabili per sferrare un attacco altamente mirato sulle celle di memoria, abbattendo allo stesso tempo le difese. In parole povere, l\u2019attacco funziona in questo modo: il codice dannoso esegue una serie di accessi fittizi che di fatto inducono un falso senso di sicurezza nel meccanismo TRR. A questo punto si verifica la fase attiva dell\u2019attacco, che alla fine modifica il valore della cella bersagliata. Il team ha quindi confermato l\u2019affidabilit\u00e0 dell\u2019attacco contro tutti i 15 moduli DDR5 testati prodotti da SK Hynix, uno dei leader di mercato.<\/p>\n

Tre reali scenari di attacco<\/h2>\n

Un attacco realistico deve modificare un valore in un\u2019area della memoria ben definita: un compito non facile. In primo luogo, il pirata informatico deve avere una conoscenza dettagliata del software di destinazione. Deve aggirare pi\u00f9 controlli di sicurezza convenzionali e, se dovesse mancare il bersaglio per uno o due soli bit, potrebbe causare un arresto anomalo del sistema ma non un attacco pienamente riuscito.<\/p>\n

I ricercatori svizzeri hanno perci\u00f2 inteso dimostrare come Phoenix potrebbe essere utilizzato per causare danni nel mondo reale. A tale scopo hanno valutato tre scenari di attacco. Il primo (PTE) prevede l\u2019accesso alla tabella delle pagine per creare le condizioni per la lettura\/scrittura arbitraria dei dati RAM. Il secondo (RSA) mira a rubare una chiave di criptaggio privata RSA-2048 dalla memoria. Il terzo (sudo) prevede l\u2019elusione delle protezioni dell\u2019utilit\u00e0 sudo Linux allo scopo di scalare i privilegi. I risultati finali dello studio sono mostrati in questa tabella:<\/p>\n

\"Efficacia

Efficacia dell\u2019attacco Phoenix. Fonte<\/a><\/p><\/div>\n

Per alcuni moduli, la prima variante di attacco (128 intervalli di aggiornamento) si \u00e8 rivelata efficace, mentre per gli altri moduli ha funzionato solo la seconda variante (2608 intervalli). In alcuni esperimenti il furto della chiave RSA e gli exploit sudo non hanno avuto esito positivo. Tuttavia, \u00e8 stato trovato un metodo per la lettura\/scrittura arbitraria della memoria per tutti i moduli e con un tempo di sfruttamento relativamente breve, da cinque secondi a sette minuti circa. Ci\u00f2 \u00e8 stato sufficiente per dimostrare che gli attacchi Rowhammer rappresentano un rischio reale, pur se in una serie di scenari molto circoscritti.<\/p>\n

Minacce e contromisure<\/h2>\n

L\u2019attacco Phoenix mostra che gli attacchi di tipo Rowhammer possono essere sferrati contro i moduli DDR5 con la stessa efficacia degli attacchi contro le DDR4 e DDR3. Sebbene i moduli di un singolo fornitore siano stati testati e i ricercatori abbiano scoperto un punto debole nell\u2019algoritmo TRR di quel fornitore (abbastanza semplice e molto probabilmente facile da correggere), si tratta di un significativo passo avanti nella ricerca sulla sicurezza dei moduli di memoria.<\/p>\n

Gli autori dello studio hanno proposto diverse contromisure contro gli attacchi di tipo Rowhammer. In primo luogo, la riduzione dell\u2019intervallo di aggiornamento forzato in tutte le celle pu\u00f2 ostacolare di molto l\u2019attacco. Il consumo energetico e la temperatura del chip ne potrebbero risentire, ma \u00e8 una soluzione semplice. In secondo luogo, \u00e8 possibile utilizzare la memoria con un codice di correzione errori (ECC). Questo complica gli attacchi Rowhammer, anche se, paradossalmente, non li rende del tutto impossibili<\/a>.<\/p>\n

Al di l\u00e0 di queste ovvie misure, gli autori ne menzionano altre due. La prima riguarda il metodo di protezione Aggiornamento granularit\u00e0 fine, gi\u00e0 in fase di attuazione. Integrato nel controller della memoria del processore, questo metodo modifica il comportamento di aggiornamento delle celle di memoria per resistere agli attacchi Rowhammer. Per quanto riguarda la seconda misura, i ricercatori esortano gli sviluppatori di moduli di memoria e chip a non fare pi\u00f9 affidamento su misure di sicurezza proprietarie (la cosiddetta \u201csecurity through obscurity\u201d, cio\u00e8 la protezione nascosta dall\u2019opacit\u00e0). Raccomandano invece di adottare un approccio comune al criptaggio, nel quale gli algoritmi di sicurezza siano disponibili al pubblico e soggetti a test indipendenti.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Ricercatori svizzeri hanno trovato il modo di attaccare i moduli di memoria DDR5.<\/p>\n","protected":false},"author":665,"featured_media":30191,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[1619,3898,584],"class_list":{"0":"post-30189","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-hardware","11":"tag-memoria","12":"tag-vulnerabilita"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/phoenix-rowhammer-attack\/30189\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/phoenix-rowhammer-attack\/29700\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/phoenix-rowhammer-attack\/24771\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/phoenix-rowhammer-attack\/29588\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/phoenix-rowhammer-attack\/28647\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/phoenix-rowhammer-attack\/31534\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/phoenix-rowhammer-attack\/40627\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/phoenix-rowhammer-attack\/13876\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/phoenix-rowhammer-attack\/54528\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/phoenix-rowhammer-attack\/24389\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/phoenix-rowhammer-attack\/32786\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/phoenix-rowhammer-attack\/29803\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/phoenix-rowhammer-attack\/35532\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/phoenix-rowhammer-attack\/35156\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/hardware\/","name":"hardware"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30189","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=30189"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30189\/revisions"}],"predecessor-version":[{"id":30192,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30189\/revisions\/30192"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/30191"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=30189"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=30189"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=30189"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}