Huit ans après l’émergence de Spectre, des chercheurs du MIT CSAIL ont démontré que certaines défenses contre les attaques par exécution spéculative peuvent à nouveau être contournées si une interruption survient précisément dans le court intervalle entre le nettoyage du prédicteur de branche et sa réutilisation ultérieure. Le travail, nommé TONTOU, concerne des scénarios étudiés sur des processeurs Intel et AMD et a conduit AMD à publier une mitigation pour Linux liée à Safe RET.

Les résumés clés de TONTOU en 20 secondes

• TONTOU exploite des fenêtres temporelles apparaissant entre la neutralisation du prédicteur et sa prochaine utilisation.
• Les chercheurs utilisent une technique appelée Injection d’Interruption pour introduire une activité dans cet intervalle.
• Les tests incluent des processeurs Intel Cascade Lake Refresh, Arrow Lake, ainsi que AMD Zen 2 et Zen 4.
• Sur AMD Zen 2, ils ont conçu une exploitation capable d’extraire des informations du noyau.
• AMD attribue le problème observé à l’implémentation Linux de Safe RET et recommande de mettre à jour le système.

L’étude ne révèle pas une autre variante classique basée simplement sur l’entraînement du prédicteur par un processus attaquant. Sa contribution principale est de montrer qu’une mitigation apparemment efficace pour nettoyer l’état spéculatif peut échouer s’il existe un intervalle entre la neutralisation de cet état et son utilisation ultérieure.

Ce concept donne son nom au travail : Time-of-Neutralization to Time-of-Use, TONTOU.

L’étude a été rédigée par Daniël Trujillo et Mengjia Yan, du MIT CSAIL et fait partie du programme de USENIX Security 2026.

Une interruption de seulement quelques nanosecondes peut à nouveau contaminer le prédicteur

Les processeurs modernes utilisent l’exécution spéculative pour anticiper le flux réel du programme. Plutôt que d’attendre de connaître le résultat de chaque saut, ils tentent de prédire le chemin à suivre et commencent à exécuter des instructions en avance.

Lorsque la prédiction est erronée, ces opérations sont archétiquement annulées. Le problème que Spectre avait mis en évidence en 2018 est que certains effets microarchitecturels peuvent persister et servir de canaux latéraux pour inférer des informations.

Les mitigations ultérieures cherchent à empêcher qu’un attaquant contrôle l’état utilisé par ces prédicteurs.

TONTOU indique une vulnérabilité différente.

Après avoir nettoyé ou isolé le prédicteur, il y a inévitablement du code avant que le CPU n’utilise à nouveau cette information. Si une interruption se produit à cet instant précis, le gestionnaire d’interruption peut de nouveau modifier l’état microarchitectural.

Les chercheurs appellent Injection d’Interruption cette technique employée pour y parvenir.

Un programme local peut utiliser des temporisateurs pour provoquer des interruptions et ajuster progressivement leur moment d’exécution jusqu’à les faire coïncider avec ces fenêtres.

La précision nécessaire peut être extrême. Dans le cas de la mitigation Safe RET d’AMD, les chercheurs décrivent une fenêtre d’à peine deux instructions.

Ils ont néanmoins réussi à l’atteindre.

Intel a aussi montré des prédictions erronées malgré les défenses existantes

L’étude a évalué quatre plateformes :

Chez Intel, les chercheurs ont réussi à provoquer des prédictions erronées dans des situations protégées par des mécanismes liés à la gestion de l’historique de branchements, notamment BHI_DIS_S.

Ce dernier est un contrôle conçu pour limiter l’impact de l’historique de branchements sur des prédictions effectuées en mode privilégié. Intel documente BHI_DIS_S dans ses protections contre l’Injection d’Histoire de Branche (BHI) et dispose aussi de l’instruction IBHF, Indirect Branch History Fence, destinée à empêcher l’influence de l’historique préalable sur certaines prédictions ultérieures.

Le comportement observé par TONTOU ne signifie pas automatiquement que toutes ces protections sont inefficaces sur tous les processeurs Intel.

Une conclusion clé de l’étude est que la même défense peut se comporter différemment selon la microarchitecture.

Intel recommande donc des mesures spécifiques selon la génération et les capacités du processeur, notamment BHI_DIS_S, des séquences logicielles de nettoyage du Branch History Buffer (BHB), IBPB et d’autres mesures selon le contexte.

Par conséquent, l’impact pratique de TONTOU sur Intel doit s’analyser au cas par cas, en fonction de la plateforme et de la configuration, et non simplement sur la marque.

Sur AMD Zen 2, on est passé de la théorie à l’extraction de mémoire du noyau

La démonstration la plus inquiétante de l’étude a été menée sur AMD Zen 2.

Safe RET est la mitigation logicielle utilisée par Linux face à Speculative Return Stack Overflow (SRSO) sur certains processeurs AMD. La documentation du noyau mentionne safe-ret comme une des options de mitigation, aux côtés d’autres méthodes basées sur le microcode ou IBPB.

TONTOU parvient à introduire l’interruption entre le nettoyage réalisé par Safe RET et le retour spéculatif que ce nettoyage cherche à protéger.

Les chercheurs ont ensuite développé une chaîne d’exploitation complète sous Linux.

Selon les résultats présentés, ils ont d’abord réussi à casser le KASLR (Kernel Address Space Layout Randomization) lors des dix tests, en une moyenne d’environ neuf minutes.

KASLR permet de rendre aléatoire la position du noyau en mémoire pour compliquer une attaque visant à connaître les adresses nécessaires à une exploitation.

Après avoir contourné cette protection, TONTOU a permis d’extraire de la mémoire arbitrée du noyau à une vitesse d’environ 5,47 octets par seconde, avec une précision proche de 91,97%.

Ce n’est pas une vitesse élevée, mais un canal latéral n’a pas besoin de transférer des mégaoctets par seconde pour être utile.

Les chercheurs ont utilisé cette capacité pour tenter de localiser le fichier /etc/shadow, qui stocke sur Linux les informations liées aux hachages des mots de passe.

Ils ont réussi dans cinq des dix essais, avec une moyenne d’environ 18 minutes.

Cela fait de TONTOU autre chose qu’une simple démonstration qu’une prédiction incorrecte reste possible.

Ce n’est pas une attaque à distance, mais cela a une importance particulière sur les serveurs partagés

Pour exploiter ce scénario, il faut exécuter du code local sans privilèges sur le système touché.

Ainsi, TONTOU ne permet pas de compromettre directement un ordinateur vulnérable via Internet, simplement en lui envoyant du trafic.

Cette condition réduit considérablement le risque pour un ordinateur classique exécutant uniquement des logiciels de confiance.

En revanche, la situation évolue dans les environnements multi-utilisateurs, serveurs partagés, plateformes de développement ou certains environnements cloud.

Dans ces cas, il est courant que du code appartenant à différents utilisateurs partage le même matériel physique. Les attaques microarchitecturelles sont particulièrement préoccupantes car elles tentent de traverser des séparations qui, du point de vue logique du système d’exploitation ou de l’hyperviseur, devraient être maintenues.

USENIX souligne dans son programme 2026 que ces attaques continuent d’être une source d’inquiétude spécifique pour les clouds publics, en raison du risque de fuite d’informations entre locataires partageant une même infrastructure physique.

Cela ne signifie pas que TONTOU permet d’échapper automatiquement à une machine virtuelle ou de compromettre un fournisseur cloud. Son exploitation dépend du processeur, du noyau, des mitigations disponibles et de la capacité de l’attaquant à exécuter du code dans les conditions nécessaires.

AMD confirme la vulnérabilité de Zen 1 à Zen 4 dans le cadre de Safe RET

AMD a publié sa réponse sous la référence AMD-SB-7061, Safe RET Interrupt Vulnerability.

Le fabricant explique qu’un chercheur externe a signalé qu’une interruption soigneusement synchronisée pouvait compromettre Safe RET, la mitigation par défaut sous Linux contre SRSO.

AMD indique que ce comportement a été démontré sur Zen 1 et Zen 2 et que les chercheurs pensent que Zen 3 et Zen 4 pourraient également être affectés par ce même principe, bien que cette exploitation spécifique n’ait pas été démontrée sur ces générations.

L’évaluation d’AMD est également importante, car elle situe principalement le problème dans l’implémentation Linux de Safe RET, plutôt que dans un défaut matériel nécessitant le remplacement des processeurs.

L’entreprise et les développeurs du noyau ont travaillé sur une mitigation logicielle ; la recommandation pratique pour les administrateurs est donc d’maintenir le système à jour en appliquant les mises à jour du noyau.

Les correctifs de Spectre vont-ils à nouveau réduire les performances ?

Il s’agit probablement de la question la plus cruciale d’un point de vue gestion d’infrastructure.

Les premiers correctifs contre Spectre et Meltdown ont montré qu’il pouvait y avoir un coût mesurable à la protection contre certaines transitions spéculatives, notamment dans les charges de travail comportant beaucoup d’appels système, de virtualisation ou d’opérations d’entrée/sortie.

TONTOU remet ce compromis sur la table.

Une solution apparemment simple serait de nettoyer à nouveau le prédicteur à chaque retour d’interruption.

Les chercheurs considèrent que cette approche peut être utile sur certains processeurs AMD. Cependant, ils avertissent que le comportement pourrait ne pas se transférer directement à Intel.

Une autre voie serait d’utiliser des mécanismes plus robustes comme IBPB (Indirect Branch Prediction Barrier).

Linux propose déjà l’option IBPB pour la mitigation SRSO sur AMD :

spec_rstack_overflow=ibpb

Il existe aussi :

spec_rstack_overflow=ibpb-vmexit

ciblant spécifiquement l’application d’IBPB lors de la sortie d’une machine virtuelle dans un environnement cloud.

Le problème, c’est que les barrières plus strictes peuvent impacter davantage les performances.

Bloquer les interruptions durant toutes les fenêtres sensibles serait une autre solution, mais les chercheurs considèrent que cela pourrait être trop coûteux.

Pour l’instant, il n’existe pas de données suffisantes pour affirmer que TONTOU provoquerait une perte généralisée comparable à celle de certaines mitigations apportées après 2018.

La mitigation finale dépend de chaque fabricant, microarchitecture et système d’exploitation.

Spectre reste une famille de problèmes, pas une vulnérabilité définitivement éradiquée

TONTOU enseigne également une leçon plus large.

Les mitigations contre l’exécution spéculative sont souvent analysées en supposant une séquence plutôt propre :

état contaminé
      ↓
mitigation
      ↓
état purifié
      ↓
utilisation sûre

L’étude montre que la réalité peut parfois ressembler davantage à ceci :

état contaminé
      ↓
mitigation
      ↓
état purifié
      ↓
INTERRUPTION
      ↓
nouvel état microarchitecturel
      ↓
utilisation du prédicteur

Le problème ne réside pas forcément dans l’échec de la phase de nettoyage.

Il peut se situer dans ce qui se passe après le nettoyage mais avant d’utiliser la ressource protégée.

Ces fenêtres TOCTOU (Time of Check to Time of Use) sont connues depuis des décennies en sécurité logicielle. TONTOU applique un concept similaire, mais à une échelle microarchitecturelle beaucoup plus difficile à observer.

C’est pourquoi Spectre continue d’alimenter la recherche huit ans après sa première révélation.

Les fabricants ont renforcé leurs processeurs de manière significative, et les systèmes d’exploitation intègrent plusieurs couches de protections, mais l’exécution spéculative reste une composante clé des performances modernes des CPU. Le défi consiste toujours à en profiter sans que l’état interne utilisé pour accélérer le processeur devienne une source d’informations exploitables.

Questions fréquentes

Qu’est-ce que TONTOU ?

TONTOU est une nouvelle catégorie d’attaque étudiée par le MIT CSAIL, exploitant l’intervalle entre la neutralisation d’un certain état du prédicteur spéculatif et sa réutilisation ultérieure.

Qu’est-ce que l’Injection d’Interruption ?

Il s’agit de la technique employée par les chercheurs pour provoquer une interruption à un moment précis et modifier à nouveau l’état microarchitecturel après qu’une mitigation l’aura nettoyé.

Quels processeurs ont été testés ?

L’étude a utilisé AMD Ryzen 7 4700G, AMD EPYC 9124, Intel Xeon Gold 5220R et Intel Core Ultra 9 285H. La chaîne d’exploitation complète pour la fuite mémoire a été développée sur AMD Zen 2.

Que doivent faire les administrateurs système ?

Sur les systèmes AMD affectés par Safe RET, AMD recommande d’appliquer les mises à jour du système d’exploitation comportant la mitigation. Sur les serveurs et environnements cloud, il convient également de vérifier la configuration des protections Spectre/SRSO fournies par le noyau, la distribution ou le fabricant.

Sources :

• MIT CSAIL / Daniël Trujillo et Mengjia Yan, recherche TONTOU: On the Exploitability of Time-of-Neutralization to Time-of-Use Windows.
• USENIX Security 2026, programme technique et présentation de TONTOU.
• AMD, AMD-SB-7061 : Vulnerabilité d’interruption Safe RET, 08/06/2026.
• Documentation du Kernel Linux, mitigation du saut spéculatif overflow de la pile de retour (static.lwn.net)
• Intel, documentation sur l’Injection d’Histoire de Branche, BHI_DIS_S et IBHF.