- Se produjeron bit flips de Rowhammer incluso en sistemas AMD Zen 2 y Zen 3 con DDR4 que tenían mitigación TRR, lo que indica que la plataforma AMD también puede ser una superficie de ataque real
- El equipo de investigación aplicó una técnica DRAMA adaptada a AMD para hacer ingeniería inversa de la función secreta de direcciones DRAM, y confirmó que, debido al remapeo de direcciones del sistema, era necesario manejar offsets de direcciones físicas
- El fuzzer ZenHammer provocó bit flips en 7 de 10 dispositivos en Zen 2 y 6 de 10 en Zen 3, entre 10 dispositivos DDR4 de Samsung, Micron y SK Hynix, y los dispositivos Zen 3 resultaron más vulnerables que Intel Coffee Lake
- Los ataques existentes contra tablas de páginas, la corrupción de claves públicas RSA-2048 y
sudoers.sopudieron configurarse en 7/6/4 dispositivos, respectivamente, y el tiempo promedio para encontrar bit flips explotables fue de 164/267/209 segundos - En la evaluación de DDR5 sobre Zen 4, un dispositivo de 10 presentó cerca de 42,000 bit flips, pero en los otros 9 no se logró, por lo que hacen falta más estudios de patrones para DDR5
Bit flips de Rowhammer también en AMD Zen
- ZenHammer provoca bit flips de Rowhammer en dispositivos DDR4 con mitigación TRR sobre sistemas AMD Zen 2 y Zen 3
- Se confirmó que los sistemas AMD, al igual que los sistemas Intel, también pueden tener vulnerabilidad a Rowhammer
- Dado que AMD tiene alrededor de 36% de participación en el mercado de CPU x86 de escritorio, la superficie de ataque no es pequeña
- Los dispositivos DRAM son difíciles de corregir fácilmente una vez desplegados, y estudios previos ya mostraron que los ataques Rowhammer pueden ser prácticos en distintos entornos
Ingeniería inversa de la función de direcciones DRAM de AMD y optimización del hammering
- Aplicaron la técnica DRAMA a sistemas AMD para hacer ingeniería inversa de la función secreta de direcciones DRAM
- Modificaron la rutina de temporización para obtener resultados más estables
- Debido al remapeo de direcciones del sistema, fue necesario aplicar un offset de dirección física antes de reconstruir la función de direcciones DRAM, lo que permitió recuperarla por completo
- Usar solo la función de direcciones recuperada limitó la cantidad de bit flips
- En Zen 2, solo se confirmaron bit flips en 5 de 10 dispositivos
- En Zen 3, se confirmaron bit flips en 0 de 10 dispositivos
Sincronización de refresh y secuencias de comandos
- Igual que en investigaciones previas como SMASH y Blacksmith, la sincronización de refresh fue un factor clave para provocar bit flips
- En AMD, realizar mediciones continuas de tiempo sobre filas no repetidas fue efectivo para una sincronización de refresh precisa y confiable
- En sistemas AMD Zen+/3, la tasa de activación de patrones Rowhammer no uniformes fue mucho menor que en Intel Coffee Lake
- La secuencia óptima de comandos de hammering usó cargas normales
MOVyCLFLUSHOPTpara expulsar los aggressors de la caché, y un estilo “scatter” que hace flush justo después de acceder al aggressor - A diferencia de Zen 2, en Zen 3 no fue necesario un fence explícito después del flush
- El tipo de fence y la política de scheduling del fence también afectaron los resultados, y el equipo propuso 6 políticas de reconocimiento de patrones y evasión de caché, probándolas durante 6 horas por dispositivo
- En la mayoría de los dispositivos Zen 2,
SP_nonefue lo óptimo - En la mayoría de los casos de Zen 3,
SP_pairfue más adecuado
- En la mayoría de los dispositivos Zen 2,
Resultados de la evaluación en DDR4 y posibilidad de explotación
- La evaluación se realizó sobre 10 dispositivos DRAM DDR4 de Samsung, Micron y SK Hynix
- El fuzzer ZenHammer se ejecutó 3 horas por cada combinación de tipo de fence,
mfence,sfence, y cada política de scheduling del fence - Después de cada ejecución, se hizo un minisweep en un rango de 4MiB con todos los patrones encontrados para determinar el mejor patrón, y luego se aplicó un sweep del mejor patrón de la mejor política sobre una región contigua de memoria de 256MB
- Como resultado, se produjeron bit flips en 7 de 10 dispositivos en Zen 2 y 6 de 10 en Zen 3 entre los 10 dispositivos DRAM DDR4
- La explotabilidad de los bit flips se evaluó con tres ataques de investigaciones previas
- Un ataque que apunta al page frame number de una entrada de tabla de páginas para pivotar hacia una página de tabla de páginas controlada por el atacante
- Un ataque de clave pública RSA-2048 que permite recuperar la clave privada relacionada usada para autenticación de hosts SSH
- Un ataque contra la lógica de verificación de contraseñas de la biblioteca
sudoers.so, que permite obtener privilegios de root
- Los ataques existentes pudieron configurarse en 7/6/4 dispositivos, respectivamente, y el tiempo promedio para encontrar bit flips explotables fue de 164/267/209 segundos
Evaluación en DDR5, código público y calendario de divulgación
- También hicieron ingeniería inversa de la función DRAM DDR5 en AMD Zen 4 y evaluaron 10 dispositivos DDR5
- ZenHammer provocó cerca de 42,000 bit flips en 1 de 10 dispositivos DDR5
- Este es el primer caso reportado públicamente de bit flips en DDR5 sobre un sistema comercial común
- En los otros 9 dispositivos DDR5 no se produjeron bit flips, por lo que se necesita investigación adicional para encontrar patrones más efectivos para DDR5
- Todos los detalles completos están en el paper que se presentará en USENIX Security 2024 en agosto de 2024
- El código del fuzzer ZenHammer está disponible en GitHub y puede usarse para evaluar si los dispositivos DRAM presentan bit flips en CPU AMD Zen 2/3/4
- Consideraron que Rowhammer es un problema conocido en toda la industria y que no requería un proceso de divulgación general, pero notificaron a AMD el 26 de febrero de 2024 y, a solicitud de AMD, no lo publicaron hasta el 25 de marzo de 2024
- Esta página se publicó brevemente por error en línea el 21 de marzo de 2024
Limitaciones prácticas del FAQ
- La razón por la que antes se trató menos a los sistemas AMD es que en la investigación original de Rowhammer los sistemas Intel presentaban muchos más bit flips, los estudios posteriores también se centraron principalmente en Intel, y se conocía más información sobre microarquitectura de CPU Intel que de AMD
- Aunque en 3 dispositivos sobre 10 en Zen 2 y 4 sobre 10 en Zen 3 no se produjeron bit flips, en Intel Coffee Lake esos mismos dispositivos también mostraron pocos bit flips, por lo que creen que, ajustando más el fuzzer, podrían hacerse visibles
- La razón de limitar la evaluación a 10 dispositivos fue la cantidad reducida de equipos AMD Zen 2/3 en el laboratorio y el largo tiempo de algunos experimentos; el subconjunto aleatorio sí incluía dispositivos de los 3 proveedores de DRAM
- Sobre por qué JEDEC aún no ha resuelto el problema, explican que solucionar Rowhammer es difícil, pero no imposible, y que investigaciones previas como ProTRR y REGA ya lo mostraron
- Una investigación previa sobre DDR3 mostró que ECC no puede detener Rowhammer, y como los dispositivos DDR4 actuales presentan más bit flips, consideran que ECC no brinda protección completa, sino que solo hace más difícil la explotación
- El enfoque de duplicar la tasa de refresh tiene overhead de rendimiento y mayor consumo de energía, y estudios previos como Mutlu et al. y Frigo et al. lo muestran como una solución débil que no ofrece protección completa
1 comentarios
Opiniones en Hacker News
Soy coautor del exploit Rowhammer original. ECC sigue siendo muy eficaz para convertir este problema, en gran medida, de un tema de seguridad a uno de confiabilidad.
Si eres dueño de un servidor personal, el impacto en seguridad no es grande si esperas que tu servidor tenga ECC y que puedas notar una interrupción de la máquina causada por un error ECC no corregible.
Pero si eres un proveedor de nube que ofrece VMs en un host multi-tenant, el modelo de amenaza puede cambiar.
En cualquier caso, hay que evitar las máquinas sin ECC. TRR ya era una defensa fallida cuando Rowhammer recién se dio a conocer, y mientras no cambie la economía de fabricación de DRAM, los bit flips en DRAM no van a desaparecer.
Ryzen solo soporta ECC unbuffered, que es más lenta, más cara o ambas cosas que la memoria sin ECC de la misma capacidad.
La línea Threadripper más reciente soporta Registered ECC, pero para un usuario doméstico como yo es excesiva en costo, hilos y lanes PCIe.
El riesgo de seguridad es demasiado grande y todo está demasiado integrado como para seguir postergando este cambio. Incluso un gamer que usa una computadora solo para juegos probablemente pondrá información importante en esa máquina, así que no entiendo que este cambio no haya ocurrido hasta ahora.
También me pregunto si lo único verdaderamente inmune es SRAM.
Solo Pro y Threadripper están garantizados, y algunos Ryzen de escritorio solo funcionan con algunas placas madre.
¿Qué tan agresivamente tendría que escanear la DRAM un motor de lectura de patrulla para adelantarse de forma segura a los bit flips inducidos por Rowhammer?
Con palabras ECC más grandes que el tradicional 64+8 y corrección de errores de múltiples bits, ¿cambia lo suficiente el panorama como para construir sistemas más confiables incluso con DRAM que tenga vulnerabilidades de patrón?
Expresiones como “ECC no puede detener Rowhammer” son muy engañosas. El paper citado también dice que “incluso cuando la detección ECC se usa correctamente, entre el 0.65% y el 7.42% de todos los bit flips causan corrupción silenciosa… en la configuración AMD-1, los errores no corregibles hacen que el sistema se caiga”.
Para que un atacante obtenga un bit flip explotable, tendría que provocar decenas de caídas de la máquina. Decenas de caídas de una máquina no son algo que pueda pasar desapercibido.
Está bien señalar que la respuesta de JEDEC a Rowhammer es pésima, pero no hay que subestimar ECC como solución de corto plazo.
Es una plataforma Zen2 TR, y al ver esa frase se me cayó el alma al piso por un momento. Es una expresión bastante engañosa.
Me pregunto si problemas de seguridad de hardware como Rowhammer, Spectre y Meltdown son un riesgo real para la gente común.
Entendía que Spectre y Meltdown eran problemáticos para ataques como escapes de VM, algo que debería preocuparle a un ingeniero de AWS, pero que no parecía aplicarle a un usuario individual.
Y como ya quedaste desconectado de la sociedad moderna, puedes irte a una cabaña en el bosque y vivir de la autosuficiencia.
Personalmente me gusta NoScript. En Chrome no sé bien qué elegir.
Fuera de eso… uno no suele ejecutar programas arbitrarios de internet tan seguido, ¿no?
Con este tipo de bugs apenas hemos arañado la superficie. El hardware moderno es tan complejo que cuesta creer que podamos encontrarlos todos.
Por eso todo el mundo puede verse afectado.
Entendía los ataques de bit flip en DDR apenas de forma muy vaga, pero al ver el paper original de Hammertime, en realidad es fácil de leer
Todavía no lo leí completo, pero lo explica de una forma muy fácil de entender. Había oído incontables veces el término bit flip, pero nunca lo había entendido bien; con esto me cayó la ficha
https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
Se siente como haber tomado una clase introductoria de electricidad y electrónica. No tenía idea de que esto estuviera relacionado con un defecto real de fabricación de hardware
El nombre Rowhammer recién ahí también se entiende. Tal vez yo estaba muy atrasado y esto sea algo que todos ya sabían
“Debido a la densidad extrema de los arreglos de DRAM modernos, pequeños defectos de fabricación pueden crear un acoplamiento eléctrico débil entre celdas adyacentes. Combinado con la diminuta capacitancia de estas celdas, cada vez que se lee una fila de DRAM en un banco, las celdas de memoria de las filas adyacentes pierden una pequeña cantidad de carga. Si esto ocurre con suficiente frecuencia entre dos ciclos de refresh, las celdas afectadas pueden perder suficiente carga como para que se invierta el valor del bit almacenado; a esto se le llama ‘disturbance error’ o, más recientemente, Rowhammer”
Es porque los fabricantes de DRAM llevaron los límites al extremo. Es búsqueda de ganancias
No es distinto de Ford al concluir que el costo de los acuerdos en demandas por lesiones y muertes del Pinto era menor que el costo de modificar el diseño del vehículo
Me pregunto si Secure Memory Encryption ayuda en esto
https://www.amd.com/en/developer/sev.html
Un solo bit flip puede convertirse en un error fatal
Sé muy poco de seguridad de hardware, y me pregunto si esto es una de las muchas vulnerabilidades inevitables que surgen de las optimizaciones de CPU y que en la práctica tienen poca viabilidad
Ocurre a un nivel mucho más bajo que los casos límite de funciones que filtran información por canales laterales
Los datos se almacenan como pequeñas cargas en una rejilla, y si se cambian muchas veces puntos cercanos de la rejilla, se puede hacer que parte de la carga se fugue hacia la carga objetivo
Cuanto más pequeñas y más cercanas entre sí sean las cargas, más fácil es un ataque Rowhammer. Al mismo tiempo, cuanto más pequeñas y cercanas sean las cargas, más rápida, barata, densa y eficiente se vuelve la RAM
Hay mitigaciones, pero ya se llevó todo hasta el límite
Me pregunto si esto funciona aun con cifrado total de memoria, poisoning y XOR de direcciones activados
Así que usar cifrado de memoria lo hace más seguro
Si “ZenHammer no logró provocar flips en 9 de 10 dispositivos… se necesita más investigación para encontrar patrones más efectivos en dispositivos DDR5”, parece que a DDR5 todavía le queda algo de tiempo
Me pregunto si alguien sabe si esto también afecta a LPDDR5x
Por eso, si es DDR5, LPDDR5(x), GDDR6(x) o HBM3(e) no es la pregunta clave
Lo importante son los detalles de implementación que quedan a criterio del fabricante, como ECC on-die
Se mencionan Zen 2 y 3, pero me pregunto si hay información sobre Zen 1
¿Simplemente aplica igual?