Des chercheurs du MIT (CSAIL) ont mis au jour une technique baptisée injection d’interruption qui vise à fragiliser certaines protections contre Spectre v2 sur des processeurs Intel et AMD. L’idée n’est pas de « refaire » toute la défense, mais de profiter d’un détail d’exécution : le moment précis où le noyau neutralise l’état de prédiction, puis l’utilise à nouveau.
Concrètement, un programme Linux sans privilèges peut chronométrer une interruption matérielle afin qu’elle tombe dans le créneau entre deux étapes du traitement des prédictions. Résultat : après l’exécution de la défense, le prédicteur peut être “re-poisonné”, ce qui ouvre la voie à des fuites de mémoire côté noyau. La question centrale devient alors : une bonne mitigation pour l’entrée ou la sortie du noyau suffit-elle vraiment, si une interruption peut survenir au milieu ?
Ce que fait l’attaque : une fenêtre entre neutralisation et usage
Les défenses Spectre v2 cherchent à empêcher qu’un attaquant influence la prédiction des branches du noyau. Pour cela, elles neutralisent ou isolent l’état du prédicteur. Mais les chercheurs expliquent que ces mécanismes reposent sur une hypothèse : rien de hostile ne s’exécute entre la neutralisation et l’usage.
Or, les interruptions cassent cette hypothèse. Sur Linux, un utilisateur peut déclencher une interruption avec un contrôle fin, et le matériel peut la traiter presque n’importe quand. Ainsi, même si la mitigation était pensée pour le moment de l’entrée du noyau ou juste avant son retour, le chemin d’exécution lié aux retours d’interruption fait aussi partie du périmètre réel.
Sur une configuration AMD Zen 2 observée dans l’étude, le créneau exploitable correspond à deux instructions (six octets). Les chercheurs ont augmenté leurs chances en provoquant un effet de contention sur le cache : en expulsant les octets concernés du cache L1/L2 via une exécution sur un hyperthread voisin, puis en choisissant un appel système particulier qui leur laissait davantage de contrôle sur des registres.
Résultats chiffrés : fuite de mémoire et précision
Sur une machine AMD Zen 2 exécutant Linux 6.14, avec toutes les mitigations Spectre v2 activées par défaut, l’équipe rapporte une fuite de mémoire arbitraire du noyau à un rythme d’environ 5,47 octets par seconde, avec une précision de 91,97 %.
Le niveau de preuve est suffisamment concret pour permettre de cibler et lire le fichier /etc/shadow (où sont stockés des hachages de mots de passe), avec succès dans cinq tentatives sur dix. L’attaque ne demande donc pas d’accès administrateur : il suffit d’avoir une exécution locale (par exemple via un compte utilisateur qui peut déclencher et chronométrer les interruptions).
Cette contrainte change la nature du risque. Sur des systèmes partagés (hébergement, machines multi-utilisateurs), la possibilité d’un acteur malveillant disposant d’exécution locale devient un point d’attention.
Pourquoi Spectre v2 peut être affecté même si la mitigation existe
Les protections Spectre v2 sont mises en œuvre à différents endroits du traitement noyau. Les chercheurs rappellent, à titre de comparaison :
- Intel applique une neutralisation à l’entrée du noyau, avec eIBRS et, selon le processeur, d’autres mécanismes comme une boucle de purge de l’historique ou un contrôle BHI_DIS.
- AMD applique un mécanisme juste avant chaque retour noyau, via saferet.
Mais dans l’approche décrite, l’attaque vise un cas où une interruption s’insère entre la neutralisation et l’usage réel de la structure qui sert à guider la prédiction. Dès lors, une partie du chemin matériel (le traitement de l’interruption puis du retour) devient le point où l’attaquant peut réintroduire une influence.
Les chercheurs qualifient cette logique de Time-of-Neutralization to Time-of-Use (TONTOU), par analogie avec les risques de type TOCTOU connus en exploitation logicielle. L’idée est que la temporalité fait la différence : la défense a pu s’exécuter, mais le contexte peut être “remis en forme” avant l’usage suivant.
Le rôle d’Inception et l’évolution vers une attaque de bout en bout
Une fois l’interruption positionnée dans la fenêtre, le gestionnaire d’interruption lui-même devient un “gadget” d’entraînement, prêt à produire un effet exploitable. Les chercheurs combinent alors ce principe avec Inception (CVE-2023-20569), une faille qui a été identifiée dans le contexte saferet.
La combinaison est présentée comme un moyen de construire un end-to-end attack, c’est-à-dire une attaque complète menant à une divulgation contrôlée.
Observations sur différentes plateformes
Les résultats d’erreur de prédiction (mispredictions) apparaissent dans le code noyau sur une partie des machines testées. Les taux annoncés varient :
- 0,75 % sur Zen 2
- 0,22 % sur Intel Arrow Lake
- 0,037 % sur Cascade Lake Refresh
Sur Zen 4 dans l’expérimentation rapportée, les chercheurs n’observent pas ces erreurs dans ce test précis. En outre, ils ne démontrent pas une fuite de bout en bout sur Intel dans la configuration testée : en pratique, il faut aussi des éléments exploitables déjà présents dans le noyau (des gadgets de divulgation réutilisables).
Les auteurs estiment toutefois que l’absence de démonstration sur Intel ne constitue pas une barrière technique définitive. Ils indiquent que des gadgets de divulgation existent déjà dans les noyaux, et que la primitive d’injection d’interruption pourrait être combinée avec ces éléments pour obtenir une attaque complète sur d’autres systèmes.
Réactions et correctifs : AMD et MIT, Intel moins pressé
Les chercheurs ont divulgué la technique à AMD et Intel le 5 février, selon le récit. AMD a indiqué qu’une mise à jour noyau était envisagée, tandis que le MIT indique qu’un correctif aurait ensuite été expédié et serait arrivé via une mise à jour logicielle standard.
Le 6 août, AMD a publié un bulletin AMD-SB-7061 intitulé « Safe RET Interrupt Vulnerability ». Le texte décrit un scénario où un attaquant exécutant du code sur une machine concernée pourrait injecter une interruption à un moment précis afin de perturber Safe RET. AMD avertit que cela peut affaiblir la protection et conduire à une divulgation d’informations.
Le bulletin lie également le phénomène à l’implémentation Linux de la mitigation Safe RET. Il mentionne des processeurs Zen 1 à Zen 4 comme affectés, tout en citant des démonstrations sur Zen 1 et Zen 2. Pour Zen 3 et Zen 4, le document suggère un comportement plausible, mais sans preuve expérimentale directe telle que rapportée.
Le papier précise par ailleurs que l’évaluation côté AMD a été réalisée sur Zen 2 et Zen 4. Un point notable : la section “Affected Products and Mitigation” liste des processeurs, mais sans détails tels que version de correctif, commit précis ou identifiant CVE.
En parallèle, les chercheurs rapportent que Intel ne considère pas une mitigation comme nécessaire. L’article souligne aussi que le guidance consultée côté Intel ne mentionne pas d’interruptions et aurait été mise à jour en mai 2025.
Pourquoi il est difficile de vérifier la protection sur le parc
Pour un administrateur système, le bulletin AMD pose un défi opérationnel. Sans numéro de version, sans commit et sans CVE, il n’existe pas de correspondance simple entre “ma machine” et “le correctif exact”. Dans ce contexte, il devient plus ardu de décider si un déploiement est déjà effectué ou s’il reste en attente.
Les chercheurs signalent aussi que les systèmes exposent un statut autour de SRSO via un fichier dans /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow, et indiquent que la documentation définissant les valeurs ne mentionnait pas d’interruptions lors de leur vérification.
Autrement dit : même lorsque la documentation “annonce” un état de mitigation, elle ne garantit pas forcément que la protection couvre les scénarios liés au timing des interruptions.
Quelle piste de correction est discutée ?
Les auteurs proposent une approche complémentaire : une deuxième neutralisation au moment où une interruption se termine. Sur l’idée, il s’agirait de préparer le tampon de pile de retour avant l’instruction de retour (comme iret) ou, sur des puces Intel plus récentes, d’émettre une action du type IBHF à cet endroit.
Bloquer les interruptions uniquement pendant la durée de la fenêtre aurait aussi un effet, mais les chercheurs indiquent que le coût performance n’a pas été quantifié dans leur papier. La solution la plus réaliste dépend donc probablement des compromis d’architecture et des détails de l’implémentation noyau.
Ce que vous pouvez faire dès maintenant
Si vous gérez des serveurs ou des environnements multi-utilisateurs, l’élément le plus important est de considérer l’injection d’interruption comme un risque d’exécution locale, même sans privilèges. Les systèmes concernés seraient alors ceux exposant une surface où un attaquant peut planifier et déclencher des interruptions.
En pratique, la meilleure action consiste à :
- mettre à jour vos noyaux et distributions en suivant les correctifs liés à Spectre v2 et à la vulnérabilité Safe RET mentionnée par AMD ;
- surveiller les avis fabricants pour identifier ce qui est déjà appliqué côté microcode et noyau ;
- évaluer les environnements où l’exécution locale non privilégiée est possible (hébergement mutualisé, plateformes de test, environnements de développement ouverts).
Comme les documents disponibles peuvent ne pas fournir de repère simple (version/commit/CVE), le suivi des mises à jour distribuées par votre fournisseur de système reste souvent le chemin le plus fiable.
Conclusion
L’étude sur l’injection d’interruption montre qu’une défense contre Spectre v2 peut être contournée si le timing permet de réintroduire une influence dans une micro-fenêtre entre la neutralisation du prédicteur et son usage suivant. Les résultats rapportés sur AMD Zen 2, avec des fuites allant jusqu’à /etc/shadow dans une proportion d’essais, soulignent que le risque peut rester tangible même avec des mitigations activées par défaut.
Entre les bulletins AMD, les positions d’Intel et la difficulté à vérifier précisément l’état des correctifs, la vigilance côté administration système est essentielle. Les mises à jour noyau et le suivi des recommandations fabricants restent les meilleures réponses pour réduire l’exposition sur les machines concernées.
Source: https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
