Branch Privilege Injection : exploitation d’une condition de concurrence dans le prédicteur de branchement
(comsec.ethz.ch)- Branch Privilege Injection est une vulnérabilité qui permet de contourner à nouveau des défenses matérielles de la famille Spectre-BTI, en place depuis environ 6 ans, via une condition de concurrence dans le prédicteur de branchement des CPU Intel
- Le cœur de l’attaque tient au fait que les mises à jour du prédicteur de branchement sont traitées de façon asynchrone par rapport au flux d’instructions et peuvent, dans certaines conditions, être prises en compte avec un retard de dizaines à centaines de cycles
- Si des mises à jour retardées subsistent lors d’un changement de privilèges ou de l’exécution d’IBPB, elles peuvent ensuite être associées au mauvais domaine de sécurité, ce qui casse les garanties de sécurité d’eIBRS et d’IBPB
- Les chercheurs ont démontré une attaque de bout en bout sur Ubuntu 24.04, avec toutes les mesures d’atténuation par défaut activées, exfiltrant de la mémoire arbitraire à 5,6 KiB/s sur un Intel Raptor Lake de 13e génération
- La mise à jour du microcode d’Intel a bloqué, lors d’une évaluation sur Alder Lake, la primitive de détection de la vulnérabilité, avec un surcoût allant jusqu’à 2,7 %
Conditions nécessaires à Branch Privilege Injection
- Branch Privilege Injection est une attaque par injection de cible de branchement, c’est-à-dire une attaque qui rend à nouveau possible, dans les environnements Intel, la puissance de Spectre-BTI
- Les mesures d’atténuation matérielles d’Intel bloquaient ce type d’attaque depuis environ 6 ans, mais cette étude montre qu’une condition de concurrence dans les CPU Intel peut ébranler cette défense
- L’attaque repose sur deux observations
- Le prédicteur de branchement des processeurs Intel est mis à jour de façon asynchrone par rapport au flux d’instructions
- Dans certaines conditions, une mise à jour peut être retardée de dizaines, voire de centaines de cycles
- La mise à jour asynchrone n’est pas en soi une vulnérabilité, mais une fonctionnalité
- La synchronisation est insuffisante entre le prédicteur de branchement et le flux d’instructions lors d’opérations importantes pour la sécurité
- Pendant le passage du mode utilisateur au noyau, ou d’un invité à l’hyperviseur, une mise à jour peut encore être en cours
- Des mises à jour en cours peuvent aussi subsister pendant l’exécution d’IBPB
- Si ces mises à jour arrivent après le changement de privilèges, elles sont associées non pas aux anciens privilèges, mais au nouveau mode de privilège
- Le prédicteur de branchement des processeurs Intel est mis à jour de façon asynchrone par rapport au flux d’instructions
- Cette catégorie de vulnérabilités s’appelle Branch Predictor Race Conditions
Mesures d’atténuation contournées et périmètre d’impact
- eIBRS est une mesure d’atténuation de Spectre-BTI introduite par Intel sur tous ses processeurs depuis la 9e génération Coffee Lake Refresh
- Son objectif est de séparer les prédictions de branchements indirects selon les différents domaines de sécurité
- Elle est conçue pour associer chaque prédiction au domaine dans lequel elle a été créée, puis pour n’utiliser ensuite que les prédictions du domaine courant
- Si une mise à jour en cours pendant un changement de privilèges est associée au nouveau domaine de sécurité, cette association peut être manipulée
- IBPB est un mécanisme utilisé pour isoler des sandbox ou des machines virtuelles ne se faisant pas mutuellement confiance au sein d’un même domaine de sécurité matériel
- Il fournit une fonction d’invalidation de toutes les prédictions de branchements indirects
- Les mises à jour en cours ne sont pas purgées par IBPB et peuvent donc être enregistrées dans le prédicteur de branchement même après l’invalidation
- Le périmètre d’impact varie selon les générations et les architectures
- Tous les processeurs Intel depuis la 9e génération Coffee Lake Refresh sont affectés par Branch Privilege Injection
- Le contournement prédictif d’IBPB a été observé jusqu’à la 7e génération Kaby Lake
- Aucun problème n’a été découvert sur les systèmes AMD et ARM évalués
- L’attaque de preuve de concept a été créée pour Linux, mais le problème fondamental se situe dans le matériel ; les systèmes d’exploitation exécutés sur du matériel affecté sont donc concernés
Mesures d’atténuation, coût en performances et ressources publiées
- Il est recommandé d’installer les dernières mises à jour du système d’exploitation et du BIOS
- Intel a développé une mise à jour du microcode pour les processeurs affectés, et les chercheurs l’ont évaluée sur Alder Lake
- La mesure d’atténuation par microcode bloque la primitive de détection de la vulnérabilité
- Elle affiche un surcoût allant jusqu’à 2,7 % sur Alder Lake
- Des mesures d’atténuation logicielles alternatives ont également été évaluées
- 1,6 % de surcoût sur Coffee Lake Refresh
- 8,3 % de surcoût sur Rocket Lake
- Les détails techniques sont disponibles dans l’article
- L’article sur Branch Privilege Injection doit être présenté à USENIX Security 2025, avec également une présentation prévue à Black Hat USA 2025
- Le code source de l’attaque et des expériences est publié sur github
1 commentaires
Avis de Hacker News
Article de blog des chercheurs : https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Article scientifique : https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
Dans un scénario d’attaque, ce n’est finalement qu’une question de temps avant que toutes les informations de la mémoire du CPU ne tombent entre de mauvaises mains
Bon article. En résumé, la mise à jour du prédicteur de branchement peut être repoussée longtemps après le retrait (retire) de l’instruction de branchement
Sinon, le retrait de l’instruction de branchement prendrait plus de temps, donc c’est logique. Les instructions de sérialisation du dispatch ne semblent pas non plus bloquer le pipeline à cause des mises à jour en attente de l’état du prédicteur, ce qui est naturel puisqu’on a déjà distingué « commit du résultat de l’instruction de branchement » et « commit du résultat de la prédiction »
Les instructions de changement de privilège ne bloquent pas non plus le pipeline à cause des mises à jour en attente, ce qui n’est valable que si l’on peut garantir que le niveau de privilège est cohérent entre le moment où la prédiction est créée et celui où elle est commitée. Sinon, une prédiction créée par du code à un niveau de privilège peut être commitée dans un état utilisé à un autre niveau de privilège
Peut-être que c’est un problème difficile parce que, dans le pipeline, le niveau de privilège courant n’est pas une valeur unique et clairement définie
Content de voir Kaveh Razavi. Il enseignait auparavant à la Vrije Universiteit d’Amsterdam, et le cours Hardware Security abordait ce genre de sujets en profondeur, c’était vraiment excellent
Je me demande s’il existe des enregistrements officiels ou des notes en ligne
Quelqu’un sait quel rapport cela a avec l’attaque Training Solo qui vient d’être publiée ? https://www.vusec.net/projects/training-solo/
Training Solo entre dans le noyau, change de niveau de privilège, puis utilise un « auto-entraînement » pour amener une branche à être mal prédite vers un disclosure gadget et ainsi faire fuiter la mémoire
Branch predictor race conditions entre dans le noyau alors qu’une mise à jour entraînée du prédicteur de branchement est encore en cours de traitement, ce qui rattache cette mise à jour au mauvais niveau de privilège. Cela sert ensuite à rediriger une branche du noyau vers un disclosure gadget et à faire fuiter la mémoire
Si le prédicteur de branchement du CPU pouvait directement utiliser les informations nécessaires pour vérifier les limites de tampon et le niveau de privilège du code, ce genre de problème serait beaucoup plus facile à éviter
Mais cela n’arrivera probablement pas tant qu’on n’aura pas arraché
void*des mains glacées des programmeurs C et enrichi les pointeurs avec des informations importantesPour faire ce que tu veux, il faudrait une architecture matérielle où tous les loads/stores passent par une sorte d’« adresse augmentée » qui stocke les informations de limites
En gros, tu demandes la segmentation 80286, qui a déjà existé et n’a pas fait ce que tu veux. La raison est que ces descripteurs de segments doivent eux aussi être correctement chargés par le logiciel. Du point de vue du logiciel, ce ne sont au final que de « simples pointeurs », vulnérables aux mêmes erreurs
Dans le cas de l’exécution spéculative, il faut une préparation absurde pour exploiter réellement la vulnérabilité. En pratique, la seule manière réellement exploitable est d’avoir un accès direct à la machine et d’y exécuter du code bas niveau. Ce n’est pas le genre de chose où du simple JS exécuté dans un navigateur permettrait de faire fuiter n’importe quel secret
Si un système est assez précieux pour justifier les recherches et le ciblage par une organisation privée spécialisée ou soutenue par un État, il devrait de toute façon disposer de mécanismes empêchant l’exécution de code arbitraire non autorisé
Personnellement, le gain de performances se ressent vraiment, donc je désactive toutes les mesures d’atténuation
Avis de sécurité Intel : https://www.intel.com/content/www/us/en/security-center/advi...
Je me demande s’il existe une faille similaire sur le matériel AMD. L’exécution spéculative ressemble à une vulnérabilité très difficile à corriger dans un espace processeur partagé, donc je me demande comment AMD y a échappé
Aucun problème n’aurait été trouvé sur les systèmes AMD et ARM évalués
Source : https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Cette vulnérabilité précise semble spécifique à Intel, comme Meltdown, mais AMD était aussi vulnérable au Spectre original
En revanche, les moteurs d’exécution spéculative sont complexes, donc les bugs et vulnérabilités y sont très répandus
Il est très probable qu’AMD et ARM aient aussi des bugs similaires. Il suffit de voir combien de temps ces bugs sont restés non découverts chez Intel
Malheureusement, la vraie solution serait d’admettre qu’il est impossible d’isoler le code exécuté sur les systèmes modernes, ce qui pourrait être fatal au modèle économique de certaines entreprises très riches
Ce n’est pas le même genre de problème, avec la même solution, que ce qu’on pourrait voir côté logiciel ?
Il est dit que « pour combler ce type de faille, une mise à jour spéciale du microcode du processeur est nécessaire. Elle peut être fournie via une mise à jour du BIOS ou du système d’exploitation, elle devrait donc être installée sur le PC avec l’une des dernières mises à jour cumulatives de Windows ». Pourquoi ne mentionner que Windows ? Et les utilisateurs de Linux ?
Les distributions sont configurées pour les récupérer à partir de là et les distribuer automatiquement
En revanche, je ne sais pas trop quoi regarder pour vérifier si cette mitigation précise y est déjà incluse
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL)Mais Intel doit publier les fichiers de microcode nécessaires pour que les mainteneurs des distributions puissent mettre à jour leurs paquets, puis ce sera inclus dans les mises à jour système
Je me demande si Intel a un moyen de se redresser. Il n’y a pas vraiment de produits convaincants sur le marché, la R&D prend beaucoup de temps, et les fonderies sont à la traîne par rapport aux concurrents et restent une source de pertes
En plus, x86 est de plus en plus repoussé par le matériel ARM, et maintenant RISC-V venu de Chine prend aussi de l’ampleur. Bien sûr, il y a aussi l’angle des semi-conducteurs américains. Surtout après les problèmes rencontrés pendant le Covid, les États-Unis laisseraient-ils un fabricant clé comme Intel s’effondrer ?
La situation n’est pas bonne, mais le sensationnalisme est ridicule
Les gamers ne représentent que quelques pourcents des utilisateurs de produits Intel, et pourtant c’est ce dont on entend le plus parler. Une ou deux commandes de datacenters sont plus importantes que tous les CPU gaming qu’Intel vend en un an. Intel tient encore bien sur le marché des datacenters
En plus, Intel domine toujours le marché des ordinateurs portables d’entreprise, qui est lui aussi nettement plus grand que le marché des gamers
Arm n’avait que 15 % de part de marché dans les datacenters l’an dernier, et n’a pas encore vraiment percé sur le marché Windows
Indépendamment des produits, du point de vue des actionnaires et du business, j’ai tendance à considérer les choses séparément, car les performances financières reflètent de moins en moins les produits finaux ces temps-ci ; pour moi, Intel est presque too big to fail
Je veux vérifier que j’ai bien compris : à l’heure actuelle, tous les principaux systèmes d’exploitation disposent-ils de correctifs pour atténuer ce problème ou appliquer le microcode correspondant ?