TONTOU demuestra que las defensas contra Spectre v2 dejan una ventana crítica

Cómo funciona TONTOU

Las mitigaciones como eIBRS y Safe RET actúan en las fronteras de privilegio, por ejemplo, cuando el procesador pasa del espacio de usuario al espacio del kernel. En ese proceso, neutralizan o aíslan la información que utiliza el predictor de saltos .

El supuesto central era que un atacante no podría modificar de nuevo ese estado entre la limpieza y el momento en que el kernel consultara el predictor. TONTOU demuestra que ese supuesto no siempre se cumple.

En el caso de Safe RET en AMD, la ventana vulnerable puede tener solo dos instrucciones . Un programa sin privilegios puede programar una interrupción de hardware para que ocurra exactamente en ese intervalo. La técnica, denominada INTERRUPT INJECTION, vuelve a «envenenar» el predictor después de que la defensa ya se ha ejecutado, pero antes de que el kernel utilice el estado predictor .

De ese modo, la ejecución especulativa vuelve a quedar bajo la influencia del atacante y puede utilizarse como canal lateral para filtrar datos. El ataque requiere que el código no privilegiado pueda ejecutarse en la máquina objetivo, pero no exige permisos elevados .

El impacto demostrado: hashes de contraseñas de Linux

El equipo construyó un exploit de extremo a extremo y lo probó en varias generaciones de procesadores:

• Intel Cascade Lake Refresh.
• Intel Arrow Lake.
• AMD Zen 2.
• AMD Zen 4 .

En un sistema AMD Zen 2 con Linux 6.14.0-37-generic, 16 GB de memoria y las protecciones de Spectre v2 activadas por defecto, el ataque consiguió filtrar memoria arbitraria del kernel a una velocidad de 5,47 bytes por segundo . La información recuperada alcanzó una precisión del 91,97 % .

La demostración más llamativa fue la localización y extracción de /etc/shadow, el archivo de Linux que almacena los hashes de las contraseñas. El equipo lo consiguió en cinco de diez intentos, con una duración aproximada de 18 minutos por intento .

En Intel, los investigadores demostraron un bypass parcial de eIBRS en Cascade Lake Refresh y Arrow Lake, aunque la superficie de ataque no es idéntica a la de Safe RET en AMD . Con el mismo método no confirmaron una redirección incorrecta de saltos en AMD Zen 4 .

Qué respondieron AMD e Intel

La divulgación coordinada comenzó el 5 de febrero de 2026, cuando los investigadores informaron de sus resultados a AMD, Intel y Arm .

AMD publicó el 6 de agosto el boletín de seguridad AMD-SB-7061, titulado «Safe RET Interrupt Vulnerability». El aviso señala como afectados los procesadores Zen 1 a Zen 4 y vincula el problema principalmente con la implementación de Safe RET en Linux para mitigar Speculative Return Stack Overflow (SRSO), no necesariamente con la arquitectura del procesador por sí sola .

La respuesta en el kernel de Linux siguió este calendario:

• El 2 de junio de 2026 se incorporó un parche desarrollado por Borislav Petkov, de AMD, con el título «x86/bugs: Make Safe-RET robust against interrupt injection» .
• El cambio fue aceptado en el kernel principal el 5 de agosto de 2026 .
• El 6 de agosto llegó a varias versiones, entre ellas 7.1.7, 6.18.43, 6.6.149 y 6.1.181, para corregir CVE-2026-68480 .

Intel reconoció los hallazgos durante el proceso de divulgación coordinada y concedió una recompensa a los investigadores a través de su programa de detección de errores. No obstante, comunicó que no desarrollaría mitigaciones adicionales, aludiendo, entre otros factores, a la disponibilidad de los gadgets de divulgación necesarios para convertir el hallazgo en un ataque práctico .

Por qué importa TONTOU

Los ataques Spectre originales apuntaban directamente a los mecanismos de predicción y ejecución especulativa. TONTOU da un paso distinto: ataca la carrera temporal creada por las propias mitigaciones.

La investigación muestra que limpiar el predictor y utilizarlo no puede tratarse como una operación atómica. Basta una interrupción colocada en el momento adecuado para volver a introducir datos manipulados entre ambas fases.

El parche del kernel cierra la ventana concreta de inyección de interrupciones identificada en los sistemas AMD Zen, pero el hallazgo deja una lección más amplia para la seguridad de las CPU: las defensas contra ataques microarquitectónicos también deben analizarse como posibles superficies de ataque. En este caso, el problema no fue simplemente que el predictor pudiera envenenarse, sino que podía volver a envenenarse justo después de que la protección lo hubiera limpiado.