Ocho años después de la aparición de Spectre, investigadores del MIT CSAIL han demostrado que determinadas defensas contra ataques de ejecución especulativa pueden volver a quedar expuestas si una interrupción se produce exactamente en el pequeño intervalo existente entre la limpieza del predictor de saltos y su posterior utilización. El trabajo, denominado TONTOU, afecta a escenarios estudiados sobre procesadores Intel y AMD y ha llevado a AMD a publicar una mitigación para Linux relacionada con Safe RET.
Las claves de TONTOU en 20 segundos
- TONTOU explota ventanas temporales que aparecen entre la neutralización del predictor y su siguiente utilización.
- Los investigadores utilizan una técnica denominada Interrupt Injection para introducir actividad en ese intervalo.
- Las pruebas incluyen procesadores Intel Cascade Lake Refresh y Arrow Lake, además de AMD Zen 2 y Zen 4.
- En AMD Zen 2 construyeron un exploit capaz de extraer información del kernel.
- AMD atribuye el problema observado a la implementación Linux de Safe RET y recomienda actualizar el sistema.
La investigación no descubre otra variante clásica basada simplemente en entrenar el predictor desde un proceso atacante. Su aportación es mostrar que incluso una mitigación que aparentemente limpia correctamente el estado especulativo puede fallar si existe un intervalo entre el momento en que ese estado queda neutralizado y aquel en que vuelve a utilizarse.
El 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 a conocer el resultado de cada salto, intentan predecir qué camino se seguirá y empiezan a ejecutar instrucciones por adelantado.
Cuando la predicción resulta incorrecta, esas operaciones se descartan arquitectónicamente. El problema que Spectre puso de manifiesto en 2018 es que determinados efectos microarquitectónicos pueden permanecer y utilizarse como canal lateral para inferir información.
Las mitigaciones creadas posteriormente intentan impedir que un atacante controle el estado utilizado por esos predictores.
TONTOU señala una debilidad diferente.
Después de limpiar o aislar el predictor existe inevitablemente algún código antes de que la CPU utilice de nuevo esa información. Si una interrupción se ejecuta justo ahí, el propio manejador puede modificar de nuevo el estado microarquitectónico.
Los investigadores denominan Interrupt Injection a la técnica empleada para conseguirlo.
Un programa local puede utilizar temporizadores para provocar interrupciones y ajustar progresivamente su momento de ejecución hasta hacerlas coincidir con esas ventanas.
La precisión necesaria puede ser extrema. En el caso de la mitigación Safe RET de AMD, los investigadores describen una ventana de apenas dos instrucciones.
Aun así lograron alcanzarla.
Intel también mostró predicciones erróneas pese a las defensas existentes
El trabajo 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 consiguieron provocar predicciones erróneas en situaciones protegidas mediante mecanismos relacionados con la limpieza del historial de saltos y BHI_DIS_S.
Este último es un control diseñado para limitar la influencia del historial de saltos sobre predicciones realizadas en niveles privilegiados. Intel documenta BHI_DIS_S dentro de sus mitigaciones para Branch History Injection (BHI) y dispone además de la instrucción IBHF, Indirect Branch History Fence, destinada a impedir que el historial previo influya en determinadas predicciones posteriores.
El comportamiento observado por TONTOU no significa automáticamente que todas estas protecciones sean inútiles en cualquier procesador Intel.
De hecho, una de las conclusiones del estudio es precisamente que una misma defensa puede comportarse de manera diferente entre microarquitecturas.
Intel mantiene recomendaciones específicas según la generación y las capacidades del procesador, incluyendo BHI_DIS_S, secuencias software de limpieza del Branch History Buffer (BHB), IBPB y otras medidas dependiendo del escenario.
Eso hace que el alcance práctico de TONTOU sobre Intel deba analizarse por plataforma y configuración, no simplemente por marca.
En AMD Zen 2 pasaron de la teoría a leer memoria del kernel
La demostración más preocupante del estudio se realizó sobre AMD Zen 2.
Safe RET es la mitigación software utilizada por Linux frente a Speculative Return Stack Overflow (SRSO) en determinados procesadores AMD. La propia documentación del kernel mantiene safe-ret como una de las opciones de mitigación, junto con alternativas basadas en microcódigo o IBPB.
TONTOU consigue introducir la interrupción entre la limpieza realizada por Safe RET y el retorno especulativo que esa limpieza pretende proteger.
Los investigadores construyeron después una cadena de explotación completa sobre Linux.
Según los resultados proporcionados en el estudio, consiguieron primero romper KASLR (Kernel Address Space Layout Randomization) en las diez pruebas realizadas, con unos nueve minutos de media.
KASLR aleatoriza la posición del kernel en memoria para dificultar que un atacante conozca las direcciones necesarias para construir una explotación.
Una vez superada 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 %.
No es una velocidad elevada, pero un canal lateral no necesita necesariamente transferir megabytes por segundo para resultar útil.
Los investigadores utilizaron esa capacidad para intentar localizar /etc/shadow, el archivo que en sistemas Linux almacena información asociada a los hashes de las contraseñas.
Lo consiguieron en cinco de diez ejecuciones, con aproximadamente 18 minutos de media.
Esto convierte TONTOU en algo más que una demostración de que una predicción incorrecta sigue siendo posible.
No es un ataque remoto, pero importa especialmente en servidores compartidos
Para explotar el escenario descrito es necesario ejecutar código local sin privilegios en el sistema afectado.
Por tanto, TONTOU no permite comprometer directamente desde Internet un ordenador vulnerable simplemente enviándole tráfico.
Esa condición reduce considerablemente el riesgo para un PC convencional donde únicamente se ejecuta software de confianza.
El escenario cambia en infraestructuras multiusuario, servidores de ejecución compartida, plataformas de desarrollo y determinados entornos cloud.
En estos casos resulta normal que código perteneciente a distintos usuarios termine utilizando el mismo hardware físico. Los ataques microarquitectónicos son especialmente relevantes precisamente porque intentan atravesar separaciones que, desde el punto de vista lógico del sistema operativo o del hipervisor, deberían mantenerse.
USENIX señala en su propio programa de 2026 que los ataques microarquitectónicos continúan siendo una preocupación específica en clouds públicos debido al riesgo de filtración entre tenants que comparten infraestructura física.
Eso no implica que TONTOU permita automáticamente escapar de cualquier máquina virtual o comprometer cualquier proveedor cloud. La explotación depende de procesador, kernel, mitigaciones disponibles y capacidad del atacante para ejecutar código en las condiciones necesarias.
AMD confirma Zen 1 a Zen 4 dentro del ámbito de Safe RET
AMD ha publicado su respuesta como AMD-SB-7061, Safe RET Interrupt Vulnerability.
El fabricante explica que un investigador externo informó de que una interrupción cuidadosamente sincronizada podía debilitar Safe RET, la mitigación predeterminada de Linux frente a SRSO.
AMD señala que el comportamiento fue demostrado sobre Zen 1 y Zen 2 y que los investigadores consideran que Zen 3 y Zen 4 podrían verse afectados por el mismo principio, aunque esa explotación concreta no fue demostrada sobre esas generaciones.
La valoración de AMD es también relevante porque sitúa el problema principalmente en la implementación Linux de Safe RET, no como un nuevo fallo de hardware para el que necesariamente haya que sustituir procesadores.
La compañía y los mantenedores del kernel han trabajado en una mitigación software, por lo que la recomendación práctica para administradores es mucho menos espectacular que el ataque: mantener actualizado el kernel Linux y aplicar las actualizaciones distribuidas por la distribución correspondiente.
¿Volverán los parches de Spectre a reducir el rendimiento?
Es probablemente la cuestión más interesante desde el punto de vista de administración de infraestructura.
Los primeros parches contra Spectre y Meltdown mostraron que proteger determinadas transiciones especulativas podía introducir un coste medible, especialmente en workloads con muchas llamadas al sistema, virtualización y operaciones de entrada/salida.
TONTOU vuelve a poner sobre la mesa ese equilibrio.
Una solución aparentemente directa consistiría en limpiar de nuevo el predictor al regresar de cada interrupción.
Los investigadores consideran que ese enfoque puede ser útil en determinados procesadores AMD. Sin embargo, advierten de que el comportamiento no tiene por qué trasladarse directamente a Intel.
Otra posibilidad sería recurrir a mecanismos más fuertes como IBPB (Indirect Branch Prediction Barrier).
Linux ya contempla IBPB como opción para la mitigación SRSO en AMD:
spec_rstack_overflow=ibpb
También existe:
spec_rstack_overflow=ibpb-vmexit
orientada específicamente a aplicar IBPB durante VMEXIT en escenarios cloud.
El problema es que las barreras más fuertes pueden tener un mayor impacto en rendimiento.
Bloquear las interrupciones durante todas las ventanas sensibles sería otra solución conceptual, pero los propios investigadores consideran que podría resultar demasiado costosa.
De momento no hay datos suficientes para afirmar que TONTOU vaya a provocar una pérdida generalizada de rendimiento comparable a la de algunas mitigaciones introducidas después de 2018.
La mitigación final depende de cada fabricante, microarquitectura y sistema operativo.
Spectre sigue siendo una familia de problemas, no una vulnerabilidad cerrada
TONTOU deja además una enseñanza más amplia.
Las mitigaciones contra ejecución especulativa suelen analizarse suponiendo una secuencia bastante limpia:
estado contaminado
↓
mitigación
↓
estado limpio
↓
uso seguro
La investigación demuestra que el sistema real puede parecerse más a esto:
estado contaminado
↓
mitigación
↓
estado limpio
↓
INTERRUPCIÓN
↓
nuevo estado microarquitectónico
↓
uso del predictor
El problema no está necesariamente en que la operación de limpieza falle.
Puede estar en lo que ocurre después de limpiarla pero antes de utilizar el recurso protegido.
Ese tipo de ventanas TOCTOU (Time of Check to Time of Use) son conocidas desde hace décadas en seguridad software. TONTOU aplica un concepto parecido a un nivel microarquitectónico mucho más difícil de observar.
Por eso Spectre continúa generando investigación ocho años después.
Los fabricantes han endurecido considerablemente sus procesadores y los sistemas operativos incorporan múltiples capas de protección, pero la ejecución especulativa sigue siendo una pieza esencial del rendimiento de las CPU modernas. El reto continúa siendo aprovecharla sin permitir que el estado interno utilizado para acelerar el procesador termine convertido en una fuente de información.
Preguntas frecuentes
¿Qué es TONTOU?
TONTOU es una nueva clase de ataque investigada por MIT CSAIL que explota el intervalo entre la neutralización de determinado estado del predictor especulativo y su posterior utilización.
¿Qué es Interrupt Injection?
Es la técnica empleada por los investigadores para provocar una interrupción en un momento muy concreto y modificar de nuevo el estado microarquitectónico después de que una mitigación lo haya limpiado.
¿Qué procesadores se probaron?
El estudio utilizó AMD Ryzen 7 4700G, AMD EPYC 9124, Intel Xeon Gold 5220R e Intel Core Ultra 9 285H. El exploit completo de filtración de memoria se desarrolló sobre AMD Zen 2.
¿Qué deben hacer los administradores de sistemas?
En sistemas AMD afectados por el escenario Safe RET, AMD recomienda aplicar las actualizaciones del sistema operativo que incorporen la mitigación. En servidores y clouds conviene revisar además la configuración de las protecciones Spectre/SRSO proporcionadas por kernel, distribución y 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 técnico y presentación de TONTOU.
- AMD, AMD-SB-7061: Safe RET Interrupt Vulnerability, 06/08/2026.
- Linux Kernel Documentation, mitigaciones de Speculative Return Stack Overflow. (static.lwn.net)
- Intel, documentación de Branch History Injection, BHI_DIS_S e IBHF.
