Ocho años después de la aparición de Spectre, investigadores del MIT CSAIL han demostrado que ciertas defensas contra ataques de ejecución especulativa pueden volver a quedar expuestas si una interrupción se produce exactamente en el pequeño intervalo entre la limpieza del predictor de saltos y su posterior uso. El trabajo, denominado TONTOU, afecta a escenarios evaluados en procesadores Intel y AMD, y ha llevado a AMD a publicar una mitigación para Linux relacionada con Safe RET.
Resumen rápido de TONTOU en 20 segundos
- TONTOU aprovecha ventanas temporales entre la neutralización del predictor y su reutilización.
- Los investigadores emplean una técnica llamada Interrupt Injection para introducir actividad en ese intervalo.
- Las pruebas abarcan procesadores Intel Cascade Lake Refresh y Arrow Lake, además de AMD Zen 2 y Zen 4.
- Con AMD Zen 2 crearon un exploit capaz de extraer información del kernel.
- AMD atribuye el problema a la implementación de Safe RET en Linux y recomienda actualizar el sistema.
La investigación no revela otra variante clásica basada únicamente en entrenar el predictor desde un proceso atacante. Su aportación principal es mostrar que, incluso con una mitigación que aparentemente limpia correctamente el estado especulativo, puede fallar si existe un intervalo entre la neutralización del estado y su posterior utilización.
Este concepto da nombre al trabajo: Time-of-Neutralization to Time-of-Use, TONTOU.
El estudio está firmado por Daniël Trujillo y Mengjia Yan del MIT CSAIL, y forma parte del programa de USENIX Security 2026.
Una interrupción de apenas unos nanosegundos puede volver a contaminar el predictor
Los procesadores modernos utilizan ejecución especulativa para adelantarse al flujo real del programa. En lugar de esperar los resultados de cada salto, intentan predecir qué camino seguirá y comienzan a ejecutar instrucciones de forma anticipada.
Cuando la predicción resulta incorrecta, esas operaciones se descartan arquitectónicamente. Lo que Spectre evidenció en 2018 es que ciertos efectos microarquitectónicos pueden permanecer activos y ser utilizados como canales laterales para filtrar información.
Las mitigaciones posteriores intentan impedir que un atacante controle el estado utilizado por estos predictores.
TONTOU señala una vulnerabilidad distinta.
Tras limpiar o aislar el predictor, inevitablemente queda algún código justo antes de que la CPU vuelva a utilizar esa información. Si una interrupción se produce en ese momento, el manejador puede modificar nuevamente el estado microarquitectónico.
Los investigadores llaman Interrupt Injection a la técnica empleada para lograr esto.
Un programa local puede usar temporizadores para provocar interrupciones y ajustar gradualmente su momento de ejecución hasta hacerlas coincidir con esas ventanas temporales.
La precisión necesaria puede ser extrema. En el caso de Safe RET de AMD, los investigadores describen una ventana de apenas dos instrucciones.
A pesar de ello, lograron alcanzarla.
Intel también mostró predicciones erróneas pese a las defensas existentes
El estudio evaluó cuatro plataformas:
| Fabricante | Procesador | Arquitectura |
|---|---|---|
| AMD | Ryzen 7 4700G | Zen 2 |
| AMD | EPYC 9124 | Zen 4 |
| Intel | Xeon Gold 5220R | Cascade Lake Refresh |
| Intel | Core Ultra 9 285H | Arrow Lake |
En Intel, los investigadores lograron provocar predicciones erróneas en entornos protegidos mediante mecanismos relacionados con la limpieza del historial de saltos y BHI_DIS_S.
Este mismo mecanismo consiste en un control diseñado para limitar la influencia del historial de saltos en predicciones en niveles privilegiados. Intel documenta BHI_DIS_S en sus mitigaciones para Branch History Injection (BHI) y también dispone de la instrucción IBHF, Indirect Branch History Fence, que evita que el historial previo influya en predicciones posteriores.
El comportamiento observado por TONTOU no implica automáticamente que todas estas protecciones sean inútiles en cualquier procesador Intel.
De hecho, una de las conclusiones del estudio es que una misma defensa puede actuar de forma diferente según la microarquitectura.
Intel recomienda medidas específicas según la generación y capacidades del procesador, incluyendo BHI_DIS_S, secuencias de limpieza del Branch History Buffer (BHB) mediante software, IBPB y otras medidas según el escenario.
Por ello, el alcance práctico de TONTOU en Intel debe analizarse por plataforma y configuración, no solo por marca.
En AMD Zen 2 pasaron de la teoría a leer memoria del kernel
La demostración más inquietante del estudio se realizó en AMD Zen 2.
Safe RET es la mitigación por software utilizada en Linux contra Speculative Return Stack Overflow (SRSO) en ciertos procesadores AMD. La documentación del kernel mantiene safe-ret como opción mitigadora, junto con alternativas basadas en microcódigo o IBPB.
TONTOU logra introducir la interrupción entre la limpieza realizada por Safe RET y el retorno especulativo que esa limpieza intenta proteger.
Luego, los investigadores desarrollaron una cadena de explotación completa en Linux.
Según los resultados del estudio, lograron primero vencer la protección de KASLR (Kernel Address Space Layout Randomization) en las diez pruebas, con una media de unos nueve minutos.
KASLR aleatoriza la ubicación del kernel en memoria para dificultar que un atacante conozca las direcciones necesarias para explotar.
Tras superar esa protección, TONTOU permitió extraer memoria arbitraria del kernel a aproximadamente 5,47 bytes por segundo, con una precisión cercana al 91,97 %.
Aunque no es una velocidad elevada, un canal lateral no necesita necesariamente transmitir megabytes por segundo para ser útil.
Los investigadores usaron esa capacidad para buscar /etc/shadow, el archivo en Linux que almacena hashes de contraseñas y otra información confidencial.
Lo lograron en cinco de diez intentos, con una media de unos 18 minutos.
Esto hace que TONTOU sea más que una demostración de que una predicción incorrecta sigue siendo posible.
No es un ataque remoto, pero es especialmente relevante en servidores compartidos
Para explotar este escenario, es necesario ejecutar código local sin privilegios en el sistema afectado.
Por tanto, TONTOU no permite comprometer directamente una máquina vulnerable desde Internet mediante envío de tráfico.
Este hecho reduce mucho el riesgo en un PC típico donde solo se ejecuta software confiable.
El escenario cambia en entornos multiusuario, servidores compartidos, plataformas de desarrollo y ciertos servicios cloud.
En estos casos, es habitual que código de diferentes usuarios comparta hardware físico. Los ataques microarquitectónicos son especialmente relevantes porque buscan atravesar barreras que, desde un punto de vista de sistema operativo o hipervisor, deberían mantenerse intactas.
USENIX subraya en su programa de 2026 que estos ataques siguen siendo una preocupación en nubes públicas, por el riesgo de filtraciones entre inquilinos que comparten infraestructura física.
Esto no significa que TONTOU permita escapar automáticamente de máquinas virtuales o comprometer proveedores de nube. La explotación depende del procesador, el sistema operativo, las mitigaciones activas y la capacidad del atacante para ejecutar código en las condiciones necesarias.
AMD confirma que Zen 1 a Zen 4 están afectados por Safe RET
AMD ha publicado su respuesta bajo el documento AMD-SB-7061, Vulnerabilidad de Interrupción en Safe RET.
La empresa explica que un investigador externo informó que una interrupción cuidadosamente sincronizada podía debilitar Safe RET, la mitigación predeterminada en Linux contra Speculative Return Stack Overflow (SRSO).
AMD indica que el comportamiento fue demostrado en Zen 1 y Zen 2 y que los investigadores consideran que Zen 3 y Zen 4 podrían estar afectados, aunque no se demostró concretamente en esas generaciones.
La evaluación de AMD es importante porque enfoca el problema principalmente en la implementación de Safe RET en Linux, no como un fallo de hardware que requiera reemplazo de procesadores.
La compañía y los mantenedores del kernel han trabajado en una mitigación por software, por lo que la recomendación práctica es simplemente mantener actualizado el kernel Linux y aplicar las actualizaciones de la distribución.
¿Volverán los parches de Spectre a afectar el rendimiento?
Probablemente sea la duda más relevante para administradores e ingenieros de infraestructura.
Los primeros parches contra Spectre y Meltdown mostraron que proteger algunas transiciones especulativas podía introducir un coste medible, especialmente en cargas de trabajo con muchas llamadas al sistema, virtualización y operaciones de entrada/salida.
TONTOU vuelve a plantear esa cuestión.
Una solución simple sería limpiar nuevamente el predictor tras cada interrupción.
Los investigadores consideran que este enfoque puede ser útil en ciertos procesadores AMD pero advierten que la misma estrategia no necesariamente funciona en Intel.
Otra alternativa sería usar mecanismos más fuertes como IBPB (Indirect Branch Prediction Barrier).
Linux ya contempla IBPB para mitigate SRSO en AMD, con opciones como:
spec_rstack_overflow=ibpb
Y también:
spec_rstack_overflow=ibpb-vmexit
esta última específica para activar IBPB durante VMEXIT en entornos cloud.
El problema es que las barreras más fuertes pueden impactar en el rendimiento, y bloquear todas las interrupciones en ventanas sensibles sería muy costoso.
De momento, aún no hay datos concluyentes que indiquen que TONTOU vaya a causar una reducción generalizada del rendimiento comparable a algunas mitigaciones posteriores a 2018.
La decisión final dependerá de cada fabricante, microarquitectura y sistema operativo.
Spectre sigue siendo una familia de problemas, no una vulnerabilidad cerrada
TONTOU aporta también una enseñanza más profunda.
Las mitigaciones contra ejecución especulativa suelen analizarse suponiendo una secuencia bastante controlada:
estado contaminado
↓
mitigación
↓
estado limpio
↓
uso seguro
La realidad puede parecerse más a esto:
estado contaminado
↓
mitigación
↓
estado limpio
↓
INTERRUPCIÓN
↓
nuevo estado microarquitectónico
↓
uso del predictor
El problema no es que falle la operación de limpieza en sí.
Puede estar en lo que sucede después de la limpieza, pero antes de usar el recurso protegido.
Este tipo de ventanas TOCTOU (Time of Check to Time of Use) son conocidas desde hace décadas en seguridad de software. TONTOU aplica un concepto similar a nivel microarquitectónico, mucho más difícil de detectar.
Por eso, Spectre sigue siendo objeto de investigación ocho años después.
Los fabricantes han endurecido sus procesadores, y los sistemas operativos incorporan múltiples capas de protección, pero la ejecución especulativa sigue siendo clave para el rendimiento de las CPUs modernas. El reto es aprovecharla sin que el estado interno utilizado para acelerar la CPU acabe siendo una fuente de filtración de información.
Preguntas frecuentes
¿Qué es TONTOU?
TONTOU es una nueva categoría de ataque investigada por MIT CSAIL que explota el intervalo entre la neutralización de cierto estado del predictor especulativo y su posterior uso.
¿Qué es Interrupt Injection?
Es la técnica usada por los investigadores para provocar una interrupción en un momento muy preciso y modificar de nuevo el estado microarquitectónico tras una mitigación.
¿Qué procesadores fueron analizados?
Se estudiaron AMD Ryzen 7 4700G, AMD EPYC 9124, Intel Xeon Gold 5220R e Intel Core Ultra 9 285H. La exploitación completa de memoria se desarrolló en AMD Zen 2.
¿Qué deben hacer los administradores de sistemas?
En sistemas AMD afectados por Safe RET, AMD recomienda aplicar las actualizaciones del sistema operativo que incorporen la mitigación. En servidores y entornos en la nube, también conviene revisar las protecciones Spectre/SRSO configuradas mediante kernel y distribución, así como las recomendaciones del fabricante.
Fuentes:
- MIT CSAIL / Daniël Trujillo y Mengjia Yan, investigación TONTOU: On the Exploitability of Time-of-Neutralization to Time-of-Use Windows.
- USENIX Security 2026, programa y presentación de TONTOU.
- AMD, AMD-SB-7061: Safe RET Interrupt Vulnerability, 06/08/2026.
- Documentación del Kernel Linux, mitigaciones para Speculative Return Stack Overflow (static.lwn.net)
- Intel, documentación de Branch History Injection, BHI_DIS_S y IBHF.