Avant de parler de cette découverte, il faut revenir à ce qu’est Spectre. Révélée en même temps que Meltdown, elle réside dans le fonctionnement de pratiquement tous les processeurs Intel, AMD et ARM depuis 1995, déclenchant une frénésie de correctifs. À cette époque, ces entreprises ont intégré une fonctionnalité dans leurs processeurs permettant d’exécuter spéculativement les instructions, la prédiction de branchement.

Sur la base d’hypothèses considérées comme vraisemblables, les processeurs peuvent tenter de prédire les instructions qui seront exécutées au sein d’une application. Si l’hypothèse est vérifiée, le processeur a gagné du temps, entrainant une hausse des performances. Si elle est erronée, la branche spéculative est abandonnée et l’exécution reprend son rythme normal.

Mauvais chemin, vraies données

Problème : pour fonctionner, la branche spéculative accède aux mêmes données que lors de l’exécution classique. L’attaque Spectre consistait alors à accéder à ces données pour les exfiltrer par canal auxiliaire. « Comme elle n'est pas facile à corriger, elle va nous hanter pendant un certain temps », avaient alors déclaré les chercheurs à l’origine de la découverte, en 2018. Ils avaient choisi le nom « Spectre » en référence à cette « hantise ».

Une attaque Spectre cherche donc à faire passer les instructions par le mauvais chemin. Elle peut fracasser l’isolation entre les processeurs et permet à un malware de manipuler les applications afin de leur faire remonter des données dans la branche spéculative.

Trois ans plus tard, le problème restait presque entier

Des correctifs avaient été publiés, mais de nouvelles variantes sont apparues régulièrement. Pour que les défenses soient rebâties, il fallait surtout qu’Intel, AMD et ARM sortent de nouvelles puces incluant des barrières physiques. Et même si ce fut le cas, ces protections n’ont pas été suffisantes.

Intel a recommandé de mettre en place la barrière nommée LFENCE (qui existait déjà depuis des années) pour atténuer les risques de Spectre. Elle place le code sensible dans une zone d’attente, le temps que tous les contrôles de sécurité aient été effectués. Malheureusement, d’autres chercheurs avaient montré que ce n’était pas si simple : les murs de cette salle d’attente étaient poreux.

Il était donc possible de faire passer des informations de cette salle d’attente vers le cache dédié aux micro-opérations (ou micro-ops), les instructions bas niveau du CPU. Avec l’attaque Spectre modifiée, ce cache devenait lui aussi un nouveau canal auxiliaire, permettant la récupération des informations par des malwares. Et là encore, presque tous les processeurs étaient concernés.

Les branchements indirects

Pour se rapprocher encore un peu du problème soulevé récemment par les chercheurs suisses, il faut revenir au mécanisme de prédiction de branchement. Il prend appui sur deux paramètres : l’adresse de destination et le statut « pris ». Le premier définit où le branchement se fera (direction de prédiction), tandis que le second reflète le statut du saut conditionnel, qui indique si la branche spéculée est acceptée ou pas. Quand la prédiction se révèle erronée, il n’y a pas de branchement et les instructions en attente, dites transitoires, sont abandonnées et écrasées. L’algorithme permettant de savoir si un branchement est pris ou non est matériel et donc implémenté dans le processeur.

On distingue également deux types de branchement. Le premier, direct, correspond à la situation où l’adresse mémoire d’un branchement est déjà connue, car le plus souvent inscrite dans l’instruction. C’est le cas le plus simple. Le second, indirect, reflète le cas où l’adresse n’est pas connue, par exemple parce qu’elle n’est pas constante ou qu’elle est inconnue à la compilation.

Il existe des mécanismes de prédiction pour les deux types de branchement. Sur les processeurs récents, on trouve ainsi des prédicteurs de branches indirectes. L’opération étant beaucoup plus complexe, ces prédictions fonctionnent seulement dans certains cas, notamment quand l’adresse de destination change de manière cyclique. Le tampon (buffer) associé peut stocker plusieurs adresses de destination par branchement, ainsi que d’autres informations pour mieux prédire la bonne adresse.

Des branches indirectes si désirables

Ces branches indirectes ont été au cœur des attaques dites Spectre v2, basée sur la faille CVE-2017-5715. L’attaque se fait sur les instructions transitoires et vise à injecter une cible dans la branche spéculée. En clair, un pirate peut essayer d’introduire dans une branche indirecte un élément indiquant au processeur que l’adresse pointée est la bonne. Pour le pirate, le jeu consiste alors à faire envoyer les instructions – et les données liées – vers l’adresse mémoire qui l’arrange.

Pour protéger les branches indirectes, Intel a introduit un mécanisme nommé IBPB, ou barrière prédictive de branche indirecte. Ce mécanisme « établit une barrière empêchant les logiciels exécutés avant la barrière de contrôler les cibles prédites des branches indirectes exécutées après la barrière sur le même processeur logique ». Il permet ainsi d’atténuer les risques d’injection de cible de branche.

Des chercheurs de l’École polytechnique fédérale de Zurich ont cependant trouvé un bug dans la microarchitecture des processeurs Intel et AMD, ce dernier ayant, lui aussi, une fonction de ce type. Exploitée, la faille peut permettre de contourner entièrement l’IBPB et permet de nouveau l’injection de cible de branche. Les chercheurs ont montré qu’une attaque Spectre basée sur ce bug peut être menée sur les processeurs Core de 12^e, 13^e et 14^e générations, ainsi que les Xeon de 5^e et 6^e générations.

Des correctifs déjà disponibles, quid de la dangerosité ?

Dans le document [PDF] expliquant la découverte et leurs procédés, les chercheurs indiquent qu'Intel et AMD ont été informés en juin dernier. Les deux entreprises ont confirmé le problème, qui était cependant déjà connu et corrigé. Chez Intel, il s'agissait d'un bulletin de sécurité publié en mars. Une mise à jour du microcode des processeurs concernés avait été ensuite publiée sur le GitHub de l'entreprise. Lorsque les chercheurs ont mené leurs travaux sur Ubuntu, le correctif n'avait pas encore été déployé (il l'a été depuis).

Concernant AMD, le problème avait été détecté il y a deux ans, le bulletin ayant été publié en novembre 2022. Les chercheurs précisent qu'AMD suit la faille depuis. Dans le bulletin, on peut lire qu'AMD considère qu'il s'agit avant tout d'un bug logiciel spécifique à chaque système d'exploitation. Les distributions Linux et Windows ont reçu des correctifs en ce sens.

Dans les deux cas, les chercheurs pensent pouvoir améliorer ces correctifs. Ils indiquent être en contact avec les mainteneurs du noyau Linux en vue de fusionner leur proposition de correction. Ils ajoutent qu'ils mettront à disposition le code source de leurs expériences sur la page de présentation de leurs travaux, sans précision sur les délais.

La découverte rappelle quoi qu'il en soit la récente colère de Linus Torvalds sur l’avalanche de correctifs que les fabricants de matériel réclament aux mainteneurs du noyau Linux pour atténuer des problèmes de sécurité. Il a ainsi indiqué en avoir « marre » des bugs dans le matériel d’Intel et AMD et a fustigé « des attaques complètement théoriques qui n'ont jamais été utilisées en pratique ».

• Linus Torvalds en a « marre » du matériel buggé d’Intel et AMD

Peut-être parce qu’ils avaient connaissance de cette volée de bois vert, les chercheurs affirment – en gras dans le texte – qu’ils sont les « premiers à montrer une fuite Spectre inter-processus pratique de bout en bout », en opposition à ce qu’ils qualifient d’« exemples irréalistes ».