Row hammer

Summary

Rowhammer (también escrito como row hammer o RowHammer) es una vulnerabilidad de seguridad informática que aprovecha un efecto secundario no deseado en la memoria de acceso aleatorio dinámico (DRAM), en el cual las células de memoria interactúan eléctricamente entre sí al filtrar sus cargas, pudiendo alterar el contenido de filas de memoria cercanas que no fueron direccionadas en el acceso original a la memoria. Esta violación del aislamiento entre las células de memoria DRAM resulta de la alta densidad de células en las memorias DRAM modernas y puede desencadenarse mediante patrones de acceso a la memoria diseñados específicamente que activan repetidamente las mismas filas de memoria numerosas veces.[1][2][3]

El efecto Rowhammer ha sido utilizado en algunos exploits de escalada de privilegios en seguridad informática,[2][4][5][6]​ y también son teóricamente posibles los ataques basados en redes.[7][8]

Existen diferentes técnicas basadas en hardware para prevenir el efecto Rowhammer, incluyendo soporte requerido en algunos procesadores y tipos de módulos de memoria DRAM.[9][10]

Antecedentes

editar
 
Ilustración de alto nivel de la organización de DRAM, que incluye células de memoria (cuadrados azules), decodificadores de direcciones (rectángulos verdes) y amplificadores de detección (cuadrados rojos)

En la memoria DRAM, cada bit de datos almacenados ocupa una célula de memoria separada que se implementa eléctricamente con un condensador y un transistor. El estado de carga de un condensador (cargado o descargado) determina si una célula DRAM almacena "1" o "0" como un valor binario. Enormes cantidades de células de memoria DRAM se empaquetan en circuitos integrados, junto con lógica adicional que organiza las células para leer, escribir y refrescar los datos.[11][12]

Las células de memoria (cuadrados azules en ambas ilustraciones) se organizan además en matrices y se direccionan a través de filas y columnas. Una dirección de memoria aplicada a una matriz se divide en la dirección de fila y la dirección de columna, que son procesadas por los decodificadores de direcciones de fila y columna (en ambas ilustraciones, rectángulos verdes verticales y horizontales, respectivamente). Después de que una dirección de fila selecciona la fila para una operación de lectura (la selección también se conoce como activación de fila), los bits de todas las células en la fila se transfieren a los amplificadores de detección que forman el búfer de fila (cuadrados rojos en ambas ilustraciones), desde donde se selecciona el bit exacto usando la dirección de columna. En consecuencia, las operaciones de lectura son de naturaleza destructiva porque el diseño de DRAM requiere que las células de memoria se reescriban después de que sus valores han sido leídos al transferir las cargas de las células al búfer de fila. Las operaciones de escritura decodifican las direcciones de manera similar, pero debido al diseño, se deben reescribir filas completas para cambiar el valor de un solo bit.[1]: 2–3 [11][12][13]

Debido a que los datos se almacenan utilizando condensadores que tienen una tasa de descarga natural, las células de memoria DRAM pierden su estado con el tiempo y requieren una reescritura periódica de todas las células de memoria, un proceso conocido como refresco.[1]: 3 [11]​ Como otro resultado del diseño, la memoria DRAM es susceptible a cambios aleatorios en los datos almacenados, conocidos como errores de memoria suaves y atribuidos a rayos cósmicos y otras causas. Existen diferentes técnicas que contrarrestan los errores de memoria suaves y mejoran la fiabilidad de DRAM, de las cuales la memoria de código de corrección de errores (ECC) y sus variantes avanzadas (como la memoria en lockstep) son las más comúnmente utilizadas.[14]

Descripción general

editar
 
Las activaciones rápidas de filas (filas amarillas) pueden cambiar los valores de los bits almacenados en la fila víctima (fila púrpura).[15]: 2 

El aumento de la densidad de los circuitos integrados de DRAM ha llevado a células de memoria físicamente más pequeñas que contienen menos carga, lo que resulta en márgenes de ruido operativo más bajos, tasas aumentadas de interacciones electromagnéticas entre las células de memoria y una mayor posibilidad de pérdida de datos. Como resultado, se han observado «errores de perturbación», causados por la interferencia de las células entre sí y que se manifiestan como cambios aleatorios en los valores de los bits almacenados en las células de memoria afectadas. La conciencia de los errores de perturbación data de principios de la década de 1970 con el Intel 1103, los primeros circuitos integrados DRAM disponibles comercialmente; desde entonces, los fabricantes de DRAM han empleado diversas técnicas de mitigación para contrarrestar los errores de perturbación, como mejorar el aislamiento entre las células y realizar pruebas de producción. Sin embargo, los investigadores demostraron en un análisis de 2014 que los chips de DDR3 SDRAM fabricados en 2012 y 2013 son susceptibles a errores de perturbación, utilizando el término "Rowhammer" para nombrar el efecto secundario asociado que condujo a los cambios de bits observados.[1][3][15]

La oportunidad para que el efecto Rowhammer ocurra en la memoria DDR3[16]​ se atribuye principalmente a la alta densidad de células de memoria de DDR3 y a los resultados de las interacciones asociadas entre las células, mientras que las activaciones rápidas de filas DRAM se han determinado como la causa principal. Las activaciones frecuentes de filas causan fluctuaciones de voltaje en las líneas de selección de filas asociadas, lo que se ha observado que induce tasas de descarga más altas de lo normal en los condensadores pertenecientes a filas de memoria cercanas (adyacentes, en la mayoría de los casos), conocidas como "filas víctimas"; si las células de memoria afectadas no se refrescan antes de que pierdan demasiada carga, ocurren errores de perturbación. Las pruebas muestran que puede observarse un error de perturbación después de realizar alrededor de 139,000 accesos consecutivos a filas de memoria (con limpiezas de caché), y que hasta una célula de memoria en cada 1,700 células puede ser susceptible. Las pruebas también muestran que la tasa de errores de perturbación no se ve afectada sustancialmente por un aumento en la temperatura ambiental, mientras que depende del contenido real de DRAM porque ciertos patrones de bits resultan en tasas de error de perturbación significativamente más altas.[1][2][15][17]

Una variante llamada "martilleo de doble cara" implica activaciones dirigidas de dos filas DRAM que rodean una fila víctima: en la ilustración proporcionada en esta sección, esta variante activaría ambas filas amarillas con el objetivo de inducir cambios de bits en la fila púrpura, que en este caso sería la fila víctima. Las pruebas muestran que este enfoque puede resultar en una tasa de errores de perturbación significativamente más alta, en comparación con la variante que activa solo una de las filas DRAM vecinas de la fila víctima.[4][18]: 19–20 [19]

A medida que los proveedores de DRAM han implementado mitigaciones, los patrones han tenido que volverse más sofisticados para eludir las mitigaciones de Rowhammer. Los patrones más recientes incluyen patrones no uniformes basados en frecuencia.[20]​ Estos patrones consisten en muchos pares de agresores de doble cara donde cada uno de ellos es martilleado con una frecuencia, fase y amplitud diferentes. Usando esto y sincronizando los patrones con el comando REFRESH, es posible determinar de manera muy efectiva «puntos ciegos» donde la mitigación ya no puede proporcionar protección. Basándose en esta idea, académicos construyeron un fuzzer de Rowhammer llamado "Blacksmith"[21]​ que puede eludir las mitigaciones existentes en todos los dispositivos DDR4.

Mitigación

editar

Existen diferentes métodos para la detección, prevención, corrección o mitigación más o menos exitosa del efecto Rowhammer. Las pruebas muestran que el simple código de corrección de errores, que proporciona capacidades de corrección de errores de un solo bit y detección de errores dobles (SECDED), no es capaz de corregir o detectar todos los errores de perturbación observados porque algunos de ellos incluyen más de dos bits invertidos por palabra de memoria.[1]: 8 [15]: 32  Además, la investigación muestra que los cambios de bits de Rowhammer dirigidos con precisión a tres bits impiden que la memoria ECC note las modificaciones.[22][23]

Una solución menos efectiva es introducir un refresco de memoria más frecuente, con intervalos de refresco más cortos que los habituales 64 ms,[24]​ pero esta técnica resulta en un mayor consumo de energía y un mayor sobrecarga de procesamiento; algunos proveedores proporcionan actualizaciones de firmware que implementan este tipo de mitigación.[25]​ Una de las medidas de prevención más complejas realiza la identificación basada en contadores de filas de memoria accedidas frecuentemente y refresca proactivamente sus filas vecinas; otro método emite refrescos aleatorios poco frecuentes de filas de memoria vecinas a las filas accedidas, independientemente de su frecuencia de acceso. La investigación muestra que estas dos medidas de prevención causan impactos insignificantes en el rendimiento.[1]: 10–11 [26]

Desde el lanzamiento de la microarquitectura Ivy Bridge, los procesadores Intel Xeon soportan el llamado «refresco de fila objetivo pseudo» (pTRR) que puede usarse en combinación con módulos de memoria de doble línea DDR3 (DIMMs) compatibles con pTRR para mitigar el efecto Rowhammer al refrescar automáticamente las posibles filas víctimas, sin impacto negativo en el rendimiento o el consumo de energía. Cuando se usan con DIMMs que no son compatibles con pTRR, estos procesadores Xeon por defecto realizan refrescos de DRAM al doble de la frecuencia habitual, lo que resulta en una latencia de acceso a memoria ligeramente mayor y puede reducir el ancho de banda de memoria hasta en un 2–4%.[9]

El estándar de memoria móvil LPDDR4 publicado por JEDEC[27]​ incluye soporte de hardware opcional para el llamado «refresco de fila objetivo» (TRR) que previene el efecto Rowhammer sin impactar negativamente el rendimiento o el consumo de energía.[10][28][29]​ Además, algunos fabricantes implementan TRR en sus productos DDR4,[30][31]​ aunque no es parte del estándar de memoria DDR4 publicado por JEDEC.[32]​ Internamente, TRR identifica posibles filas víctimas contando el número de activaciones de filas y comparándolo con valores predefinidos específicos del chip de "conteo máximo de activaciones" (MAC) y "ventana máxima de activaciones" (tMAW). TRR también puede marcar una fila como víctima si la suma de activaciones de filas para sus dos filas vecinas alcanza el límite MAC dentro de la ventana de tiempo tMAW.[27][33]​ La investigación mostró que las mitigaciones TRR implementadas en UDIMMs DDR4 y chips LPDDR4X de dispositivos producidos entre 2019 y 2020 no son efectivas para proteger contra Rowhammer.[20]

Debido a la necesidad de enormes cantidades de activaciones rápidas de filas DRAM, los exploits de Rowhammer emiten grandes cantidades de accesos a memoria sin caché que causan fallos de caché, los cuales pueden detectarse monitoreando la tasa de fallos de caché para picos inusuales usando contadores de rendimiento de hardware.[4][34]

La versión 5.0 del software de diagnóstico de memoria MemTest86, lanzada el 3 de diciembre de 2013, añadió una prueba de Rowhammer que verifica si la RAM de la computadora es susceptible a errores de perturbación, pero solo funciona si la computadora arranca con UEFI; sin UEFI, arranca una versión anterior sin la prueba de martilleo.[35]

Implicaciones

editar

La protección de memoria, como una forma de prevenir que los procesos accedan a memoria que no les ha sido asignada, es uno de los conceptos detrás de la mayoría de los sistemas operativos modernos. Al usar la protección de memoria en combinación con otros mecanismos relacionados con la seguridad, como los anillos de protección, es posible lograr una separación de privilegios entre procesos, en la cual los programas y los sistemas informáticos en general se dividen en partes limitadas a los privilegios específicos que requieren para realizar una tarea particular. Usar la separación de privilegios también puede reducir la extensión del daño potencial causado por ataques de seguridad informática al restringir sus efectos a partes específicas del sistema.[36][37]

Los errores de perturbación (explicados en la sección anterior) derrotan efectivamente varias capas de protección de memoria al «cortocircuitarlas» a un nivel de hardware muy bajo, creando prácticamente un tipo único de vector de ataque que permite a los procesos alterar el contenido de partes arbitrarias de la memoria principal al manipular directamente el hardware de memoria subyacente.[2][4][18][38]​ En comparación, los vectores de ataque «convencionales» como los desbordamientos de búfer buscan eludir los mecanismos de protección a nivel de software, explotando varios errores de programación para lograr alteraciones de contenidos de memoria principal de otra manera inaccesibles.[39]

Exploits

editar
hammer:
  mov (X), %eax  // leer desde la dirección X
  mov (Y), %ebx  // leer desde la dirección Y
  clflush (X)    // vaciar caché para la dirección X
  clflush (Y)    // vaciar caché para la dirección Y
  jmp hammer
Un fragmento de código en ensamblador x86 que induce el efecto Rowhammer (las direcciones de memoria X y Y deben mapearse a diferentes filas DRAM en el mismo banco de memoria)[1]: 3 [4][18]: 13–15 

La investigación inicial sobre el efecto Rowhammer, publicada y presentada en junio de 2014 en el Simposio Internacional sobre Arquitectura de Computadoras, describió y analizó la naturaleza de los errores de perturbación de lectura en chips DRAM DDR3. Este artículo[1]​ estudió experimentalmente 129 módulos DRAM DDR3 reales de tres fabricantes de DRAM y demostró cambios de bits de perturbación en 110 de ellos. También mostró que un programa de nivel de usuario ejecutado en dos sistemas reales de Intel y AMD induce cambios de bits en la memoria principal. El trabajo indicó el potencial para construir un ataque, diciendo que "Con algo de esfuerzo de ingeniería, creemos que podemos desarrollar el Código 1a en un ataque de perturbación que inyecte errores en otros programas, cause fallos en el sistema, o incluso secuestre el control del sistema. Dejamos esa investigación para el futuro, ya que el objetivo principal en este trabajo es entender y prevenir los errores de perturbación en DRAM".[1]

Un artículo de investigación posterior de octubre de 2014 no implicó la existencia de problemas relacionados con la seguridad derivados del efecto Rowhammer.[16]

El 9 de marzo de 2015, Google's Project Zero reveló dos exploits de escalada de privilegios funcionales basados en el efecto Rowhammer, estableciendo su naturaleza explotable en la arquitectura x86-64. Uno de los exploits revelados apunta al mecanismo Google Native Client (NaCl) para ejecutar un subconjunto limitado de instrucciones de máquina x86-64 dentro de un sandbox,[18]: 27  explotando el efecto Rowhammer para escapar del sandbox y obtener la capacidad de emitir llamadas al sistema directamente. Esta vulnerabilidad de NaCl, rastreada como CVE-2015-0565, ha sido mitigada modificando el NaCl para que no permita la ejecución de la instrucción clflush (vaciado de línea de caché[40]​) instrucción de máquina, que anteriormente se creía necesaria para construir un ataque Rowhammer efectivo.[2][4][38]

El segundo exploit revelado por Project Zero se ejecuta como un proceso Linux sin privilegios en la arquitectura x86-64, explotando el efecto Rowhammer para obtener acceso sin restricciones a toda la memoria física instalada en una computadora. Al combinar los errores de perturbación con rociado de memoria, este exploit es capaz de alterar las entradas de tabla de páginas[18]: 35  utilizadas por el sistema de memoria virtual para mapear direcciones virtuales a direcciones físicas, lo que resulta en que el exploit obtenga acceso sin restricciones a la memoria.[18]: 34, 36–57  Debido a su naturaleza y la incapacidad de la arquitectura x86-64 para hacer de clflush una instrucción de máquina privilegiada, este exploit apenas puede mitigarse en computadoras que no usan hardware con mecanismos de prevención de Rowhammer integrados. Mientras probaban la viabilidad de los exploits, Project Zero encontró que aproximadamente la mitad de los 29 portátiles probados experimentaron errores de perturbación, con algunos ocurriendo en portátiles vulnerables en menos de cinco minutos de ejecución del código que induce Rowhammer; los portátiles probados fueron fabricados entre 2010 y 2014 y usaban memoria DDR3 no ECC.[2][4][38]

En julio de 2015, un grupo de investigadores publicó un artículo que describe una forma independiente de la arquitectura y el conjunto de instrucciones para explotar el efecto Rowhammer. En lugar de depender de la instrucción clflush para realizar vaciados de caché, este enfoque logra accesos a memoria sin caché al causar una tasa muy alta de expulsión de caché utilizando patrones de acceso a memoria cuidadosamente seleccionados. Aunque las políticas de reemplazo de caché difieren entre procesadores, este enfoque supera las diferencias arquitectónicas al emplear una estrategia de expulsión de caché adaptativa algoritmo.[18]: 64–68  La prueba de concepto para este enfoque se proporciona tanto como una implementación de código nativo, como una implementación pura en JavaScript que se ejecuta en Firefox 39. La implementación en JavaScript, llamada "Rowhammer.js",[41]​ usa grandes arrays tipados y depende de su asignación de memoria interna utilizando páginas grandes; como resultado, demuestra un exploit de muy alto nivel de una vulnerabilidad de muy bajo nivel.[42][43][44][45]

En octubre de 2016, los investigadores publicaron DRAMMER, una aplicación de Android que usa Rowhammer, junto con otros métodos, para obtener acceso root de manera confiable en varios teléfonos inteligentes populares.[46]​ La vulnerabilidad fue reconocida como CVE-2016-6728[47]​ y Google lanzó una mitigación dentro de un mes. Sin embargo, debido a la naturaleza general de las posibles implementaciones del ataque, es difícil implementar un parche de software efectivo de manera confiable. Hasta junio de 2018, la mayoría de las propuestas de parches hechas por la academia y la industria eran poco prácticas de implementar o insuficientes para detener todos los ataques. Como mitigación, los investigadores propusieron una defensa ligera que previene ataques basados en acceso directo a memoria (DMA) al aislar los búferes DMA con filas de guarda.[48][49]

En mayo de 2020, el trabajo TRRespass[50]​ mostró que los chips DRAM DDR4, que se afirmaban protegidos y resilientes contra Rowhammer, son en realidad vulnerables a Rowhammer. Este trabajo introdujo un nuevo patrón de acceso, llamado martilleo de múltiples lados, que elude las protecciones de Rowhammer implementadas dentro de los chips DRAM DDR4.

En mayo de 2021, un equipo de investigación de Google anunció un nuevo exploit, Half-Double, que aprovecha el empeoramiento de la física de algunos de los chips DRAM más nuevos.[51]

En marzo de 2024, un grupo de investigadores en ETH Zúrich anunció ZenHammer, un exploit de Rowhammer para chips AMD Zen, y también anunció el primer uso de Rowhammer para explotar DDR5 SDRAM.[52][53]

En junio de 2024, un grupo de investigadores en ETH Zúrich anunció RISC-H, un exploit de Rowhammer para chips RISC-V, siendo este el primer estudio de Rowhammer en RISC-V.[54]

Véase también

editar
  • Controlador de memoria - función del controlador de memoria que convierte los datos del usuario escritos en la memoria en patrones pseudoaleatorios
  • Resistencia a radiación - acción de hacer que los componentes electrónicos sean resistentes a los daños o fallos de funcionamiento causados por la radiación ionizante
  • Single event upset - cambio de estado causado por iones o radiación electromagnética que golpean un nodo sensible de un dispositivo electrónico
  • Soft error - tipo de error que implica cambios erróneos en las señales o los datos, pero ningún cambio en el dispositivo o circuito subyacente.

Referencias

editar
  1. a b c d e f g h i j Yoongu Kim; Ross Daly; Jeremie Kim; Chris Fallin; Ji Hye Lee; Donghyuk Lee; Chris Wilkerson; Konrad Lai et al. (24 de junio de 2014). «Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors» [Inversión de bits en la memoria sin acceder a ellos: Un estudio experimental de errores de perturbación en DRAM]. ece.cmu.edu. IEEE. Consultado el 7 de julio de 2025. 
  2. a b c d e f Goodin, Dan (10 de marzo de 2015). «Cutting-edge hack gives super user status by exploiting DRAM weakness» [Hackeo avanzado otorga estado de superusuario al explotar una debilidad en DRAM]. Ars Technica. Consultado el 7 de julio de 2025. 
  3. a b Ducklin, Paul (12 de marzo de 2015). «'Row hammering' – how to exploit a computer by overworking its memory» [«Row hammering» – cómo explotar una computadora sobrecargando su memoria]. Sophos. Consultado el 7 de julio de 2025. 
  4. a b c d e f g Seaborn, Mark; Dullien, Thomas (9 de marzo de 2015). «Exploiting the DRAM rowhammer bug to gain kernel privileges» [Explotando el fallo Rowhammer de DRAM para obtener privilegios de kernel]. googleprojectzero.blogspot.com. Consultado el 7 de julio de 2025. 
  5. «Using Rowhammer bitflips to root Android phones is now a thing» [Usar los cambios de bits de Rowhammer para obtener acceso root en teléfonos Android ya es una realidad]. Ars Technica. Consultado el 7 de julio de 2025. 
  6. Swati Khandelwal (3 de mayo de 2018). «GLitch: New 'Rowhammer' Attack Can Remotely Hijack Android Phones» [GLitch: Nuevo ataque «Rowhammer» puede secuestrar teléfonos Android de forma remota]. The Hacker News. Consultado el 7 de julio de 2025. 
  7. Mohit Kumar (10 de mayo de 2018). «New Rowhammer Attack Can Hijack Computers Remotely Over the Network» [Nuevo ataque Rowhammer puede secuestrar computadoras de forma remota a través de la red]. The Hacker News. Consultado el 7 de julio de 2025. 
  8. Swati Khandelwal (16 de mayo de 2018). «Nethammer—Exploiting DRAM Rowhammer Bug Through Network Requests» [Nethammer—Explotando el fallo Rowhammer de DRAM a través de solicitudes de red]. The Hacker News. Consultado el 7 de julio de 2025. 
  9. a b Marcin Kaczmarski (agosto de 2014). «Thoughts on Intel Xeon E5-2600 v2 Product Family Performance Optimisation – Component selection guidelines» [Reflexiones sobre la optimización del rendimiento de la familia de productos Intel Xeon E5-2600 v2 – Guías de selección de componentes]. Intel. p. 13. Archivado desde el original el 18 de abril de 2024. Consultado el 7 de julio de 2025. 
  10. a b Greenberg, Marc (15 de octubre de 2014). «Reliability, Availability, and Serviceability (RAS) for DDR DRAM interfaces» [Fiabilidad, disponibilidad y capacidad de servicio (RAS) para interfaces DDR DRAM]. memcon.com. pp. 2, 7, 10, 20, 27. Archivado desde el original el 5 de julio de 2016. Consultado el 7 de julio de 2025. 
  11. a b c «Lecture 12: DRAM Basics» [Lección 12: Fundamentos de DRAM]. utah.edu. 17 de febrero de 2011. pp. 2-7. Consultado el 7 de julio de 2025. 
  12. a b «Understanding DRAM Operation» [Comprendiendo el funcionamiento de DRAM]. IBM. diciembre de 1996. Archivado desde el original el 29 de agosto de 2017. Consultado el 7 de julio de 2025. 
  13. David August (23 de noviembre de 2004). «Lecture 20: Memory Technology» [Lección 20: Tecnología de memoria]. cs.princeton.edu. pp. 3-5. Archivado desde el original el 7 de julio de 2025. Consultado el 7 de julio de 2025. 
  14. Bianca Schroeder; Eduardo Pinheiro; Wolf-Dietrich Weber (25 de junio de 2009). «DRAM Errors in the Wild: A Large-Scale Field Study» [Errores de DRAM en la práctica: Un estudio de campo a gran escala]. cs.toronto.edu. ACM. Consultado el 7 de julio de 2025. 
  15. a b c d e Yoongu Kim; Ross Daly; Jeremie Kim; Chris Fallin; Ji Hye Lee; Donghyuk Lee; Chris Wilkerson; Konrad Lai et al. (24 de junio de 2014). «Flipping Bits in Memory Without Accessing Them: DRAM Disturbance Errors» [Inversión de bits en la memoria sin acceder a ellos: Errores de perturbación en DRAM]. ece.cmu.edu. Consultado el 7 de julio de 2025. 
  16. a b Kyungbae Park; Sanghyeon Baeg; ShiJie Wen; Richard Wong (octubre de 2014). «Active-precharge hammering on a row induced failure in DDR3 SDRAMs under 3× nm technology». Active-Precharge Hammering on a Row Induced Failure in DDR3 SDRAMs under 3x nm Technology [Martilleo activo-pre-carga en una fila que induce fallos en DDR3 SDRAM bajo tecnología de 3x nm]. IEEE. pp. 82-85. ISBN 978-1-4799-7308-8. S2CID 14464953. doi:10.1109/IIRW.2014.7049516. 
  17. Yoongu Kim; Ross Daly; Jeremie Kim; Chris Fallin; Ji Hye Lee; Donghyuk Lee; Chris Wilkerson; Konrad Lai et al. (30 de julio de 2015). «RowHammer: Reliability Analysis and Security Implications» [RowHammer: Análisis de fiabilidad e implicaciones de seguridad]. ece.cmu.edu. Consultado el 7 de julio de 2025. 
  18. a b c d e f g Mark Seaborn; Thomas Dullien (6 de agosto de 2015). «Exploiting the DRAM rowhammer bug to gain kernel privileges: How to cause and exploit single bit errors» [Explotando el fallo Rowhammer de DRAM para obtener privilegios de kernel: Cómo causar y explotar errores de un solo bit]. Black Hat. Consultado el 7 de julio de 2025. 
  19. Andy Greenberg (10 de marzo de 2015). «Googlers' Epic Hack Exploits How Memory Leaks Electricity» [Hackeo épico de Googlers explota cómo la memoria filtra electricidad]. Wired. Consultado el 7 de julio de 2025. 
  20. a b Jattke, Patrick; van der Veen, Victor; Frigo, Pietro; Gunter, Stijn; Razavi, Kaveh (25 de mayo de 2022). «Blacksmith: Scalable Rowhammering in the Frequency Domain» [Blacksmith: Martilleo de filas escalable en el dominio de la frecuencia]. comsec.ethz.ch. IEEE. Consultado el 7 de julio de 2025. 
  21. Blacksmith Rowhammer Fuzzer [Fuzzer de Rowhammer Blacksmith], 2 de noviembre de 2022, consultado el 7 de julio de 2025 .
  22. Cojocar, Lucian; Razavi, Kaveh; Giuffrida, Cristiano; Bos, Herbert (2019). «Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks». 2019 IEEE Symposium on Security and Privacy (SP) [Explotando códigos de corrección: Sobre la efectividad de la memoria ECC contra ataques Rowhammer]. IEEE. pp. 55-71. ISBN 978-1-5386-6660-9. doi:10.1109/sp.2019.00089. Consultado el 7 de julio de 2025. 
  23. VUsec, Systems and Network Security Group (11 de noviembre de 2018). «ECCploit: ECC Memory Vulnerable to Rowhammer Attacks After All» [ECCploit: La memoria ECC vulnerable a ataques Rowhammer después de todo]. Vrije Universiteit Amsterdam. Consultado el 7 de julio de 2025. 
  24. La investigación muestra que la tasa de errores de perturbación en una selección de módulos de memoria DDR3 se reduce a casi cero cuando el intervalo de refresco de memoria se vuelve aproximadamente siete veces más corto que el predeterminado de 64 ms.[15]: 17, 26 
  25. «Row Hammer Privilege Escalation (Lenovo Security Advisory LEN-2015-009)» [Escalada de privilegios Row Hammer (Aviso de seguridad de Lenovo LEN-2015-009)]. Lenovo. 5 de agosto de 2015. Consultado el 7 de julio de 2025. 
  26. Dae-Hyun Kim; Prashant J. Nair; Moinuddin K. Qureshi (9 de octubre de 2014). «Architectural Support for Mitigating Row Hammering in DRAM Memories» [Soporte arquitectónico para mitigar el martilleo de filas en memorias DRAM]. ece.gatech.edu. IEEE. Archivado desde el original el 11 de marzo de 2015. Consultado el 7 de julio de 2025. 
  27. a b «JEDEC standard JESD209-4A: Low Power Double Data Rate (LPDDR4)» [Estándar JEDEC JESD209-4A: Tasa de datos doble de baja potencia (LPDDR4)] (PDF). JEDEC. noviembre de 2015. pp. 222-223. Consultado el 7 de julio de 2025. 
  28. Kishore Kasamsetty (22 de octubre de 2014). «DRAM scaling challenges and solutions in LPDDR4 context» [Desafíos y soluciones de escalado de DRAM en el contexto de LPDDR4] (PDF). memcon.com. p. 11. Archivado desde el original el 3 de junio de 2016. Consultado el 7 de julio de 2025. 
  29. Omar Santos (9 de marzo de 2015). «Mitigations Available for the DRAM Row Hammer Vulnerability» [Mitigaciones disponibles para la vulnerabilidad Row Hammer de DRAM]. cisco.com. Consultado el 7 de julio de 2025. 
  30. Marc Greenber (9 de marzo de 2015). «Row Hammering: What it is, and how hackers could use it to gain access to your system» [Martilleo de filas: Qué es y cómo los hackers podrían usarlo para obtener acceso a tu sistema]. synopsys.com. Consultado el 7 de julio de 2025. 
  31. Jung-Bae Lee (7 de noviembre de 2014). «Green Memory Solution (Samsung Investors Forum 2014)» [Solución de memoria verde (Foro de inversores de Samsung 2014)] (PDF). teletogether.com. Samsung Electronics. p. 15. Consultado el 7 de julio de 2025. 
  32. «JEDEC standard JESD79-4A: DDR4 SDRAM» [Estándar JEDEC JESD79-4A: DDR4 SDRAM] (PDF). JEDEC. noviembre de 2013. Consultado el 7 de julio de 2025. 
  33. «Data Sheet: 4 Gb ×4, ×8 and ×16 DDR4 SDRAM Features» [Hoja de datos: Características de DDR4 SDRAM de 4 Gb ×4, ×8 y ×16]. Micron Technology. 20 de noviembre de 2015. pp. 48, 131. Archivado desde el original el 10 de febrero de 2018. Consultado el 7 de julio de 2025. 
  34. Nishad Herath; Anders Fogh (6 de agosto de 2015). «These are Not Your Grand Daddy's CPU Performance Counters: CPU Hardware Performance Counters for Security» [Estos no son los contadores de rendimiento de CPU de tu abuelo: Contadores de rendimiento de hardware de CPU para seguridad]. Black Hat. pp. 29, 38-68. Consultado el 7 de julio de 2025. 
  35. «PassMark MemTest86 – Version History» [PassMark MemTest86 – Historial de versiones]. memtest86.com. 13 de febrero de 2015. Consultado el 7 de julio de 2025. 
  36. Pehr Söderman (2011). «Memory Protection» [Protección de memoria]. csc.kth.se. Archivado desde el original el 2 de abril de 2015. Consultado el 7 de julio de 2025. 
  37. Niels Provos; Markus Friedl; Peter Honeyman (10 de agosto de 2003). «Preventing Privilege Escalation» [Previniendo la escalada de privilegios]. niels.xtdnet.nl. Consultado el 7 de julio de 2025. 
  38. a b c Liam Tung (10 de marzo de 2015). «"Rowhammer" DRAM flaw could be widespread, says Google» [La falla de DRAM «Rowhammer» podría estar extendida, dice Google]. ZDNet. Consultado el 7 de julio de 2025. 
  39. Murat Balaban (6 de junio de 2009). «Buffer Overflows Demystified» [Desbordamientos de búfer desmitificados] (TXT). enderunix.org. Archivado desde el original el 7 de julio de 2025. Consultado el 7 de julio de 2025. 
  40. «CLFLUSH: Flush Cache Line (x86 Instruction Set Reference)» [CLFLUSH: Vaciado de línea de caché (Referencia del conjunto de instrucciones x86)]. renejeschke.de. 3 de marzo de 2013. Archivado desde el original el 3 de diciembre de 2017. Consultado el 7 de julio de 2025. 
  41. Daniel Gruss; Clémentine Maurice (27 de julio de 2015). «IAIK/rowhammerjs: rowhammerjs/rowhammer.js at master» [IAIK/rowhammerjs: rowhammerjs/rowhammer.js en master]. github.com. Consultado el 7 de julio de 2025. 
  42. Daniel Gruss; Clementine Maurice; Stefan Mengard (24 de julio de 2015). «Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript». arXiv:1507.06955  [cs.CR]. 
  43. David Auerbach (28 de julio de 2015). «Rowhammer security exploit: Why a new security attack is truly terrifying» [Exploit de seguridad Rowhammer: Por qué un nuevo ataque de seguridad es verdaderamente aterrador]. slate.com. Consultado el 7 de julio de 2025. 
  44. Alix Jean-Pharuns (30 de julio de 2015). «Rowhammer.js Is the Most Ingenious Hack I've Ever Seen» [Rowhammer.js es el hackeo más ingenioso que he visto]. Motherboard. 
  45. Dan Goodin (4 de agosto de 2015). «DRAM 'Bitflipping' exploit for attacking PCs: Just add JavaScript» [Exploit de «Bitflipping» de DRAM para atacar PCs: Solo añade JavaScript]. Ars Technica. 
  46. VUSec (octubre de 2016). «DRAMMER: FLIP FENG SHUI GOES MOBILE» [DRAMMER: FLIP FENG SHUI SE VUELVE MÓVIL]. Consultado el 7 de julio de 2025. 
  47. NIST National Vulnerability Database (NVD). «CVE-2016-6728 Detail» [Detalle de CVE-2016-6728]. 
  48. Victor van der Veen; Martina Lindorfer; Yanick Fratantonio; Harikrishnan Padmanabha Pillai; Giovanni Vigna; Christopher Kruegel; Herbert Bos; Kaveh Razavi (2018), «GuardION: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM» [GuardION: Mitigación práctica de ataques Rowhammer basados en DMA en ARM], Detection of Intrusions and Malware, and Vulnerability Assessment (Springer International Publishing): 92-113, ISBN 9783319934105, doi:10.1007/978-3-319-93411-2_5, hdl:1871.1/112a5465-aeb5-40fd-98ff-6f3b7c976676 .
  49. «RAMPAGE AND GUARDION - Vulnerabilities in modern phones enable unauthorized access» [RAMPAGE Y GUARDION - Vulnerabilidades en teléfonos modernos permiten acceso no autorizado]. Consultado el 7 de julio de 2025. 
  50. Pietro Frigo; Emanuele Vannacci; Hasan Hassan; Victor van der Veen; Onur Mutlu; Cristiano Giuffrida; Herbert Bos; Kaveh Razavi (2020). «TRRespass: Exploiting the Many Sides of Target Row Refresh». arXiv:2004.01807  [cs.CR]. 
  51. «Introducing Half-Double: New hammering technique for DRAM Rowhammer bug» [Presentando Half-Double: Nueva técnica de martilleo para el fallo Rowhammer de DRAM]. Google. 25 de mayo de 2021. Consultado el 7 de julio de 2025. 
  52. Toulas, Bill. «New ZenHammer memory attack impacts AMD Zen CPUs» [Nuevo ataque de memoria ZenHammer afecta a CPUs AMD Zen]. BleepingComputer (en inglés estadounidense). Consultado el 7 de julio de 2025. 
  53. «ZenHammer: Rowhammer Attacks on AMD Zen-based Platforms» [ZenHammer: Ataques Rowhammer en plataformas basadas en AMD Zen]. Computer Security Group (en inglés estadounidense). Consultado el 7 de julio de 2025. 
  54. «Rowhammer Bit Flips On A High-End RISC-V CPU (ETH Zurich)» [Cambios de bits de Rowhammer en una CPU RISC-V de alta gama (ETH Zúrich)]. semiengineering (en inglés estadounidense). 13 de junio de 2024. Consultado el 7 de julio de 2025. 

Enlaces externos

editar
  • Algunas notas sobre DRAM (#rowhammer), 9 de marzo de 2015, por Robert Graham
  • La falla de hardware Rowhammer amenaza con romper la seguridad de los portátiles, InfoWorld, 9 de marzo de 2015, por Serdar Yegulalp
  • DDR3 Memory Known Failure Mechanism called "Row Hammer" en YouTube., 17 de julio de 2014, por Barbara Aichinger
  • Patente US 20140059287 A1: Row hammer refresh command, 27 de febrero de 2014, por Kuljit Bains et al.
  • Vulnerabilidad de escalada de privilegios Row Hammer, Aviso de seguridad de Cisco Systems, 11 de marzo de 2015
  • ARMOR: Un detector de filas calientes en tiempo de ejecución, Universidad de Mánchester, por Mohsen Ghasempour et al.
  • Usando errores de memoria para atacar una máquina virtual, 6 de marzo de 2003, por Sudhakar Govindavajhala y Andrew W. Appel
  • Un programa para probar el problema de "rowhammer" en DRAM, código fuente en GitHub