{"id":28647,"date":"2025-10-22T09:48:07","date_gmt":"2025-10-22T15:48:07","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=28647"},"modified":"2025-10-22T09:48:07","modified_gmt":"2025-10-22T15:48:07","slug":"phoenix-rowhammer-attack","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/phoenix-rowhammer-attack\/28647\/","title":{"rendered":"Phoenix: un ataque Rowhammer contra la memoria DDR5"},"content":{"rendered":"

En septiembre de 2025, investigadores de ETH Zurich (el Instituto Federal de Tecnolog\u00eda de Suiza) publicaron un art\u00edculo<\/a> en el que presentaban Phoenix, una modificaci\u00f3n de ataque Rowhammer que funciona en m\u00f3dulos de memoria DDR5. Los autores no solo demostraron la eficacia del nuevo ataque contra los 15\u00a0m\u00f3dulos probados, sino que tambi\u00e9n propusieron tres\u00a0casos de uso pr\u00e1ctico: leer y escribir datos de la memoria, robar una clave de cifrado privada almacenada en la memoria y eludir las protecciones de la utilidad sudo de Linux para escalar privilegios.<\/p>\n

Ataque Rowhammer: una breve historia<\/h2>\n

Para comprender este estudio bastante complejo, primero debemos repasar brevemente la historia de Rowhammer. El ataque Rowhammer se describi\u00f3 por primera vez en un art\u00edculo de investigaci\u00f3n<\/a> de 2014. En aquel entonces, investigadores de la Universidad Carnegie Mellon e Intel demostraron c\u00f3mo el acceso repetido a filas de celdas de memoria pod\u00eda provocar cambios en el valor de las celdas de memoria adyacentes. Estas celdas vecinas podr\u00edan contener datos cr\u00edticos, cuya alteraci\u00f3n podr\u00eda tener graves consecuencias (como la escalada de privilegios).<\/p>\n

Esto ocurre porque cada celda de un chip de memoria es, en esencia, un condensador: un componente sencillo que solo puede almacenar carga el\u00e9ctrica durante un breve per\u00edodo de tiempo. Por eso, este tipo de memoria es vol\u00e1til: si se apaga el ordenador o el servidor, los datos desaparecen. Por la misma raz\u00f3n, la carga en las celdas debe actualizarse con frecuencia, incluso si nadie accede a esa regi\u00f3n de memoria<\/em>.<\/p>\n

Las celdas de memoria no est\u00e1n aisladas; est\u00e1n organizadas en filas y columnas, interconectadas de manera que pueden causar interferencias. El acceso a una fila puede afectar a una fila vecina; por ejemplo, actualizar una fila puede da\u00f1ar los datos de otra. Durante a\u00f1os, este efecto solo era conocido por los fabricantes de memorias, quienes hac\u00edan todo lo posible por mitigarlo con el fin de mejorar la fiabilidad. Pero, a medida que las celdas se hicieron m\u00e1s peque\u00f1as y, por lo tanto, se agruparon m\u00e1s estrechamente, el efecto \u201crow hammering\u201d (martilleo de fila) pas\u00f3 a ser explotable en ataques en el mundo real.<\/p>\n

Despu\u00e9s de que se demostr\u00f3 el ataque Rowhammer, los desarrolladores de memoria comenzaron a introducir defensas, lo que dio lugar a la tecnolog\u00eda de hardware Target Row Refresh (TRR). En teor\u00eda, la TRR es sencilla: supervisa el acceso agresivo a las filas y, si se detecta, actualiza a la fuerza las filas adyacentes. En la pr\u00e1ctica, no fue tan eficaz. En 2021, los investigadores describieron el ataque Blacksmith<\/a>, que eludi\u00f3 la TRR utilizando patrones de acceso a c\u00e9lulas de memoria m\u00e1s sofisticados.<\/p>\n

Los desarrolladores volvieron a adaptarse, a\u00f1adiendo defensas a\u00fan m\u00e1s avanzadas contra ataques tipo Rowhammer en los m\u00f3dulos DDR5 y aumentando la frecuencia de actualizaci\u00f3n forzada. Para impedir nuevos ataques, los fabricantes evitaron revelar qu\u00e9 medidas de protecci\u00f3n hab\u00edan adoptado. Esto llev\u00f3 a muchos a creer que DDR5 hab\u00eda resuelto eficazmente el problema de Rowhammer. Sin embargo, el a\u00f1o pasado, investigadores de la misma ETH Zurich lograron atacar con \u00e9xito<\/a> los m\u00f3dulos DDR5, aunque bajo ciertas condiciones: la memoria deb\u00eda estar emparejada con una CPU AMD Zen\u00a02 o Zen\u00a03 e, incluso as\u00ed, algunos m\u00f3dulos no se vieron afectados.<\/p>\n

Caracter\u00edsticas del nuevo ataque<\/h2>\n

Para desarrollar Phoenix, los investigadores aplicaron ingenier\u00eda inversa al mecanismo TRR. Analizaron su comportamiento en varios patrones de acceso a las filas de la memoria y comprobaron si la protecci\u00f3n se activaba para las filas adyacentes. Result\u00f3 que la TRR se ha vuelto significativamente m\u00e1s compleja y los patrones de acceso conocidos anteriormente ya no funcionan; la protecci\u00f3n ahora marca correctamente esos patrones como potencialmente peligrosos y actualiza a la fuerza las filas adyacentes. Como resultado, los investigadores descubrieron que, despu\u00e9s de 128\u00a0accesos a la memoria rastreados por TRR, aparece una \u201cventana de oportunidad\u201d de 64\u00a0accesos, durante la cual las defensas son m\u00e1s d\u00e9biles. No es que el sistema de protecci\u00f3n falle por completo, pero sus respuestas son insuficientes para evitar un cambio de valor en una celda de memoria espec\u00edfica. La segunda ventana se presenta despu\u00e9s de acceder a las celdas de memoria en el transcurso de 2608\u00a0intervalos de actualizaci\u00f3n.<\/p>\n

Luego, los investigadores estudiaron estos puntos vulnerables en detalle para lanzar un ataque muy espec\u00edfico contra las c\u00e9lulas de memoria, al tiempo que neutralizaban las defensas. En pocas palabras, el ataque funciona as\u00ed: el c\u00f3digo malicioso realiza una serie de accesos ficticios que efectivamente adormecen el mecanismo TRR en una falsa sensaci\u00f3n de seguridad. Luego, ocurre la fase activa del ataque, que finalmente modifica el valor de la celda objetivo. Como resultado, el equipo confirm\u00f3 que el ataque funcionaba de forma fiable contra los 15\u00a0m\u00f3dulos DDR5 probados que hab\u00eda fabricado SK Hynix, uno de los l\u00edderes del mercado.<\/p>\n

Tres\u00a0escenarios de ataque reales<\/h2>\n

Un ataque realista debe cambiar un valor en una regi\u00f3n de memoria definida con precisi\u00f3n, lo cual es una tarea dif\u00edcil. En primer lugar, un atacante necesita un conocimiento detallado del software objetivo. Debe eludir m\u00faltiples controles de seguridad convencionales, y perder el objetivo por solo uno o dos\u00a0bits puede provocar un fallo del sistema en lugar de un ataque exitoso.<\/p>\n

Los investigadores suizos se propusieron demostrar que Phoenix podr\u00eda usarse para causar da\u00f1os en el mundo real. Evaluaron tres\u00a0escenarios de ataque. El primero (PTE) consisti\u00f3 en acceder a la tabla de p\u00e1ginas para crear las condiciones necesarias para la lectura\/escritura arbitraria de datos de la RAM. El segundo (RSA) tuvo como objetivo robar una clave de cifrado privada RSA-2048 de la memoria. El tercero (sudo) implic\u00f3 eludir las protecciones de la utilidad sudo est\u00e1ndar de Linux con el objetivo de escalar privilegios. Los resultados finales del estudio se muestran en la siguiente tabla:<\/p>\n

\"Eficacia<\/a>

Eficacia del ataque Phoenix. Fuente<\/a><\/p><\/div>\n

Para algunos m\u00f3dulos, la primera variante de ataque (128\u00a0intervalos de actualizaci\u00f3n) fue eficaz, mientras que para otros solo funcion\u00f3 el segundo m\u00e9todo (intervalos de 2608). En algunos experimentos, el robo de claves RSA y las vulnerabilidades de sudo no tuvieron \u00e9xito. Sin embargo, se encontr\u00f3 un m\u00e9todo para la lectura\/escritura de memoria arbitraria para todos los m\u00f3dulos, y el tiempo de explotaci\u00f3n fue relativamente corto para esta clase de ataques, desde unos cinco\u00a0segundos hasta siete\u00a0minutos. Eso es suficiente para demostrar que los ataques Rowhammer suponen un riesgo real, aunque en un conjunto de escenarios muy restringido.<\/p>\n

Relevancia y contramedidas<\/h2>\n

El ataque Phoenix demuestra que los ataques Rowhammer pueden llevarse a cabo contra m\u00f3dulos DDR5 con la misma eficacia que contra DDR4 y DDR3. Aunque solo se probaron m\u00f3dulos de un \u00fanico proveedor, y los investigadores descubrieron una vulnerabilidad bastante sencilla en el algoritmo TRR de ese proveedor que probablemente ser\u00e1 f\u00e1cil de solucionar, esto supone un importante avance en la investigaci\u00f3n sobre la seguridad de los m\u00f3dulos de memoria.<\/p>\n

Los autores propusieron varias contramedidas ante ataques Rowhammer. Primero, reducir el intervalo de actualizaci\u00f3n forzado en todas las celdas puede impedir significativamente el ataque. Esto puede aumentar el consumo de energ\u00eda y la temperatura del chip, pero es una soluci\u00f3n sencilla. En segundo lugar, se puede utilizar la memoria con un c\u00f3digo de correcci\u00f3n de errores (ECC). Esto complica los ataques Rowhammer, aunque, parad\u00f3jicamente, no los hace completamente imposibles<\/a>.<\/p>\n

M\u00e1s all\u00e1 de estas medidas obvias, los autores mencionan dos m\u00e1s. La primera es el m\u00e9todo de protecci\u00f3n Fine Granularity Refresh, que ya se est\u00e1 implementando. Integrado en el controlador de memoria del procesador, modifica el comportamiento de actualizaci\u00f3n de las celdas de memoria para resistir los ataques Rowhammer. En cuanto a la segunda, los investigadores instan a los desarrolladores de m\u00f3dulos de memoria y chips a que dejen de depender de medidas de seguridad propietarias (\u201cseguridad mediante opacidad\u201d). En cambio, recomiendan adoptar un enfoque com\u00fan en la criptograf\u00eda, donde los algoritmos de seguridad est\u00e1n disponibles p\u00fablicamente y sujetos a pruebas independientes.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Investigadores en Suiza han encontrado una forma de atacar los m\u00f3dulos de memoria DDR5.<\/p>\n","protected":false},"author":665,"featured_media":28648,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[6],"tags":[104,5905,647],"class_list":{"0":"post-28647","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-news","8":"tag-hardware","9":"tag-memoria","10":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/phoenix-rowhammer-attack\/28647\/"},{"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":"ar","url":"https:\/\/me.kaspersky.com\/blog\/phoenix-rowhammer-attack\/12862\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/phoenix-rowhammer-attack\/29588\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/phoenix-rowhammer-attack\/31534\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/phoenix-rowhammer-attack\/30189\/"},{"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":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/phoenix-rowhammer-attack\/23285\/"},{"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:\/\/latam.kaspersky.com\/blog\/tag\/hardware\/","name":"hardware"},"_links":{"self":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/28647","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=28647"}],"version-history":[{"count":3,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/28647\/revisions"}],"predecessor-version":[{"id":28653,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/28647\/revisions\/28653"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/28648"}],"wp:attachment":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=28647"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=28647"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=28647"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}