Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Nuevo ataque de inyección de interrupciones logra vulnerar las defensas de Spectre v2 en CPUs de Intel y AMD


Investigadores del MIT descubrieron una vulnerabilidad llamada TONTOU que permite a programas sin privilegios saltar las defensas contra Spectre v2 en procesadores AMD y Intel mediante la inyección de interrupciones. El ataque permite filtrar memoria confidencial del kernel, como contraseñas del sistema, aprovechando una brecha temporal en la limpieza del predictor de saltos. Mientras AMD ha emitido un aviso y planea parches, Intel no considera necesaria una mitigación oficial.





Un programa de Linux sin privilegios puede programar una interrupción de hardware para que caiga en el intervalo entre que un procesador sanea su predictor de saltos y el núcleo lo utiliza, volviendo a envenenar el predictor después de que la defensa se haya ejecutado.

Los investigadores del MIT CSAIL, Daniël Trujillo y Mengjia Yan, han denominado la técnica INTERRUPT INJECTION. En una máquina AMD Zen 2 ejecutando Linux 6.14 con todas las mitigaciones predeterminadas de Spectre v2 activadas, su exploit filtró memoria arbitraria del núcleo a 5,47 bytes por segundo con una precisión del 91,97%, lo suficiente para localizar y leer /etc/shadow, que almacena los hashes de contraseñas del sistema, en cinco de diez intentos.

No requiere privilegios, solo la ejecución de código local, por lo que el riesgo reside en sistemas compartidos que utilicen un procesador afectado.

La pareja lo reveló aquí a AMD e Intel el 5 de febrero. AMD les informó que planea un parche para el núcleo; el MIT afirma que ya se ha enviado y llega en una actualización normal del sistema operativo.

AMD publicó un boletín el 6 de agosto, AMD-SB-7061, titulado "Safe RET Interrupt Vulnerability", señalando que los procesadores desde Zen 1 hasta Zen 4 están afectados. Su resumen indica que un atacante que ejecute código en un sistema afectado "podría inyectar una interrupción en un momento preciso para interrumpir Safe RET", lo que "podría debilitar potencialmente esa protección y resultar en la divulgación de información". AMD añade que el problema "parece estar asociado con la implementación de la mitigación Safe RET en Linux".

El boletín reconoce a Trujillo y dice que el comportamiento se demostró en Zen 1 y Zen 2, sugiriendo que Zen 3 y Zen 4 también podrían estarlo, aunque no se demostró. El documento informa que AMD realizó pruebas solo en Zen 2 y Zen 4. La sección titulada "Productos Afectados y Mitigación" enumera los procesadores y nada más: ni versión del parche, ni commit del núcleo, ni CVE.

Según el documento aquí, Intel no considera necesaria una mitigación.

El boletín no cierra la brecha para los defensores. Sin un número de versión, commit o CVE para verificar, un administrador sigue sin tener una forma sencilla de saber si una máquina ya tiene el parche que el MIT dice que se ha enviado, o si la corrección aún está en camino.


 

El núcleo informa el estado de SRSO en /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow, y la documentación que define los valores de ese archivo aquí no hacía mención de las interrupciones cuando The Hacker News lo comprobó el 6 de agosto.

Se ha contactado con AMD, Intel y Arm para obtener comentarios y actualizará esta historia con cualquier respuesta.

Cada una de estas defensas sanea o aísla el estado del predictor de saltos para que el entrenamiento previo de un atacante no pueda dirigir una rama del núcleo. Intel lo hace al entrar en el núcleo, con eIBRS y, dependiendo del procesador, mediante un bucle de limpieza del búfer de historial de saltos o el control BHI_DIS_S. AMD lo hace inmediatamente antes de cada retorno del núcleo, con saferet.

Todas ellas asumen que no se ejecuta nada hostil entremedio. Trujillo y Yan llaman a esta clase TONTOU, por Time-of-Neutralization to Time-of-Use (tiempo de neutralización al tiempo de uso), siguiendo las carreras TOCTOU comunes en software. Las interrupciones rompen esa suposición, porque se disparan casi en cualquier lugar y Linux permite que cualquier usuario las programe con granularidad de nanosegundos.

Si la gestión de interrupciones puede ejecutarse entre la neutralización y el uso, la ruta de retorno de la interrupción pasa a ser parte de la defensa Spectre v2, incluso cuando la mitigación fue diseñada para la entrada o salida del núcleo.

En Zen 2, esa ventana es de dos instrucciones, seis bytes. Los investigadores aumentaron sus probabilidades expulsando esos bytes de la caché L1 y L2 utilizando un hiperhilo hermano para ralentizarlos, y eligiendo la llamada al sistema write, que les permitió controlar dos registros.

Las interrupciones cayeron dentro de la ventana entre el 5% y el 12% de las veces, y alrededor del 2% con esos registros bajo el control del atacante. Una vez dentro, el propio manejador se convirtió en el gadget de entrenamiento, armado con Inception aquí (CVE-2023-20569) para llenar el búfer de la pila de retorno con un objetivo elegido por el atacante. Inception es el fallo de AMD de 2023 que saferet existe para detener.

Las predicciones erróneas aparecieron en el código del núcleo en tres de las cuatro máquinas probadas, con tasas de éxito del 0,75% en Zen 2, 0,22% en Intel Arrow Lake y 0,037% en Cascade Lake Refresh. Zen 4 no produjo ninguna en esa prueba, y no se demostró ninguna filtración de extremo a extremo en Intel, donde el atacante también necesitaría un gadget de divulgación utilizable ya presente en el núcleo.

Los investigadores no consideran eso como una barrera. Las predicciones erróneas son "una condición necesaria pero no suficiente para un ataque Spectre", dijeron a The Hacker News, y debido a que trabajos anteriores ya han demostrado que existen gadgets de divulgación en los núcleos, "creemos que un ataque de extremo a extremo es posible también en Intel" combinando su primitiva de Inyección de Interrupciones con dicho trabajo.

Intel pagó un bono discrecional de recompensa por errores pero, según el documento, "no considera que se requiera mitigación", afirmando que la explotabilidad "depende de muchos factores" y que la técnica está cubierta por la guía existente aquí. The Hacker News revisó esa guía, INTEL-SA-00598, en su versión actual actualizada por última vez en mayo de 2025, y no encontró mención alguna a las interrupciones.

Su propuesta de corrección es una segunda neutralización al salir de una interrupción: llenar el búfer de la pila de retorno antes de iret, o emitir IBHF allí en las piezas más nuevas de Intel. Bloquear las interrupciones durante la duración de la ventana conllevaría un coste de rendimiento que el documento no cuantifica.

La pareja presentó el trabajo en Black Hat USA aquí , y el documento se presentará en USENIX Security aquí en Baltimore la próxima semana. A fecha de 6 de agosto, el repositorio de artefactos mencionado en él aún no era público.

Fuente:
THN

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.