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:
- PTE attack: modificación de page-table entries para obtener lectura/escritura arbitraria en memoria.
- Todos los DIMMs vulnerables.
- Exfiltración de claves RSA-2048 de una VM colocalizada para romper autenticación SSH.
- 73 % de los DIMMs vulnerables.
- 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
- Inventario de DIMMs DDR5 (fabricante, lote, on-die ECC, geometría).
- 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)?
- Pruebas controladas: uso del PoC (Zen 4) en laboratorios dedicados para validar exposición real.
- Políticas de refresco: valorar 3× tREFI en sistemas de riesgo alto, midiendo impacto y estableciendo excepciones.
- 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 bypassearse 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
