--- title: "“Phoenix” rompe las defensas Rowhammer en DDR5: 15 módulos de SK Hynix vulnerables, escalada a root en minutos" description: "Investigadores del Computer Security Group de ETH Zürich han presentado Phoenix , una nueva variante de Rowhammer que elude las mitigaciones en-DRAM de memoria DDR5 de SK Hynix —el mayor fabricante de..." url: https://revistacloud.com/phoenix-rompe-las-defensas-rowhammer-en-ddr5-15-modulos-de-sk-hynix-vulnerables-escalada-a-root-en-minutos/ date: 2025-09-17 modified: 2025-09-17 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2024/11/sk-hynix-ddr5.jpg categories: ["Seguridad"] tags: ["DRAM", "SK hynix"] type: post lang: es --- # “Phoenix” rompe las defensas Rowhammer en DDR5: 15 módulos de SK Hynix vulnerables, escalada a root en minutos Investigadores del **Computer Security Group** de ETH Zürich han presentado **Phoenix**, una nueva variante de **Rowhammer** que **elude las mitigaciones en-DRAM** de memoria **DDR5** de **SK Hynix** —el mayor fabricante de DRAM— y consigue **bit flips explotables** en todos los **15 DIMMs** analizados. El equipo demuestra **escalada de privilegios** en un PC con ajustes por defecto en **tan solo 109 segundos** (con medias de **5 minutos y 19 segundos**), y aporta un **exploit funcional** y artefactos de experimentación públicos. La vulnerabilidad se ha asignado como **CVE-2025-6202**. --- ## Contexto: Rowhammer en la era DDR5 Rowhammer es un fallo físico de la DRAM por el cual **accesos repetidos (hammering)** a filas “agresoras” inducen **flips de bits** en una fila “víctima” adyacente. Las generaciones recientes de memoria incorporan mitigaciones **in-DRAM** como **Target Row Refresh (TRR)** y **on-die ECC (ODECC)** para contener el fenómeno. Sin embargo, Phoenix muestra que **DDR5 no ha “solucionado” Rowhammer**: las mitigaciones analizadas **tienen puntos ciegos** y **ODECC no evita** que los flips se acumulen con el tiempo. --- ## Qué han descubierto: puntos ciegos en TRR y sincronización autocorrectiva Los investigadores **ingenierizaron inversamente** el TRR de SK Hynix con experimentos **FPGA** y un canal lateral basado en **errores de retención** para observar qué filas refresca la lógica interna ante patrones de hammering: - **Periodo de muestreo**: el TRR repite un patrón de muestreo cada **128 intervalos de refresco (tREFI)**, **8× más largo** que lo considerado por patrones Rowhammer previos. - **Zoom-in**: en los **primeros 64 tREFI** el muestreo es **inconsistente**; en los **últimos 64**, emerge una pauta en grupos de **4 intervalos** donde **casi nunca** se muestrean los **dos primeros** (“**lightly sampled**”). Esos huecos son los **puntos ciegos**. A partir de ahí crearon **dos patrones** nuevos que **evitan** las ventanas muestreadas y **golpean** las ligeramente muestreadas: - **Patrón corto (P128)**: 128 tREFI, martillea solo la segunda mitad, enfocando los dos intervalos “lightly sampled” y **nunca** los dos últimos; repetido **16×**. - **Patrón largo (P2608)**: 2.608 tREFI para un segundo tipo de dispositivo. **Resultados**: - En **15 DIMMs DDR5** de SK Hynix (fabricados entre 12/2021 y 12/2024), **todos** fueron vulnerables a **uno de los dos patrones**. - P128 fue **2,62×** más efectivo que P2608 (media **4.989** flips), pero ambos **bypassean** las mitigaciones. ### Sincronización “self-correcting” Los patrones son **hasta 163× más largos** que los tradicionales, de modo que **sincronizarse** con los refrescos periódicos (tREFI) en sistemas commodity resulta difícil. Phoenix introduce una **sincronización autocorrectiva** que **detecta desfases** y **realinea** la ejecución en base a la **periodicidad** de los refrescos, manteniéndose estable durante **miles** de intervalos (superando a sincronizadores previos como el de **Zenhammer**, incluso en variantes multihilo). ### Alineación y bancos en paralelo Solo **2 de 128** offsets de refresco son vulnerables (**1,56 %**). Phoenix **lanza instancias desplazadas** del patrón **en paralelo** sobre **4 bancos**, multiplicando por **16×** la probabilidad de “enganchar” el offset vulnerable (≈ **25 %**). --- ## Explotabilidad demostrada: PTE, RSA y sudo Los investigadores evaluaron **tres ataques end-to-end** con los flips obtenidos: 1. **PTE attack**: modificación de **page-table entries** para obtener **lectura/escritura arbitraria** en memoria. - **Todos** los DIMMs vulnerables. 2. **Exfiltración de claves RSA-2048** de una **VM colocalizada** para romper autenticación **SSH**. - **73 %** de los DIMMs vulnerables. 3. **Sudo attack**: corrupción de binario **sudo** para **escalar a root** localmente. - **33 %** de los DIMMs vulnerables. Además de un caso **mínimo de 109 segundos**, reportan **tiempos medios** de explotación PTE en torno a **5–10 minutos**, y demuestran la **primera escalada de privilegios Rowhammer en DDR5** reproducida en un PC con **ajustes por defecto**. --- ## ODECC no basta y por qué TRR falla - **ODECC**: corrige bits **al escribir** o **tras cierto tiempo** (p. ej., cada 24 h). Phoenix muestra que los flips **se acumulan** si se martillea lo suficiente, **bypasseando** ODECC (§5.2 del paper). - **TRR**: protege contra **patrones conocidos**, pero Phoenix explota un **diseño no “principled”** (muestreo **no uniforme** y **periodicidad** larga) para **golpear justo donde no mira**. **Conclusión**: las mitigaciones actuales **reducen** ataques triviales pero **no cierran** el problema; DDR5 **sigue expuesto** a Rowhammer con patrones y sincronización adecuados. --- ## Alcance y limitaciones - El estudio se centró en **SK Hynix** (“**el mayor fabricante**”) por el coste de ingeniería inversa; **no implica** que otros proveedores estén protegidos. - El **PoC** de Phoenix (código abierto) está **adaptado a AMD Zen 4**; si desencadena bit flips en tu equipo, tu DIMM está afectado por alguno de los patrones. - Phoenix está **divulgado responsablemente** (vía **NCSC Suiza**) desde el **6 de junio de 2025** a SK Hynix, vendors de CPU y grandes clouds; **embargo** hasta el **15 de septiembre de 2025**. - Se informó de una **actualización de BIOS** para **clientes AMD** (12 de septiembre), **no verificada independientemente** por los autores. --- ## Mitigaciones prácticas hoy (y su coste) - **Triplicar la tasa de refresco** (**tREFI ≈ 1,3 μs**, ~**3×**): **detuvo** Phoenix en los sistemas de prueba. - **Overhead medido**: **8,4 %** (SPEC CPU2017). - **Recomendaciones operativas**: - En **workloads sensibles** (nube multi-tenant, VDI, VMs colocalizadas, entornos de alta seguridad), evaluar **aumento de refresh** como **mitigación temporal**. - Monitorizar y **segmentar entornos** con contenido cruzado de tenants; minimizar **colocación** de agresor/víctima con **afinidad de memoria**. - Mantener **firmware/BIOS** actualizados y monitorizar avisos del fabricante. - Endurecer binarios sensibles (p. ej., sudo) con **integridad/verificación** adicional y **reducción de superficie**. - **A medio/largo plazo**: la industria DRAM necesita **mitigaciones “principled”** que aborden **periodicidad y muestreo** de forma comprobable, no solo listas de patrones. --- ## Qué deben hacer los equipos de seguridad y cloud 1. **Inventario** de DIMMs DDR5 (fabricante, lote, on-die ECC, geometría). 2. **Riesgo por caso de uso**: ¿hay **multi-tenancy**, **acceso de código arbitrario** (p. ej., usuarios sin privilegios), **workloads de terceros**, límites de integridad críticos (PTE, claves, binarios SUID)? 3. **Pruebas controladas**: uso del **PoC** (Zen 4) en **laboratorios** dedicados para validar exposición real. 4. **Políticas de refresco**: valorar **3× tREFI** en **sistemas de riesgo alto**, midiendo impacto y estableciendo **excepciones**. 5. **Detección y respuesta**: vigilar **corrupciones de memoria** atípicas, fallos inexplicables en PTE o binarios protegidos. --- ## Preguntas frecuentes (FAQ) **¿Esto significa que DDR5 de otros fabricantes está a salvo?** No. El estudio solo abarcó SK Hynix por coste de ingeniería inversa. Otros proveedores **podrían** ser vulnerables a patrones análogos. **¿Rowhammer no estaba “solucionado” en DDR5 con TRR y on-die ECC?** Phoenix prueba que **no**: TRR tiene **huecos de muestreo** explotables y el **ODECC** puede **bypass**earse acumulando flips con martilleo prolongado. **¿Qué impacto tiene aumentar la tasa de refresco 3×?** En las pruebas, **bloqueó** Phoenix con un coste de rendimiento de **≈8,4 %** (SPEC CPU2017). Es una **mitigación temporal** útil en entornos críticos. **¿Cómo sé si mis módulos SK Hynix DDR5 son vulnerables?** Los autores publican un **PoC** (orientado a **AMD Zen 4**) que intenta inducir bit flips con Phoenix. Si aparecen flips, ese DIMM es vulnerable a **P128 o P2608**. **¿Funciona la sincronización autocorrectiva también en DDR4?** Los autores creen que **sí**. No han cuantificado cuánto mejora resultados en DDR4, pero es **probable** que ayude. --- ## Referencias y disponibilidad - Phoenix será presentado en **IEEE Symposium on Security and Privacy 2026**. - **Código** y artefactos de investigación: **GitHub (comsec-group/phoenix)**. - **CVE-2025-6202**. - Publicación conjunta con **Google Security Blog**. --- ### Conclusión Phoenix eleva el listón: demuestra que **DDR5 sigue siendo susceptible** a Rowhammer pese a las mitigaciones en-DRAM de última generación. La combinación de **patrones largos**, **sincronización autocorrectiva** y **explotabilidad real** (PTE/RSA/sudo) obliga a **revaluar** supuestos de seguridad en **PCs**, **servidores** y, especialmente, en **nubes multi-tenant**. A falta de soluciones definitivas en hardware, la **mitigación operativa** (como el **3× refresh**) y la **defensa en profundidad** son, hoy, la mejor respuesta. vía: [comsec.ethz.ch](https://comsec.ethz.ch/research/dram/phoenix/)