L’attaque Branch Target Reuse vole le hash du mot de passe root Linux en quelques minutes

29 septembre 2026. Des chercheurs du groupe VUSec de la Vrije Universiteit Amsterdam publient Branch Target Reuse (BTR), une nouvelle variante de Spectre v2 qui cible les moteurs JIT. Septembre 2026. Deux exploits de bout en bout récupèrent le hash du mot de passe root d’un noyau Linux en quelques minutes, sur une machine Intel entièrement corrigée avec les protections par défaut. 29 septembre 2026. Les correctifs arrivent sous les références CVE-2026-64507 et CVE-2026-64508. Pourquoi c’est important : cette attaque réutilise des cibles de branchement devenues obsolètes après la réécriture du code par un JIT, un angle que les défenses actuelles contre Spectre v2 ne couvraient pas.

Un angle mort que Spectre v2 ne couvrait pas

Depuis 2018, la défense contre Spectre v2 repose sur un postulat : si l’on barre les cibles de branchement valides, on empêche le prédicteur de branchement de spéculer vers du code attaquant. Les atténuations classiques — IBPB, STIBP, barrières de retour, et surtout l’eIBRS sur les processeurs récents — visent toutes des branchements indirects dont la cible reste architecturale.

BTR casse ce postulat en exploitant l’interaction entre le code auto-modifiable (SMC) et la prédiction de branchement indirecte. Le constat des chercheurs Sander Wiebing, Yuhui Zhu, Alessandro Biondi et Cristiano Giuffrida tient en une phrase : quand un CPU moderne exécute du code qui se modifie lui-même, il restaure bien la cohérence architecturale, mais il n’invalide pas nécessairement les entrées devenues obsolètes du branch target buffer (BTB). Dans un moteur JIT, ces cibles périmées peuvent survivre au code d’origine, puis être réutilisées quand le cache de code est repeuplé. Résultat : une primitive de « transient execute-after-free » qui détourne le flux de contrôle spéculatif vers du code nouvellement généré, à des offsets désormais invalides.

L’attaque se déroule en quatre temps. D’abord, l’attaquant force le JIT à allouer un bloc d’entraînement et fait pointer la branche victime vers lui, ce qui inscrit une entrée dans le BTB. Ensuite, il libère ce bloc et alloue un bloc cible qui réutilise partiellement la même adresse. Il redéclenche la branche indirecte : le CPU réutilise l’entrée BTB devenue obsolète et spécule vers l’ancien point d’entrée. Enfin, cette exécution transitoire, en accédant à de la mémoire ou en exécutant des gadgets mal alignés, laisse une trace observable dans le cache que l’attaquant mesure pour reconstituer des secrets.

Trois moteurs JIT touchés, un noyau qui fuit

Les chercheurs ont évalué BTR contre trois cibles : SpiderMonkey (le moteur JIT de Firefox), GraalVM, et le cBPF JIT du noyau Linux. Tous sont affectés, mais avec des caractéristiques d’exploitabilité et des taux de fuite « nettement différents », selon le papier.

Le cas le plus parlant est celui du noyau. En exploitant le JIT de l’interpréteur cBPF, les chercheurs ont construit deux exploits de bout en bout capables de fuir puis de récupérer le hash du mot de passe root en quelques minutes. La cible : une machine Intel récente, entièrement corrigée, avec les protections Spectre activées par défaut. Autrement dit, un attaquant disposant d’un simple accès utilisateur non privilégié, capable de charger un programme BPF, peut espérer lire de la mémoire noyau — le scénario exact que les défenses Spectre v2 étaient censées rendre infaisable.

La portée dépasse le noyau. SpiderMonkey exécute du JavaScript non fiable dans Firefox ; si un site web parvenait à déployer BTR à travers le JIT du navigateur, il lirait la mémoire du processus de rendu. Mozilla n’a pas annoncé d’atténuation immédiate : l’éditeur étudie des défenses fondées sur IBPB, mais indique prioriser le déploiement de l’isolation de site, qui limite de toute façon ce qu’un processus de contenu compromis peut atteindre.

Des correctifs aux géométries différentes

La réponse des éditeurs n’est pas uniforme, et c’est instructif. Dans le noyau Linux, les atténuations ont été fusionnées et publiées sous CVE-2026-64507 et CVE-2026-64508 ; appliquer les mises à jour de votre distribution est donc la première action. GraalVM adopte une approche différente : plutôt que de barricader le prédicteur, il randomise les emplacements du cache de code JIT, ce qui complique la réutilisation d’adresses à l’origine de l’attaque. Mozilla, enfin, temporise en misant sur l’isolation plutôt que sur une barrière de prédicteur coûteuse.

Cette hétérogénéité rappelle une leçon de 2018 : il n’existe pas d’atténuation universelle contre les attaques de spéculation. Chaque surface d’exécution de code non fiable — navigateur, machine virtuelle, noyau avec BPF, serverless multi-tenant — doit être raisonnée séparément. Le correctif du noyau ne protège pas Firefox, et la randomisation de GraalVM ne protège pas le noyau.

Vérifier que la protection est réellement active

Appliquer les correctifs ne suffit pas : encore faut-il vérifier que le noyau expose bien les atténuations. La commande suivante lit l’état des défenses Spectre déclaré par le noyau :

$ grep -E 'spectre_v2' /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Enhanced IBRS; IBPB: conditional; STIBP: conditional; ...

Deux nuances s’imposent. D’abord, les atténuations de BTR publiées sous CVE-2026-64507 et CVE-2026-64508 ne se traduisent pas forcément par une nouvelle ligne dans ce fichier : certaines distributions appliquent le correctif au cBPF JIT lui-même sans modifier la déclaration globale. Vérifiez donc la version exacte de votre noyau et la présence des correctifs dans le changelog de votre distribution, plutôt que de vous fier au seul fichier de statut.

Ensuite, ce fichier ne couvre que le noyau. Il ne dit rien de Firefox ni de GraalVM, qui portent leurs propres correctifs — ou, pour Firefox, une absence assumée d’atténuation au profit de l’isolation de site. Un inventaire des surfaces d’exécution de code non fiable, pas un simple grep, est la vraie mesure de votre exposition.

Ce que change BTR dans votre modèle de menace

BTR n’est pas la première attaque de ce type en 2026. Elle arrive environ deux mois après Interrupt Injection, une technique publiée par Daniël Trujillo et Mengjia Yan du MIT CSAIL, qui contournait elle aussi les défenses Spectre v2 pour fuir la mémoire noyau sur des systèmes Intel et AMD. La cadence s’accélère : deux attaques de spéculation contre le noyau en un trimestre suggèrent que la recherche a trouvé un filon — les moteurs JIT et les mécanismes qui exécutent du code dynamique dans l’espace noyau ou à ses portes.

Pour un RSSI, trois conséquences pratiques. Premièrement, la frontière entre « code non fiable » et « hôte » est redevenue poreuse sur les CPU mêmes qui étaient censés la sceller : un simple utilisateur capable d’injecter du BPF (ou du code dans un JIT) ne doit plus être traité comme un acteur sans risque mémoire. Deuxièmement, le patch du noyau est nécessaire mais pas suffisant : il faut inventorier chaque composant qui exécute du code dynamique et vérifier sa posture propre. Troisièmement, la mesure des fuites par canaux auxiliaires demeure un angle mort des outils de détection classiques — une exfiltration qui passe par le cache ne génère ni alerte réseau ni entrée de journal.

Verdict

Si vous exposez des charges de travail multi-tenant ou du code non fiable (navigateurs, VM, serverless, noyau avec BPF chargé par des utilisateurs), appliquez immédiatement les correctifs CVE-2026-64507 et CVE-2026-64508 du noyau, puis dressez l’inventaire de vos moteurs JIT : le correctif noyau ne couvre ni Firefox ni GraalVM. Si vous êtes un opérateur de plateforme hébergeant du code arbitraire, traitez désormais l’isolation entre locataires comme une propriété à prouver, pas à supposer — la randomisation de GraalVM montre qu’une défense par l’imprévisibilité reste moins coûteuse qu’une barrière matérielle, mais elle n’est qu’un correctif d’attente. Et si vous pilotez un parc de postes ou de serveurs, revenez à la base : la fuite du hash root en quelques minutes ne devient critique que si ce hash est faible, réutilisé ou crackable — une politique de mots de passe, d’authentification et de rotation solide réduit l’impact d’une lecture mémoire transitoire avant même qu’elle ne devienne une compromission.

Références

• The Hacker News — New Spectre-v2 BTR Attack Leaks Linux Memory Despite Existing Defenses (29 septembre 2026)
• BleepingComputer — New Spectre v2 attack variant leaks Linux root password hash in minutes (29 septembre 2026)
• Phoronix — Branch Target Reuse, BTR: New Spectre V2 Attack Targeting JIT Compilers (29 septembre 2026)
• VUSec — Systems and Network Security Group, Vrije Universiteit Amsterdam