Spectre (vulnérabilité)

La vulnérabilité Spectre a été découverte indépendamment par des chercheurs du Project Zero et par des chercheurs collaborant avec Paul Kocher. Un rapport a été rendu public le 3 janvier 2018, en même temps qu'un autre, traitant d'une vulnérabilité, nommée Meltdown.

Spectre est une vulnérabilité qui permet de faire en sorte qu'un programme accède à des emplacements arbitraires de la mémoire vive allouées à celui-ci. Un attaquant peut lire le contenu de la mémoire accédée ainsi, ce qui peut potentiellement lui permettre d'obtenir des données sensibles.

Au lieu d'une seule vulnérabilité, facile à résoudre, le rapport sur Spectre[4] décrit une classe de vulnérabilités potentielles. Elles sont toutes basées sur l'exploitation des effets secondaires de l'exécution spéculative, un moyen de masquer la latence de la mémoire et donc d'accroître la vitesse d'exécution des microprocesseurs modernes. Plus précisément, Spectre concerne la prédiction de branchement, qui est un aspect de l'exécution spéculative. Contrairement à Meltdown, à laquelle Spectre est associée du fait de la simultanéité de leurs découvertes, Spectre ne s'appuie pas sur une fonction spécifique de la gestion et du système de protection de la mémoire d'un seul processeur, mais est un concept plus général. La vulnérabilité Meltdown, quant à elle, peut être considérée comme un sous-cas particulièrement simple et efficace à mettre en place de Spectre.

Le point de départ de ce rapport est celui d'une attaque temporelle par canal auxiliaire, appliquée au système de prédiction de branche des microprocesseurs modernes à exécution atemporelle. Alors qu'au niveau architectural, illustré dans la documentation des processeurs, toute erreur de prédiction est censée être annulée après qu'elle a été constatée, l'exécution spéculative peut cependant laisser des effets secondaires. En effet, les résultats des lignes de codes exécutées en avance "au cas où", peuvent rester stockés dans le cache, permettant ainsi a un programme malveillant de récupérer ces données. Celles-ci peuvent alors affecter plus tard les aspects prétendument non-fonctionnels de l'environnement informatique. Si de tels effets secondaires—comprenant, mais non limités à, la temporisation de la mémoire—sont visibles par un programme malveillant, et peuvent être créés de sorte qu'ils se rapportent à des données sensibles détenues par le processus victime, il peut en résulter un dévoilement de ces données sensibles. Cela peut se produire en dépit du fait que les systèmes de sécurité formels au niveau architectural fonctionnent comme prévu; en effet, des optimisations micro-architecturales de l'exécution d'un code peuvent aboutir à une fuite d'informations non essentielles à son bon fonctionnement.

Le rapport sur Spectre décrit l'attaque en essentiellement quatre étapes :

1. Tout d'abord, il montre que la logique de la prédiction de branche dans les processeurs modernes peut fiablement être amenée à toucher juste ou à échouer, selon le fonctionnement interne d'un programme malveillant potentiel.
2. Ensuite, il montre que la différence, qui en résulte, entre les réussites et les échecs du cache peut être chronométrée avec fiabilité, de manière que ce qui aurait dû être une simple différence non-fonctionnelle puisse en fait être traduite en un canal masqué, qui extrait des informations à partir du fonctionnement interne d'un autre processus.
3. Enfin, le rapport synthétise les résultats par des exploits de Return-Oriented Programming (ROP) et par d'autres concepts qui s'expriment en un simple programme didactique et également en un fragment de JavaScript exécuté par un navigateur à sandboxes; dans les deux cas, l'ensemble de l'espace d'adresses du processus victime est rendu visible en exploitant simplement l'exécution spéculative de branches conditionnelles, que ce soit avec un code généré par un compilateur standard ou avec l'interprétation d'un code JavaScript comme on en trouve dans un navigateur d'aujourd'hui. Pour accéder à des zones où des données sont touchées par la spéculation, mais inaccessibles autrement, l'idée de base est de rechercher du code existant, de manipuler le processeur dans un état où l'exécution spéculative pourra toucher ces données, puis de chronométrer les effets secondaires du processeur, qui sont plus rapides si son système de prefetch, désormais préparé, a en effet chargé une ligne de cache.
4. Enfin, le rapport se termine par une généralisation de l'attaque à tout état de non-fonctionnement du processus victime. Il évoque même brièvement des états de non fonctionnement très peu évidents, tels que la latence du bus d'arbitrage.

La différence de base entre Spectre et Meltdown est que cette dernière s'appuie sur des caractéristiques spécifiques des processeurs Intel modernes : les processeurs peuvent être amenés à spéculer sur des données protégées du système, et être conduits à une prise en charge garantie de l'exception de sécurité s'y rapportant. Le montage de Spectre a une approche plus statistique: il fait de son mieux pour préparer le système de prédiction de branche d'un processeur d'une certaine manière, et utilise du code pouvant être trouvé (ou pas) dans des bibliothèques existantes pour faire essentiellement la même chose.

Les spécificités respectives des deux vulnérabilités peuvent être décrites avec les mots du rapport sur Meltdown : « Meltdown se distingue de Spectre de plusieurs façons, en particulier, Spectre nécessite une adaptation à l'environnement logiciel du processus victime, il s'applique plus largement au processeur et n'est pas atténué par KAISER[5]. »

À compter de 2018, presque tous les systèmes informatiques sont affectés par Spectre, y compris les ordinateurs de bureau, portables et appareils mobiles. Plus précisément, Spectre a été déclaré fonctionnel sur des processeurs Intel, AMD, et ARM[6] - [7]. Intel a répondu aux vulnérabilités de sécurité avec une déclaration officielle[8]. Selon une déclaration faite par AMD, la vulnérabilité à la seconde variante de Spectre n'a pas été montrée sur les processeurs AMD et le « risque d'exploitation [serait] quasi nul » en raison de différences dans l'architecture AMD.

À l'heure actuelle, Spectre n'a été rendu fonctionnel qu'entre programmes de niveau utilisateur, mais il semble probable que l'attaque puisse être développée davantage. Bien que plus difficile à utiliser correctement que Meltdown, Spectre peut être beaucoup plus difficile à contrer en raison de sa généralité. Le rapport original envisage même que des changements importants dans l'architecture des microprocesseurs puissent être nécessaires pour éliminer le problème.

En outre, Spectre peut potentiellement avoir un impact plus important sur les fournisseurs de cloud que Meltdown. Alors que Meltdown permet à des applications non autorisées de lire des zones de mémoire « privilégiées » pour obtenir des données sensibles à partir de processus en cours d'exécution sur le même serveur cloud, Spectre peut permettre à des programmes malveillants d'introduire un hyperviseur qui transmettrait des données à un système invité en cours d'exécution et ce à un niveau supérieur[9].

Puisque Spectre représente une classe entière d'attaques, on ne peut vraisemblablement pas créer un correctif unique. Alors que le travail est déjà en cours pour traiter certains cas particuliers de la vulnérabilité, le site web de référence consacré à Spectre et Meltdown rapporte que : « Comme [Spectre] n'est pas facile à contrer, il va nous hanter pendant longtemps. »

D'après les chercheurs, il sera probablement impossible de détecter une attaque utilisant cette vulnérabilité, puisqu'elle ne laisse aucune trace directe[10].

Les protections contre les vulnérabilités Spectre se composent de plusieurs parties[11] :

• introduction d'instructions prohibant l'exécution spéculative dans le code machine produit (typiquement LFENCE pour architectures x86)
• introduction de retpolines (construction permettant d’empêcher le processeur de spéculer)
• utilisation de l'IBRS des processeurs Intel qui permet d'inhiber la spéculation également.

La première solution permet de se protéger de la variante 1 de Spectre, tandis que les deux suivantes permettent de contrer la seconde variante. L'IBRS est tout de même vivement critiqué car affectant les performances de manière significative (plusieurs pourcents). Les retpolines ne sont pas une solution idéale non plus car ils n’inhibent pas la spéculation pour les processeurs les plus récents (génération Skylake et ultérieures).

• Meltdown (vulnérabilité)

• (en) Site officiel de Meltdown et Spectre
• (en) Rapport officiel sur Spectre
• (en) Article du ProjectZero