Un equipo conjunto de investigadores de ETH Zürich y Google ha publicado un hallazgo crítico: una nueva variante de RowHammer, bautizada como Phoenix y registrada como CVE-2025-6202 (CVSS 7.1), que demuestra la capacidad de inducir bit flips fiables en módulos DDR5 fabricados por SK Hynix, a pesar de las defensas modernas como TRR (Target Row Refresh) y ECC integrado.
¿Qué hace diferente a Phoenix?
RowHammer es una vulnerabilidad de hardware conocida desde 2014: activaciones repetidas de una fila DRAM pueden provocar cambios de bits en filas adyacentes. Con Phoenix, los autores no solo reproducen ese efecto en DDR5, sino que además reverse-engineerizaron implementaciones TRR en los dispositivos objetivos y desarrollaron patrones de “hammer” adaptativos que explotan intervalos de refresco muestreados de forma predecible. El resultado fue la capacidad de forzar errores de memoria de manera consistente en 15 módulos DDR5 de prueba.
Impacto práctico: escalada de privilegios en 109 segundos
Los investigadores demostraron un exploit end-to-end que logra escalada de privilegios a root en un sistema de escritorio con DDR5 en tan solo 109 segundos, utilizando los bit flips inducidos para manipular estructuras de página y objetivos criptográficos como claves RSA-2048 en máquinas virtuales co-ubicadas (por ejemplo, para quebrar autenticación SSH) y para corromper binarios sensibles (por ejemplo, sudo) y obtener ejecución con privilegios. Esta demostración convierte a Phoenix en la primera prueba práctica documentada de RowHammer que alcanza escalada de privilegios en sistemas commodity con DDR5.
¿A qué módulos afecta y por qué es grave?
Las pruebas se realizaron contra DIMMs fabricados por SK Hynix producidos entre 2021 y 2024; en esos módulos Phoenix pudo disparar bit flips aprovechables. Dado que los chips DRAM no son actualizables en campo, la vulnerabilidad persiste en el hardware ya desplegado, lo que plantea un riesgo a largo plazo para sistemas de escritorio, estaciones de trabajo y potencialmente algunos servidores con esos módulos.
Por qué ECC y TRR no bastan
DDR5 introdujo mitigaciones on-die, incluyendo variantes de TRR y ECC (on-die ECC), con la expectativa de reducir la exposición a RowHammer. Sin embargo, Phoenix demuestra que:
-
Las implementaciones TRR pueden tener patrones de muestreo predecibles o intervalos que dejan “ventanas” explotables.
-
El ECC en chip no detiene por completo la explotación cuando los bit flips se inducen en ubicaciones críticas o cuando se coordinan para evitar correcciones automáticas.
Por eso, ataques sofisticados y orientados a objetivos pueden eludir las defensas que antes se consideraban suficientes.
Mitigaciones y recomendaciones prácticas
Los autores del estudio y varios analistas de seguridad coinciden en una serie de contramedidas y recomendaciones inmediatas:
-
Aumentar la frecuencia de refresco DRAM (Refresh Rate): en los experimentos, multiplicar la frecuencia de refresco por 3× impidió que Phoenix provocara cambios de bits en los sistemas probados, aunque con un impacto de rendimiento estimado (por ejemplo, ~8.4% en SPEC2017 según los autores). Esta es una mitigación eficaz pero con coste en rendimiento. comsec-files.ethz.ch
-
Políticas de hardening a nivel SO (host/BIOS/firmware): actualizar microcódigo y BIOS cuando los proveedores ofrezcan mitigaciones, aplicar restricciones de ejecución en entornos donde la integridad de memoria sea crítica y deshabilitar el uso no supervisado de hardware no fiable.
-
Segmentación de workloads sensibles: evitar la colocación co-residente de amenazas y cargas sensibles (p. ej. hosts con claves privadas) en la misma máquina física sin aislamiento reforzado.
-
Monitorización y detección a nivel de sistema: usar técnicas de detección de patrones de acceso anómalos a memoria y telemetría que identifiquen posibles cadenas de activaciones de filas que coincidan con patrones de hammering.
-
Defensa en profundidad: reforzar controles de identidad y privilegios (MFA, least privilege), así como auditoría y sensores de integridad binaria para mitigar el impacto si se logran bit flips explotables.
Relación con otras investigaciones recientes
La publicación de Phoenix llega pocas semanas después de otros trabajos que demostraron avances en RowHammer: OneFlip (que muestra impacto en modelos DNN) y ECC.fail (demostrando bypass ECC en DDR4 servidor). Estos desarrollos confirman una tendencia: las mitigaciones clásicas no son definitivas y los investigadores siguen encontrando vectores novedosos para explotar la fragilidad física de DRAM a medida que la densidad aumenta. arxiv.org+1
En fin…
Phoenix (CVE-2025-6202) es una llamada de atención para la industria: la transición a DDR5 no elimina el riesgo de RowHammer y, de hecho, introduce nuevas complejidades en las defensas on-die. Dado que el hardware existente no puede “parcharse” como el software, la respuesta debe combinar mitigaciones de firmware, configuraciones operativas (p. ej. refresh más agresivo), aislamiento arquitectónico y detección avanzada. Para infraestructuras críticas y entornos con datos sensibles, la planificación de contingencia y la revisión de la arquitectura de memoria son ya prioridades urgentes.
Fuente: The Hacker News
