- Phoenix (CVE-2025-6202) bypassa TRR e ECC on-die su SK Hynix DDR5, ottenendo la root in pochi minuti.
- Due modelli (128 e 2608 tREFI) e la temporizzazione autocorrettiva sfruttano un punto cieco nel campionamento TRR.
- 15 DIMM testati: migliaia di capovolgimenti, attacchi PTE, furto RSA-2048 ed escalation sudo.
- Mitigazione temporanea: 3 aggiornamenti (circa l'8,4% del costo); apparecchiature pubbliche e coordinamento con i produttori.
La comunità della sicurezza e dell'hardware sta nuovamente esaminando la memoria principale: un nuovo attacco di tipo RowHammer, denominato Fenice (CVE-2025-6202), dimostra che alcuni moduli DDR5 SK Hynix rimangono vulnerabili nonostante le protezioni avanzate. Una ricerca congiunta di ETH Zurigo e Google rivela, con test riproducibili, che l'escalation dei privilegi a root è possibile su computer desktop con impostazioni predefinite in pochi minuti. verbale.
Al di là del titolo, la cosa importante è che i ricercatori hanno descritto con precisione perché le difese basate su DRAM (TRR) falliscono e come sono riusciti a aggirarle. Hanno documentato nuovi modelli di hammering, tempi di aggiornamento autocorrettivi e condizioni di sfruttamento reali che influenzano ambienti locali e multi-tenantTutto ciò è accompagnato da artefatti pubblici e da un coordinamento responsabile con i produttori e i fornitori di servizi cloud.
Cos'è RowHammer e perché sta tornando di moda?
RowHammer è una debolezza hardware nella DRAM in cui l'accesso ripetuto a una riga può portare a bit flip nelle righe adiacenti, generando corruzione dei dati. Fin dalla sua dimostrazione iniziale nel 2014, si è osservato che, all'aumentare della densità delle celle per espandere la capacità, aumenta anche il numero di attivazioni necessarie per indurre un bit flip. ridurre, aumentando il rischio.
Gli impatti pratici sono ben noti: corruzione delle strutture di sistema critiche, escalation dei privilegi o negazione del servizio. Ricerche precedenti hanno dimostrato che la suscettibilità dipende da molteplici variabili, tra cui: temperatura, tensione, variazioni di fabbricazione, modelli di dati memorizzati, modelli di accesso alla memoria e policy del controller.
Per contenere il problema sono state proposte misure di mitigazione come Error Correction Code (ECC) e Target Row Refresh (TRR). Tuttavia, studi successivi hanno dimostrato che queste difese possono essere aggirate con attacchi più sofisticati: TRRespass, SMASH, Half-Double o Blacksmith, tra gli altri. Gli effetti sono stati osservati anche in aree apparentemente molto diverse, come fingerprinting di dispositivi attraverso varianti derivate.
Parallelamente, l'organizzazione JEDEC ha recentemente introdotto un meccanismo di integrità chiamato Per-Row Activation Counting (PRAC) per rilevare i pattern RowHammer e limitare il traffico aggressivo. Tuttavia, secondo Google, i sistemi DDR5 testati non incorporavano il PRAC, lasciando la porta aperta a nuove tecniche di exploit. in produzione.
Phoenix (CVE-2025-6202): chi l'ha scoperto e cosa fa
Un team congiunto dell'ETH di Zurigo (COMSEC) e Google ha identificato un punto cieco sulle difese DDR5 TRR integrate di SK Hynix. Phoenix realizza la prima escalation dei privilegi end-to-end su un PC consumer con DDR5 standard, raggiungendo la root con le impostazioni predefinite in soli 109 secondi nel caso più favorevole, e con tempi medi di sfruttamento pratico di 5 minuti e 19 secondi in alcune demo.
La ricerca è stata testata su un sistema con CPU AMD Zen 4 e moduli DDR5 SK Hynix, con l'intenzione di replicarlo in seguito su altre memorie e processori. I risultati riguardano 15 moduli prodotti tra il 2021 e il 2024: tutti presentavano bit flip secondo uno dei due nuovi pattern sviluppati dal team. L'attacco è stato classificato come CVE-2025-6202 e gli viene assegnata una severità elevata in CVSS v4 (7.1), con valori e vettori documentati in fonti come Mitre e NVD.
Un fatto rilevante: il ECC on-die non impedisce RowHammer in DDR5. Gli autori dimostrano che i flip possono accumularsi nel tempo, poiché l'ECC on-chip corregge durante la scrittura o con correzioni periodiche (ad esempio, ogni 24 ore). L'hammering per periodi più lunghi, alla cadenza appropriata, consente circonvallazione quello strato di protezione.
Le possibilità di sfruttamento vanno dall'alterazione tabelle delle pagine per ottenere accesso arbitrario in lettura/scrittura, fino all'estrazione di chiavi RSA-2048 da macchine virtuali co-localizzate (interrompendo l'autenticazione SSH) o manipolando file binari come sudo per elevare i privilegi locali. Ci troviamo quindi di fronte a uno scenario che impatta sia sulle postazioni di lavoro sia sulle infrastrutture condivise.
Come hanno ottenuto il bypass: TRR, periodi di campionamento e nuovi modelli
Il cuore della scoperta è il ingegneria inversa delle mitigazioni TRR nella DRAM. Attraverso esperimenti basati su FPGA che utilizzano errori di ritenzione come canale laterale, i ricercatori hanno osservato che il sistema di campionamento TRR ripete il suo periodo ogni 128 intervalli tREFI, un intervallo 8 volte più ampio di quello contemplato dai classici modelli RowHammer.
“Ingrandendo”, lo studio mostra che, negli ultimi 64 intervalli di quel ciclo, c’è una sottostruttura ripetuta di quattro sottointervalli in cui i primi due sono campionati leggermente o quasi nulla. Questa asimmetria lascia una finestra di opportunità: se il martellamento si allinea con queste zone "leggermente campionate", le difese non rilevare attività aggressiva nel tempo.
Con questo indizio, il team ha derivato due modelli di lunga durata. Il primo copre solo 128 tREFI; evitare di martellare all'inizio e concentrare l'attività nelle bande a basso campionamento, ripetendo la seconda parte 16 volte per accumulare 32 intervalli di martellamento efficaci per ripetizione. La seconda copre uno schema molto più lungo di 2608 tREFI, destinato ad altri dispositivi con differenze interne.
Il tempismo è fondamentale: solo 2 di 128 Gli offset di aggiornamento sono vulnerabili, con una probabilità di successo iniziale dell'1,56%. Per aumentare le loro possibilità, eseguono la stessa sequenza di offset in parallelo su ciascuna delle quattro banche, aumentando la probabilità di raggiungere l'offset corretto di 16 fino a circa 25%.
Sincronizzazione autocorrettiva: un passo da gigante rispetto ai tentativi precedenti
Una sfida fondamentale è stata quella di mantenere l'allineamento con l' rinfreschi su migliaia di intervalli, poiché i pattern Phoenix sono da 1 a 2 ordini di grandezza più grandi dei pattern tipici. Gli autori hanno scoperto che la routine di sincronizzazione di Zenhammer, anche nelle varianti multi-thread, non mantiene la stabilità abbastanza a lungo da innescare in modo affidabile i flip.
La soluzione è una tecnica di sincronizzazione autocorrettiva che sfrutta la periodicità di aggiornamento: non ha bisogno di rilevare ogni singolo comando; invece, rileva i disallineamenti e riallinea l'esecuzione del pattern per tenere il passo, anche quando viene perso un aggiornamento tempestivo. Questo approccio consente di mantenere coherencia su migliaia di tREFI.
Per illustrare il miglioramento, i ricercatori sottolineano che grazie a questa robusta sincronizzazione possono mantenere il loro modello in perfetto tempo con i cicli interni di TRR, qualcosa che i metodi precedenti non potevano ottenere senza cadere in divario dopo alcune centinaia di intervalli.
In termini pratici, questa stabilità è ciò che consente la scalabilità end-to-end di una macchina. desktop con DDR5, culminando nei privilegi di root con parametri predefiniti in tempi aggressivi come 109 secondi nella loro dimostrazione.
Risultati sperimentali: 15 DIMM vulnerabili e flip sfruttabili
Il team ha valutato 15 moduli DDR5 di SK Hynix prodotti tra la fine del 2021 e la fine del 2024. Tutti hanno mostrato inversioni di bit con uno dei due pattern. Il pattern corto da 128 tREFI ha prodotto, in media, 2,62 × più efficiente di quello lungo, producendo nell'ordine di migliaia di flip per DIMM: il documento cita una media approssimativa di 4989 lanci nei tuoi test
Questi capovolgimenti sono diventati veri e propri primitivi in tre scenari già noti: (i) corruzione di PTE (esperti di tecnologia professionale) per leggere/scrivere memoria arbitraria (tutti i DIMM vulnerabili); (ii) estrazione della chiave RSA-2048 da VM collocate per interrompere SSH (su un 73% di DIMM vulnerabili); e (iii) modifica del binario sudo per elevare i privilegi locali (nel 33% dei DIMM vulnerabili).
Inoltre, gli autori replicano per la prima volta in DDR5 l'escalation dei privilegi del job Rubicon, mostrando tempi medi di sfruttamento di 5:19 in condizioni di test controllate, rafforzando la fattibilità pratica dell'attacco al di fuori del laboratorio.
Il test è stato eseguito su un sistema con CPU AMD Zen 4 e moduli SK Hynix. Il team prevede di estendere i test ad altri sistemi. produttori e architetture per comprenderne l'intera portata; tuttavia, la combinazione attuale è già rappresentativa di un moderno ambiente desktop DDR5.
Come dati aggregati sul rischio, le varie metriche collocano Phoenix in una gravità rilevante: CVSS v4 7.1 (alto) con vettore documentato; CVSS v3 5.5 (medio) con vettore AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N; e CVSS v2 2.1 (Basso) con vettore AV:L/AC:L/Au:N/C:N/I:P/A:N. L'EPSS associato è stimato a 0.00014, che riflette la probabilità di sfruttamento osservata nell'ecosistema, anche se questa cifra deve essere interpretata insieme all'impatto tecnico comprovato.
Mitigazioni e costi della difesa oggi
Come misura shock, i ricercatori raccomandano triplicare la frequenza di aggiornamento (3×), che sui loro sistemi ha fermato i capovolgimenti di Phoenix. Poiché tREFI è intorno 1,3 μs, questa regolazione implica più operazioni di refresh e, quindi, un costo in termini di prestazioni misurabile: in SPEC CPU2017 riportano fino a 8,4% sovraccarico.
Sottolineano inoltre che i fornitori e gli OEM hanno leve immediate: Aggiornamenti BIOS/firmware per regolare le policy di memoria o aggiornare i parametri. Infatti, nella finestra di embargo, AMD ha annunciato la disponibilità di un aggiornamento del BIOS per le macchine client, sebbene gli autori non siano stati in grado di verificare in modo indipendente in che misura mitiga specificamente Phoenix.
Importante: l'ECC on-die non è uno "scudo magico". Secondo il documento, le correzioni differite consentono l'accumulo di flip se l'attaccante colpisce con un pattern che supera il filtro TRR. Pertanto, ODEC non impedisce di per sé che l'attacco progredisca nella DDR5 nelle condizioni descritte.
Guardando al medio termine, il settore necessita di mitigazioni "di principio", non di risposte ad hoc a ogni nuovo modello. Il JEDEC ha definito i PRAC, ma gli autori e Google sottolineano che Sistemi DDR5 I test effettuati non lo includono, lasciando spazio a possibili elusioni. Un'implementazione più ampia di meccanismi di conteggio delle righe e di policy di aggiornamento adattive potrebbe alzare significativamente l'asticella.
Contesto: Altri attacchi e il ruolo dei server ECC
RowHammer ha accumulato varianti, ognuna delle quali mette pressione su un diverso fianco della difesa. Oltre a TRRespass, SMASH, Half-Double e Blacksmith, recenti ricerche hanno presentato OneFlip (capovolgere un po' per alterare i pesi del modello DNN e causare un comportamento indesiderato) e ECC.fallimento (primo attacco end-to-end riuscito contro server DDR4 con memoria ECC, che provoca capovolgimenti in posizioni specifiche che sfuggono al rilevamento/correzione).
In teoria, i server hanno protezioni extra contro la corruzione della memoria (come ECC per i raggi cosmici o RowHammer), ma ECC.fail ha dimostrato che, con lo stimolo giusto, possono anche cederPhoenix si aggiunge a questa lista sul fronte DDR5 desktop, dimostrando che l'equilibrio tra densità, prestazioni e robustezza è una linea sottile.
Anche i produttori e gli ecosistemi affermati sono stati interessati da tale ricerca (ad esempio, Nvidia o piattaforme DDR4), e non è una coincidenza: man mano che i transistor e le celle si avvicinano, si verificano interferenze elettriche e canali laterali scappatoie che prima non esisteva.
L'apprendimento è chiaro: le mitigazioni devono evolversi con la fisica dell'hardware, integrando telemetria e risposte dinamiche che sfuggono alle ipotesi di campionamento statico, precisamente il tallone d'Achille che Phoenix sfrutta nella valutazione DDR5.
Divulgazione responsabile, cronologia e risorse
L'ETH di Zurigo ha avviato un processo di divulgazione responsabile tramite l'NCSC svizzero il 6 giugno 2025, notificando SK Hynix, i produttori di CPU e i principali fornitori di servizi cloud. La questione è rimasta sotto embargo fino al 15 settembre 2025. Poco prima, il 12 settembre, AMD ha segnalato un BIOS per i computer client, senza verifica indipendente da parte degli autori.
L'opera completa verrà presentata alla Simposio IEEE su sicurezza e privacy 2026Il documento e gli artefatti (inclusi PoC e strumenti di test) sono disponibili al pubblico: è possibile consultare il PDF e il repository per riprodurre i test e valutare i moduli in un laboratorio controllato.
Link utili: carta in PDF y Repository Phoenix su GitHubGoogle ha anche pubblicato una voce nel suo Blog sulla sicurezza discutendo l'ambito e gli strumenti di test per DDR5.
Le carte vulnerabilità indicano come fonti mitra y NVD, pubblicato e aggiornato il 15 settembre 2025 con il nome Phoenix. Il tag CVE-2025-6202 e i suoi vettori consentono ai team di gestione del rischio di stabilire le priorità e mappare le decisioni di mitigazione utilizzando criteri coerenti.
Note del produttore e considerazioni legali
AMD ha pubblicato un disclaimer sottolineando che le informazioni tecniche potrebbero contenere inesattezze, non fornisce alcuna garanzia, espressa o implicita, e non si assume alcuna responsabilità per l'uso dell'hardware o del software descritto. Si noti inoltre che i marchi AMD, EPYC e Ryzen sono proprietà della società e che l'acronimo CVE e il suo logo appartengono a The MITRE Corporation.
La stessa informativa afferma che i contenuti di terze parti collegati sono forniti "così come sono" (COME SONO) e il suo utilizzo è a rischio e pericolo del lettore. Questo tipo di esclusione di responsabilità è comune nella documentazione tecnica e non pregiudica la validità del risultati accademici, ma vale la pena tenerlo presente nelle distribuzioni produttive e nelle comunicazioni aziendali.
Cosa dovrebbero fare gli utenti, gli amministratori e i provider
Se si utilizzano macchine SK Hynix DDR5, il primo passo è inventario moduli e rivedere le versioni BIOS/firmware disponibili per la tua piattaforma. Molti OEM potrebbero rilasciare modifiche che innalzano la soglia di sicurezza, mentre vengono implementate mitigazioni più approfondite.
In secondo luogo, eseguire test in un laboratorio chiuso (mai in produzione) per la suscettibilità agli artefatti Phoenix pubblici, soprattutto se si gestiscono ambienti multi-tenant o carichi di lavoro sensibili (ad esempio, claves memoria crittografica). Lo strumento ETH/Google include utilità di test progettate per DDR5, con raccomandazioni esplicite per un uso responsabile.
Se i tuoi test mostrano dei capovolgimenti, considera di attivare l' 3× di soda Sui sistemi più critici, ipotizzando il costo delle prestazioni, in presenza di carichi consentiti dall'SLA, l'8,4% misurato in SPEC potrebbe rappresentare un prezzo ragionevole da pagare rispetto alla possibilità di escalation locali o perdite segrete tra tenant.
Nel cloud privato o in ambienti con VM co-localizzate, rafforzare i limiti di affinità e isolamento, riducendo al minimo l'esposizione di segreti di alto valore in memoria quando si sospetta una coresidenza non attendibile. A ciò si aggiungono regole di monitoraggio e risposta per modelli di accesso alla memoria anomali.
Infine, restate sintonizzati per il futuro aggiornamenti dello standard (ad esempio, PRAC) e il lavoro dei produttori per integrare protezioni basate sul conteggio delle righe e sulle policy di aggiornamento adattivo. Phoenix dimostra che, senza questo salto di qualità, il settore continuerà a giocare al gatto e al topo con ogni nuova variazione di modello.
Sebbene il vettore principale sia locale (AV:L in CVSS v3), l'impatto sull'integrità è elevato e la finestra di sfruttamento è breve, con prove di escalation alla radice, furto di chiavi RSA-2048 e manipolazione di binari critici. Combinare un rafforzamento immediato, test controllati e monitoraggio delle patch è, oggi, la strategia più sensata.
Il caso Phoenix evidenzia quanto sia piccolo discrepanze La strategia di campionamento TRR può compromettere difese teoricamente robuste. Con la sincronizzazione autocorrettiva, i pattern tREFI a 128 e 2608, la parallelizzazione dei banchi e un attento allineamento degli aggiornamenti (solo 2 offset su 128 sono validi, aumentando la probabilità al 25% quando si sfruttano quattro banchi contemporaneamente), questo attacco consolida il fatto che DDR5 non sia un porto sicuro di default contro RowHammer. Tra la solidità dei risultati sperimentali, la possibilità di sfruttamento end-to-end in pochi minuti e il costo accessibile delle mitigazioni temporanee (aggiornamento 3x), il messaggio per i team tecnici è chiaro: vale la pena agire ora, senza aspettare soluzioni perfette, spingendo al contempo il settore a integrare le difese di principios come PRAC e nuove e più intelligenti politiche di aggiornamento.
