Una nueva investigación del MIT CSAIL vuelve a señalar uno de los puntos más delicados de la seguridad moderna de CPU: la ejecución especulativa. El trabajo, denominado TONTOU, demuestra que determinadas mitigaciones contra Spectre v2 pueden quedar expuestas si una interrupción ocurre exactamente en la pequeña ventana temporal que existe entre la limpieza del predictor de saltos y su uso posterior. El ataque requiere ejecución local de código, pero su impacto potencial resulta especialmente relevante en servidores compartidos y entornos cloud.
Las claves de TONTOU en 30 segundos
- TONTOU explota una ventana temporal entre la neutralización del predictor y su siguiente uso.
- La técnica de Interrupt Injection permite provocar una interrupción con precisión suficiente para contaminar de nuevo el estado especulativo.
- Los investigadores probaron procesadores Intel Cascade Lake Refresh y Arrow Lake, además de AMD Zen 2 y Zen 4.
- En AMD Zen 2 lograron una explotación completa capaz de leer memoria del kernel.
- AMD ha publicado el aviso AMD-SB-7061 y sitúa el problema observado en la implementación Linux de Safe RET.
El interés de TONTOU no está únicamente en demostrar otra predicción errónea. La investigación cuestiona una hipótesis habitual en muchas defensas frente a Spectre: que limpiar el estado del predictor inmediatamente antes de utilizarlo es suficiente para garantizar que ese estado siga siendo seguro.
Los investigadores Daniël Trujillo y Mengjia Yan han demostrado que no siempre es así.
Una ventana de dos instrucciones puede ser suficiente
El nombre TONTOU procede de Time-of-Neutralization to Time-of-Use. El concepto recuerda a los clásicos fallos TOCTOU (Time of Check to Time of Use), pero trasladados a la microarquitectura del procesador.
Una defensa puede limpiar correctamente el predictor:
estado manipulado
↓
limpieza
↓
estado seguro
↓
usoEl problema aparece si entre los dos últimos pasos ocurre una interrupción:
estado manipulado
↓
limpieza
↓
INTERRUPCIÓN
↓
nuevo estado del predictor
↓
usoEsa interrupción ejecuta código del kernel y puede modificar de nuevo estructuras microarquitectónicas que la mitigación acababa de neutralizar.
TONTOU utiliza una técnica denominada Interrupt Injection para provocar este comportamiento de forma controlada.
Los temporizadores disponibles para procesos sin privilegios permiten programar interrupciones. Ajustando repetidamente el momento en el que se producen, los investigadores consiguieron hacerlas coincidir con ventanas extremadamente pequeñas.
En el caso de Safe RET de AMD, la ventana vulnerable puede limitarse a solo dos instrucciones, ejecutadas normalmente en decenas de nanosegundos.
El equipo consiguió alcanzarla.
Cuatro procesadores de AMD e Intel puestos a prueba
Los investigadores probaron TONTOU sobre cuatro sistemas representativos de distintas generaciones:
| Fabricante | Procesador | Microarquitectura |
|---|---|---|
| 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 las plataformas Intel lograron provocar comportamientos de predicción incorrecta pese a mecanismos utilizados contra Branch History Injection, incluyendo secuencias software de limpieza y BHI_DIS_S.
El resultado no significa que cualquier procesador Intel protegido con esas técnicas pueda explotarse de la misma forma.
Una de las conclusiones más relevantes de la investigación es precisamente que mitigaciones nominalmente iguales pueden comportarse de manera diferente entre microarquitecturas.
Esto complica la gestión del riesgo. Para los equipos de seguridad no basta con comprobar que existe una mitigación con un nombre determinado: es necesario conocer cómo se implementa y qué comportamiento ofrece en cada generación de CPU.
El exploit sobre Zen 2 consiguió leer memoria del kernel
La demostración más completa se realizó sobre AMD Zen 2.
Safe RET es una mitigación utilizada por Linux frente a Speculative Return Stack Overflow (SRSO). Su objetivo es evitar que las predicciones especulativas relacionadas con instrucciones de retorno puedan ser manipuladas para acceder a información sensible.
TONTOU consiguió interrumpir el sistema después de la limpieza realizada por Safe RET pero antes del retorno protegido.
Los investigadores llevaron después el ataque más allá del laboratorio.
Primero lograron romper KASLR (Kernel Address Space Layout Randomization) en las diez pruebas realizadas, necesitando alrededor de nueve minutos de media.
Después desarrollaron un canal capaz de leer memoria arbitraria del kernel a aproximadamente 5,47 bytes por segundo, con una precisión del 91,97 %.
La velocidad puede parecer reducida, pero en ataques de canal lateral no siempre hace falta una transferencia elevada. Extraer unos pocos bytes concretos puede ser suficiente para obtener claves, direcciones o credenciales.
Como demostración, intentaron localizar /etc/shadow, el archivo utilizado por Linux para almacenar información asociada a los hashes de contraseñas.
Lo consiguieron en cinco de diez intentos, con un tiempo medio cercano a los 18 minutos.
Este resultado es el que convierte TONTOU en una investigación especialmente relevante desde el punto de vista defensivo.
El atacante necesita ejecutar código local
TONTOU no es una vulnerabilidad que pueda explotarse simplemente enviando tráfico a un equipo remoto.
El escenario descrito requiere que el atacante pueda ejecutar código local sin privilegios en el sistema objetivo.
Para un portátil o una estación de trabajo que únicamente ejecuta software de confianza, esto reduce mucho la exposición.
Sin embargo, el requisito adquiere otra dimensión en:
- infraestructuras multiusuario;
- plataformas de hosting;
- runners compartidos de CI/CD;
- servidores de desarrollo;
- clouds públicos;
- entornos donde diferentes clientes comparten CPU física.
Estos sistemas están diseñados precisamente para ejecutar código de usuarios distintos mientras mantienen una separación estricta entre ellos.
Los ataques de ejecución especulativa preocupan porque intentan aprovechar estados internos del procesador que existen por debajo de esas separaciones lógicas.
TONTOU no demuestra por sí mismo un escape universal entre máquinas virtuales ni un ataque automático contra cualquier proveedor cloud. La explotación concreta depende del procesador, kernel, mitigaciones y configuración.
Pero el modelo de amenaza merece especial atención en infraestructura compartida.
AMD publica AMD-SB-7061 y apunta a Safe RET en Linux
AMD ha reconocido públicamente el problema mediante el boletín AMD-SB-7061, Safe RET Interrupt Vulnerability, publicado el 6 de agosto de 2026.
La compañía explica que la investigación demuestra cómo una interrupción cuidadosamente sincronizada puede debilitar Safe RET.
AMD indica que el comportamiento fue demostrado directamente sobre Zen 1 y Zen 2. Los investigadores consideran que Zen 3 y Zen 4 podrían estar afectados por el mismo principio, aunque esa explotación concreta no se demostró en ambas generaciones.
El fabricante también hace una precisión importante: su evaluación actual vincula la vulnerabilidad observada con la implementación Linux de la mitigación Safe RET.
Esto significa que la respuesta se está gestionando fundamentalmente mediante cambios en software, en lugar de requerir una sustitución física de los procesadores.
Los administradores deberían revisar las actualizaciones proporcionadas por sus distribuciones Linux y mantener al día los kernels de los sistemas afectados.
Intel considera que sus recomendaciones actuales cubren el riesgo
Intel también fue notificada durante la divulgación coordinada.
Los investigadores observaron que algunas defensas podían ser atravesadas bajo determinadas condiciones, aunque el comportamiento varía entre generaciones.
Intel dispone desde hace años de varias medidas para controlar ataques de Branch History Injection y Spectre v2, entre ellas BHI_DIS_S, secuencias de limpieza del historial, IBPB y, en procesadores más recientes, instrucciones específicas como IBHF (Indirect Branch History Fence).
La existencia de estos mecanismos explica por qué no puede hablarse de un único parche TONTOU aplicable de forma idéntica a todo el catálogo.
La protección depende del modelo concreto de CPU y de las capacidades que utilice el sistema operativo.
Para equipos SOC y responsables de vulnerabilidades, esto implica revisar avisos de fabricantes y distribuciones en lugar de limitarse a buscar una CVE universal y aplicar la misma configuración en toda la flota.
¿Habrá otra vez penalizaciones de rendimiento?
TONTOU también recupera uno de los debates que acompañan a Spectre desde 2018.
Algunas mitigaciones iniciales contra ataques especulativos introdujeron pérdidas de rendimiento perceptibles en determinadas cargas, especialmente aquellas con muchas transiciones entre usuario y kernel, virtualización o entrada/salida intensiva.
Una posible defensa frente a TONTOU consiste en realizar otra limpieza al finalizar la interrupción.
En AMD, los investigadores consideran que esta aproximación puede mitigar el problema.
Otra opción más fuerte sería utilizar barreras como IBPB (Indirect Branch Prediction Barrier) con mayor frecuencia.
Linux ya contempla diferentes modos de mitigación SRSO. En determinadas configuraciones pueden utilizarse opciones como:
spec_rstack_overflow=ibpbo:
spec_rstack_overflow=ibpb-vmexitEl segundo escenario resulta especialmente relevante para virtualización porque aplica la barrera durante transiciones VMEXIT.
Pero utilizar defensas más fuertes y frecuentes también puede aumentar el coste computacional.
La alternativa extrema, bloquear interrupciones durante las ventanas sensibles, probablemente tendría un impacto demasiado elevado para ser práctica en muchos sistemas.
Por ahora no existe evidencia suficiente para afirmar que TONTOU vaya a provocar una pérdida generalizada de rendimiento comparable a algunos de los primeros parches contra Spectre.
La respuesta final dependerá de cada arquitectura y de cómo fabricantes y sistemas operativos implementen las mitigaciones.
TONTOU demuestra que Spectre sigue siendo un problema abierto
La principal conclusión de seguridad va más allá de Safe RET o BHI.
Desde 2018 se han añadido múltiples capas para impedir que los atacantes controlen predictores, historiales de saltos y otros estados relacionados con ejecución especulativa.
TONTOU demuestra que proteger el momento de limpieza no siempre es suficiente.
También hay que analizar todo lo que puede ocurrir entre esa limpieza y el uso posterior del recurso.
En procesadores modernos hay interrupciones, excepciones, cambios de contexto y numerosos eventos asíncronos que pueden modificar el comportamiento interno de la CPU.
La investigación expone precisamente esa zona.
Spectre no fue una vulnerabilidad única que pudiera solucionarse con un parche definitivo. Es una familia de técnicas que aprovecha una tensión difícil de eliminar: los procesadores necesitan predecir y ejecutar por adelantado para ofrecer su rendimiento actual, pero esos mecanismos generan estados internos que pueden filtrar información.
TONTOU demuestra que, ocho años después, todavía quedan formas nuevas de atacar esa frontera.
Preguntas frecuentes
¿Qué es TONTOU?
TONTOU es una nueva clase de ataques contra mitigaciones de ejecución especulativa desarrollada por investigadores del MIT CSAIL. Explota el intervalo entre la limpieza de un predictor y su siguiente utilización.
¿Se puede explotar TONTOU remotamente?
El ataque descrito requiere ejecución local de código sin privilegios. No se trata de una explotación remota directa mediante tráfico de red.
¿Qué impacto demostraron los investigadores?
Sobre AMD Zen 2 lograron romper KASLR y leer memoria arbitraria del kernel a unos 5,47 bytes por segundo. También localizaron /etc/shadow en cinco de diez intentos.
¿Qué deben hacer las empresas?
Las organizaciones deberían aplicar las actualizaciones de kernel y microcódigo recomendadas por fabricantes y distribuciones, revisar específicamente servidores compartidos y virtualizados y comprobar qué mitigaciones Spectre/SRSO están activas en cada generación de procesador.
Fuentes:
- Revista Cloud: TONTOU vuelve a poner a Spectre en el foco: afecta a mitigaciones de Intel y AMD
- 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.
