Huit ans après Spectre, des chercheurs contournent encore eIBRS et Safe RET

Deux chercheurs du MIT ont trouvé le chaînon manquant des attaques Spectre : l'intervalle qui sépare le nettoyage du processeur de son utilisation. AMD corrige, Intel préfère payer une prime.

Depuis janvier 2018 et la découverte simultanée de Meltdown et de Spectre par les équipes de Google, l'industrie du processeur vit avec une épine dans le pied. L'exécution spéculative, cette technique qui fait deviner au processeur les instructions à venir pour gagner du temps, laisse derrière elle des traces exploitables. Les fondeurs ont répondu par une décennie de correctifs, de microcodes et de protections matérielles, au prix de quelques pertes de performances. Daniël Trujillo, doctorant, et Mengjia Yan, professeure associée au laboratoire d'informatique et d'intelligence artificielle du MIT, viennent de démontrer à Black Hat que cet édifice comporte une faille de conception. Pas seulement des bugs d'implémentation.

Le trou se trouve entre le nettoyage et l'usage

Pour comprendre l'idée, il faut regarder ce que font réellement les protections actuelles. Le prédicteur de branchement est la partie du processeur qui parie sur la suite du programme, un peu comme un serveur de restaurant qui commencerait à préparer l'addition avant que vous ayez terminé votre dessert. Une attaque Spectre consiste à truquer ces paris pour orienter le processeur vers du code qui laissera fuiter des données. Les défenses consistent donc à nettoyer ou à isoler ce prédicteur avant qu'une portion sensible du système ne s'exécute.

Intel et AMD ont choisi deux écoles opposées. Le premier nettoie à l'entrée du noyau, via son mécanisme eIBRS complété selon les puces d'une boucle d'effacement de l'historique de branchement. Le second nettoie juste avant chaque retour du noyau, avec le dispositif Safe RET introduit après l'attaque Inception, que Trujillo avait justement co-signée en 2023. Les chercheurs baptisent ces approches neutralisation à l'entrée et neutralisation sur place. Toutes deux partagent un postulat commun : entre le moment où l'on nettoie et celui où la branche protégée s'exécute, rien d'hostile ne peut survenir.

C'est ce postulat que TONTOU fait tomber, l'acronyme signifiant Time-of-Neutralization to Time-of-Use, en écho aux courses TOCTOU bien connues des développeurs. La technique repose sur une primitive baptisée injection d'interruptions : un programme sans le moindre privilège programme des interruptions matérielles à haute fréquence, en espérant que l'une d'elles tombe pile dans cette fenêtre. Linux autorise en effet n'importe quel utilisateur à cadencer des minuteries à la nanoseconde près. Une fois l'interruption placée au bon endroit, son gestionnaire rempoisonne les structures de prédiction, et la branche protégée saute là où l'attaquant le souhaite.

Dix-huit minutes pour lire le fichier des mots de passe

La démonstration a été menée sur du matériel très ordinaire : un Ryzen 7 4700G d'architecture Zen 2, doté de 16 gigaoctets de mémoire. La machine tournait sous Linux 6.14, avec toutes les protections Spectre v2 activées par défaut. Dans ces conditions, l'attaque lit la mémoire du noyau à 5,47 octets par seconde avec 91,97 % de précision. Les chercheurs ont d'abord cassé la randomisation de l'espace d'adressage du noyau, ce garde-fou qui déplace les composants du système en mémoire pour égarer les attaquants. Ils sont ensuite allés chercher le contenu du fichier des mots de passe. Ils l'ont localisé cinq fois sur dix tentatives, avec une moyenne de dix-huit minutes par exécution réussie. Aucun accès administrateur n'est requis : exécuter du code utilisateur sur la machine suffit.

Reste que la portée pratique demande d'être mesurée avec soin, et les chercheurs ne s'en cachent pas. Les tests couvrent quatre plateformes, Cascade Lake Refresh et Arrow Lake chez Intel, Zen 2 et Zen 4 chez AMD. L'exploit complet n'existe toutefois que pour Zen 2, la variante Intel exigeant des conditions logicielles particulières. Un débit de cinq octets par seconde n'a rien d'un pillage industriel, et les dix-huit minutes de la démonstration supposent que l'attaquant soit déjà présent sur la machine avec la possibilité d'y exécuter du code. Statistiquement, le risque de croiser un rançongiciel reste très supérieur à celui de subir une attaque par canal auxiliaire. La fenêtre visée sur AMD ne fait d'ailleurs que deux instructions, quelques dizaines de nanosecondes : c'est justement l'exploit de la démonstration que d'y avoir logé quelque chose.

Un fondeur corrige, l'autre paie et passe son chemin

Les deux constructeurs ont été prévenus en février, les mainteneurs du noyau Linux en mars, ce qui laissait le temps de préparer une réponse coordonnée. AMD a publié le 6 août un bulletin baptisé Safe RET Interrupt Vulnerability, qui désigne les architectures Zen 1 à Zen 4 et rattache le problème à l'implémentation Linux de sa protection. Le même jour, les branches stables et de maintenance longue durée du noyau recevaient le correctif, signé par un ingénieur d'AMD. Mettre son système à jour suffit donc à refermer la porte côté Zen. Intel a pris l'autre chemin en indiquant aux chercheurs qu'aucune mitigation supplémentaire n'était prévue, au motif qu'une exploitation réelle dépend de trop de facteurs, à commencer par la présence dans le code de séquences exploitables. Le fondeur a néanmoins versé une prime aux deux chercheurs dans le cadre de son programme de chasse aux bugs (récompenser une découverte tout en jugeant qu'elle ne mérite pas de correctif, la nuance est subtile).

Le bulletin d'AMD ne renvoie vers aucun correctif ni aucun identifiant, alors même que le noyau était déjà corrigé. Rien d'inhabituel quand la faille tient à une classe d'attaques plutôt qu'à une vulnérabilité isolée. Cette distinction compte : TONTOU ne désigne pas un défaut particulier d'une puce donnée, mais un angle mort partagé par toute une famille de protections. La position d'Intel relève d'une continuité assumée, l'entreprise ayant déjà renoncé en 2018 à corriger plusieurs générations de processeurs anciens en jugeant l'opération complexe et de faible utilité. Quant au fond du problème, des ingénieurs de Google prévenaient dès 2019 qu'aucun correctif logiciel ne viendrait à bout de Spectre et qu'il faudrait attendre de nouvelles architectures. Cinq ans plus tard, des chercheurs de l'ETH Zurich contournaient déjà la barrière IBPB sur les puces Intel et AMD, preuve que la série est loin d'être close. Les travaux seront détaillés en octobre lors du symposium USENIX Security.

Pour un particulier, la conduite à tenir n'a rien de spectaculaire : garder son noyau Linux à jour, ce qui suffit sur AMD. Une attaque de ce type suppose de toute façon un intrus déjà capable d'exécuter du code chez vous. Pour les hébergeurs qui font cohabiter plusieurs clients sur une même machine, en revanche, la démonstration rappelle qu'un processeur partagé reste un espace commun, avec ce que cela suppose de cloisons perméables.