- Une nouvelle vulnérabilité de sécurité, Branch Privilege Injection, a été découverte sur les CPU Intel en raison d’une condition de concurrence dans le prédicteur de branche
- Cette attaque est rendue possible par des mises à jour asynchrones et une synchronisation insuffisante entre les domaines de sécurité
- Les mesures d’atténuation matérielles existantes comme eIBRS et IBPB deviennent inefficaces en présence de cette condition de concurrence
- Intel atténue cette vulnérabilité via une mise à jour de microcode, avec un impact sur les performances
- La vulnérabilité affecte tous les CPU Intel à partir de la 9e génération et se manifeste quel que soit le système d’exploitation
Présentation de l’attaque Branch Privilege Injection
- Branch Privilege Injection est une vulnérabilité de sécurité qui remet au goût du jour, sous une nouvelle forme, les attaques d’injection de cible de branche de la famille Spectre-BTI
- Sur les CPU Intel, les défenses matérielles contre Spectre sont restées efficaces pendant six ans, mais cette recherche démontre qu’elles peuvent être contournées via une condition de concurrence (race condition)
- Le prédicteur de branche fonctionne de manière asynchrone par rapport au flux d’instructions, ce qui peut provoquer, dans certaines situations, des mises à jour retardées de plusieurs dizaines à centaines de cycles
- Si une transition de privilège (par ex. utilisateur-kernel, invité-hyperviseur) ou un IBPB se produit pendant qu’une mise à jour du prédicteur de branche est en cours, cette mise à jour peut être associée à tort au nouveau mode de privilège
- Ce phénomène est nommé Branch Predictor Race Condition, et il peut entraîner une fuite d’informations sensibles en mémoire
Démonstration de l’attaque et impact
- Avec cette méthode d’attaque, le débit de fuite mémoire arbitraire atteint 5.6KiB/s sur Ubuntu 24.04 (avec les derniers correctifs et les atténuations par défaut activées)
- Une démonstration vidéo de l’attaque réussie existe sur un CPU Intel Raptor Lake (13e génération)
Mesures d’atténuation affectées
- eIBRS : mécanisme de sécurité introduit sur les CPU Intel à partir de la 9e génération (Coffee Lake Refresh), qui isole la prédiction de branche indirecte par domaine de sécurité.
- IBPB : comme eIBRS ne bloque que les attaques entre domaines de sécurité matériels, IBPB sert à invalider l’ensemble de la prédiction de branche indirecte pour couvrir des zones de sécurité supplémentaires, comme les machines virtuelles non fiables
- Les deux sont des mesures d’atténuation recommandées comme paramètres de sécurité par défaut dans les environnements concernés
Analyse détaillée de la Branch Predictor Race Condition
- Lorsqu’une condition de concurrence se produit dans le prédicteur de branche, les garanties de sécurité d’eIBRS et d’IBPB deviennent caduques
- Lorsqu’une transition de privilège a lieu pendant l’exécution des instructions, une mise à jour de prédiction de branche en cours peut être attribuée à tort au nouveau domaine de sécurité
- Même si un IBPB est exécuté, une mise à jour de prédiction déjà en cours n’est pas purgée et reste dans le prédicteur, ce qui crée un problème de sécurité
Mesures d’atténuation contre la Branch Predictor Race Condition
- Intel a développé une mise à jour de microcode pour les processeurs vulnérables, et le blocage expérimental de l’attaque a été confirmé sur Alder Lake
- Avec cette atténuation, une baisse de performances pouvant atteindre 2.7% a été observée sur Alder Lake
- Des stratégies logicielles d’atténuation alternatives ont également été testées, avec un surcoût de performance mesuré entre 1.6% (Coffee Lake Refresh) et 8.3% (Rocket Lake)
- Des informations supplémentaires sont fournies dans l’article scientifique
Ressources supplémentaires
- L’article de recherche principal sur Branch Privilege Injection doit être présenté à l’USENIX Security 2025
- Une présentation centrée sur la détection de la vulnérabilité et son exploitation est prévue à Black Hat USA 2025
- Le code source des attaques et des expérimentations est publié sur github
FAQ
1. Mon ordinateur est-il concerné ?
- Tous les processeurs Intel à partir de la 9e génération (Coffee Lake Refresh) sont affectés par Branch Privilege Injection
- L’inefficacité d’IBPB a aussi été confirmée sur des produits de 7e génération (Kaby Lake)
2. Les CPU non Intel sont-ils aussi concernés ?
- Selon l’analyse, ce problème n’a pas été observé sur les systèmes AMD et ARM
3. Seul Linux est-il affecté ?
- La preuve de concept vise Linux, mais le problème fondamental se situe dans le matériel
- Tous les systèmes d’exploitation fonctionnant sur ce matériel sont vulnérables
4. Quelles mesures prendre ?
- Il est recommandé d’installer les dernières mises à jour du système d’exploitation et du BIOS
1 commentaires
Avis Hacker News
Dans un texte publié à Harvard, un intervenant relève une métaphore malicieuse selon laquelle, pour le malheur de John, les branchements ont passé un pacte avec Satan et la mécanique quantique pour jeter un sort néfaste aux processeurs des générations futures, un sort qui a fini par porter des noms comme « fuite de tension due au scaling » ou « hausse de chaleur gaspillée »
On note aussi que les textes de James Mickens sont toujours amusants, avec une citation d’une blague disant que le Mossad chargé de la sécurité ne se soucie pas vraiment de choses comme HTTPS : s’ils ont besoin des données, ils remplacent carrément votre téléphone par une imitation en uranium via un drone, puis finissent par racheter vos affaires lors d’une vente de succession pour regarder eux-mêmes les photos
Un commentaire estime que le passage mentionnant de nombreuses matrices laisse entrevoir un peu d’espoir, et raconte que le frère de John a trouvé comment apprendre à ces matrices à parler comme des humains
Partage d’un lien vers le blog des chercheurs et l’article scientifique
Retour indiquant que le lien ci-dessus a été remplacé, depuis le communiqué de l’université, par le billet de blog des chercheurs
Au sujet de l’impact de la nouvelle vulnérabilité, un chercheur explique qu’il est possible de lire de manière répétée l’intégralité de la mémoire du CPU, à un débit pouvant atteindre 5 000 octets par seconde, ce qui signifie qu’en cas de réussite de l’attaque, toutes les informations du CPU peuvent fuiter
Souhait que l’URL du titre soit remplacée par le lien du blog
Récapitulatif du fonctionnement du prédicteur de branchement
Content de voir que le professeur Kaveh Razavi a enseigné un cours sur la sécurité matérielle dans son université, et que ce cours était vraiment excellent
Quelqu’un laisse une question : il y a quelques années, il avait essayé de retrouver ce cours ainsi qu’un autre sur les malwares, mais n’avait trouvé presque aucune information publique ; il se demande s’il existe des vidéos officielles du cours ou des notes en ligne
Quelqu’un demande si une personne connaît le lien entre l’attaque Training Solo et cette vulnérabilité
Une remarque s’interroge sur le fait que l’explication des correctifs de microcode pour le chipset ne mentionne que Windows, et demande ce qu’il en est pour les utilisateurs de Linux
Réponse : le noyau Linux prend en charge le chargement de microcode depuis longtemps, mais encore faut-il qu’Intel publie les fichiers de microcode pour que chaque distribution puisse les intégrer dans ses mises à jour système
Autre précision : Intel publie les mises à jour de microcode pour Linux sur github, donc les distributions les récupèrent automatiquement depuis là pour les redistribuer ; en revanche, l’auteur précise ne pas savoir, faute d’expertise, si cette vulnérabilité précise a effectivement été corrigée
Partage d’un lien vers l’avis officiel de sécurité d’Intel
Un commentaire se demande si les CPU AMD sont touchés par une vulnérabilité similaire, en soulignant que des mécanismes techniques comme la prédiction de branchement sont à l’origine même des failles de sécurité CPU, et se demande comment AMD évite ce type de vulnérabilité
Réponse, résumant le blog des chercheurs : cette vulnérabilité Branch Privilege Injection n’affecte pas les systèmes AMD ni ARM
Autre réponse : cela ne veut pas dire qu’AMD échappe totalement à ce genre de problème ; comme pour Spectre et Meltdown, la portée varie selon la vulnérabilité, et si celle-ci est propre à Intel, AMD a déjà été exposé à des vulnérabilités de la même famille, par exemple Spectre
Explication plus minutieuse : l’exécution spéculative en soi n’est pas une vulnérabilité mais un mécanisme indispensable aux CPU modernes ; l’intérieur de ces puces est si complexe que certains défauts peuvent être difficiles à découvrir, donc AMD et ARM pourraient aussi avoir des bugs comparables ; selon cet avis, la seule manière de régler complètement le problème serait d’admettre qu’une isolation parfaite du code est impossible sur les systèmes modernes, ce qui poserait un problème fatal pour le modèle économique de certains grands groupes
Concernant une contre-mesure à cette vulnérabilité, un commentaire suggère qu’on pourrait enregistrer un instantané du niveau de privilège au moment de la mise à jour de la prédiction de branchement et propager cette valeur avec elle, ce qui ressemblerait à la manière dont on résout des problèmes comparables en logiciel
Quelqu’un note avec humour que si le prédicteur de branchement du CPU pouvait vérifier directement les limites des buffers et les informations de privilège du code, il aurait été plus facile de prévenir cela, mais que cela impliquerait d’ajouter des informations importantes aux pointeurs
Un autre commentaire estime qu’il faut mieux cerner l’ampleur réelle du problème : les attaques exploitant l’exécution spéculative demandent en pratique une préparation énorme et n’ont guère d’intérêt sans capacité d’exécuter du code directement ; il n’est pas possible, selon lui, de faire fuiter des informations arbitraires depuis un navigateur avec du code JS arbitraire ; pour sa part, il désactive toutes les mitigations pour gagner en performances
Recommandation de l’architecture CHERI
Une réponse souligne que modifier uniquement la structure des pointeurs ne suffirait pas ; elle mentionne l’ancien modèle de segmentation x86 côté matériel (80286), qui associait réellement des informations de limites d’adresse à chaque accès mémoire ; même de tels systèmes exigeaient toutefois que le logiciel manipule correctement les informations de limite, et ils finissaient par rencontrer la même limite fondamentale
Question pour savoir si, à ce stade, tous les principaux systèmes d’exploitation ont bien reçu un correctif pour cette vulnérabilité, ou le microcode correspondant
Réponse : oui, la divulgation a lieu aujourd’hui (13 mai)