Intel, des failles

Date Auteur/auteure Catégories
12/01/2018 Janiko Actualités, Vulnérabilités
Laisser un commentaire

Jeu de mot facile, mais les petits gars d’Intel nous gâtent avec Spectre & Meltdown ! Heureusement, la NSA ne connaissait pas ces failles1. Nous voilà rassurés.

C’est grave, docteur ?

On est en présence des failles les plus graves et les plus importantes de l’histoire de l’informatique. Cette affirmation n’est pas qu’une figure de style, car elles se distinguent par plusieurs caractéristiques :

  • Elles sont anciennes (elles existeraient depuis 1995) ;
  • Elles touchent les systèmes en profondeur puisqu’elles sont le résultat d’une vulnérabilité matérielle ;
  • Elles touchent la quasi-totalité des micro-processeurs, à quelques rares exceptions près ;
  • Les conséquences sont extrêmement sérieuses puisqu’elles permettent l’accès à quasiment toutes les données d’un système, voire des attaques de type VM Escape chez les fournisseurs de ressources mutualisées (cloud)..

On ne verra peut-être pas d’attaques en nombre, mais vu les conséquences possibles, il sera impossible de ne pas mettre en place des mécanismes d’atténuation (contre-mesures) de ces failles. Et il faudra en tenir compte tant que le matériel ne sera pas revu et corrigé, ce que ne se fera pas instantanément : il faudra à la fois que tous les nouveaux processeurs soient modifiés (ça serait le cas2), mais aussi que les anciens disparaissent, ce qui ne se fera que dans plusieurs années. Il est clair que les conséquences de ces failles vont hanter le milieu informatique pendant longtemps3.

On voit aussi qu’Intel a revalorisé son programme de chasse aux bogues4 (et aux failles de sécurité), ce qui montre bien l’inquiétude du fondeur face à d’éventuelles exploitations des failles de ce type.

Essayons de les comprendre, car le moins que l’on puisse dire est que la communication est chaotique5. Tout comme la diffusion (et l’efficacité) des premiers correctifs6. L’explication la plus claire que j’ai pu trouver provient du site stratechery.com.

L’idée

Les processeurs modernes doivent aller de plus en plus vite (bien que la course à la performance me semble de plus en plus futile, voire nuisible : ça nous amène du big data et nous replonge dans l’intelligence artificielle). Parmi les techniques d’optimisation, l’exécution spéculative permet des gains substantiels dans certaines conditions, lorsqu’il est possible d’utiliser des ressources inutilisées d’un processeur ayant une architecture en pipeline, permettant l’exécution parallèle de plusieurs instructions. Le processeur exécute ainsi en avance des instructions dont on ne saura si elles doivent être exécutées qu’après avoir eu le résultat d’une autre exécution.

Exécuter du code en avance, ça peut coûter de l’énergie pour rien si on se rend compte que finalement il ne fallait pas exécuter le code. Côté performance, on ne gagnera rien non plus, mais on ne perdra rien. Par contre, si le processeur a misé sur le bon cheval : bingo ! Le code à exécuter aura donc déjà été exécuté.

Le principe est simple, il y a bien sûr pas mal de conditions et de contraintes pour que cela fonctionne, mais ça marche tant et si bien que la plupart des processeurs modernes (depuis 1995) utilisent cette technique d’une façon ou d’une autre.

Spectre et Meltdown sont des attaques par canal auxiliaire, c’est-à-dire qu’elles se basent sur l’observation des réactions du processeur dans certaines circonstances.

Ainsi, en réussissant à contrôler le processeur lors d’opérations d’exécution spéculative, on arrivera à lui faire faire des opérations par avance qui laisseront des traces dans le cache.

Même si après exécution les données lues sont effacées de la mémoire (car la spéculation risque fort d’être non pertinente) et restent inaccessibles, le cache processeur en conservera une trace, par construction.

Meltdown

Cette vulnérabilité permet à un programme n’ayant qu’un niveau de privilège faible de pouvoir lire n’importe quelle donnée dans le système concerné (plus précisément dans la mémoire du noyau)7, sous certaines conditions comme toujours.

Elle n’impacterait que certains processeurs Intel (principalement) et ARM. Quand je dis certains, c’est quasiment tous, vu la liste fournie par Intel8.

Spectre

Cette deuxième vulnérabilité, dont il existe deux variantes, concerne une gamme plus large de processeurs puisque les puces AMD seraient aussi touchées, ce qui été officiellement reconnu9 par le constructeur.

La variante 1 dite Bounds check bypass permet de lire du contenu mémoire en utilisant le mécanisme de prédiction grâce une astuce, forçant le processeur à charger en cache une zone qu’il n’aurait pas dû charger, en le trompant sur les bornes (limites) où il est censé être autorisé à lire. A l’exécution, le contenu mémoire restera inaccessible mais le résultat sera stocké en cache.

La variante 2 dite Branch Target Injection est la plus vicieuse. Le but de la prédiction dans ce cas est de deviner l’adresse mémoire où le processeur devra exécuter sa prochaine instruction10.

Exploitation des failles

D’après ce que je sais, l’exploitation n’est pas si triviale que cela. Au 11 janvier 2018, on considère qu’une exploitation n’est possible que localement11 sur un système maîtrisé par l’attaquant. Toutefois, début février 2018, on commençait à apercevoir des premiers exemples d’exploitation de ces failles, mais sans charge utile, ce qui tendrait à prouver qu’il s’agit de chercheurs essayant de mieux comprendre les mécanismes d’une future attaque, en vue de s’en protéger, ou de professionnels qui testent leur exposition à la menace12. Au fil du temps, on peut s’attendre à voir surgir de nouvelles techniques13 et exploitations14 de ces failles.

Exemple de code d’exploitation de Spectre

Le code en C fourni par les découvreurs de Spectre, et qui fait environ 100 lignes, n’est pas à proprement parler une exploitation de la faille. Il s’agit seulement d’un test permettant de savoir si la vulnérabilité est présente, sans indiquer si les contre-mesures nécessaires sont appliquées et efficaces. Comme la faille est matérielle, on ne la comblera pas logiciellement : on empêchera seulement son exploitation.

Exemple de code de test de vulnérabilité pour Meltdown

Détection d’exposition

Corrections et contre-mesures

Il ne faut s’attendre à aucun miracle : ces failles seront à surveiller longtemps, et les contre-mesures devront être déployées aussi longtemps que les processeurs vulnérables seront utilisés, c’est-à-dire… longtemps. Intel n’a proposé un changement d’architecture qu’en mars, ce qui est normal le temps d’étudier sérieusement la question15. Avec une mise en production au 2e semestre 2018. Et en priorité sur certains processeurs (Xeon), ceux utilisés pour les fournisseurs cloud15 ; le renouvellement de l’ensemble de la gamme ne peut être qu’un processus à long terme.

Meltdown

C’est la moins pire des failles : on peut la corriger de façon logicielle, et les patchs sont déployés depuis quelques temps. Pour Linux, cela s’appuie sur le mécanisme d’isolation de page PTI (Page Table Isolation). Windows et MacOS ont aussi déployé des mécanismes similaires. Ils sont relativement coûteux en charge CPU, car des opérations (mapping mémoire ?) doivent être refaites à chaque appel système.

Spectre

La théorie

Pour la variante 1, le problème étant lié à un contrôle effectué par le processeur lors d’une tentative de prédiction, la solution sera purement et simplement d’interdire la prédiction (ce qui est une option à la disposition des compilateurs). En conséquence, il faut… tout recompiler ! En corollaire, interdire la prédiction implique de ne plus tenter de gagner du temps sur l’exécution, d’où un ralentissement obligatoire des programmes.

Pour la variante 2, une solution de recompilation comme dans la variante 1 pourrait a priori résoudre le problème dans certains cas, en utilisant une construction de type Retpoline. Mais d’autres scenarios nécessiteraient une correction beaucoup plus en profondeur :

  • Le firmware serait à modifier pour que le noyau du système d’exploitation puisse contrôler les mécanismes de prédictions ;
  • Le noyau lui-même serait à modifier (je suppose pour tirer partie de ce contrôle ainsi que pour éviter d’être lui-même sujet de manipulation des prédictions).

La réalité

C’est une autre paire de manches, d’autant que la correction ne sera que partielle ou palliative, et sa nature et son efficacité dépendra du processeur concerné. Il y a aussi de grosses interrogations sur la dégradation des performances16171819 induite par ces patchs. Au mieux, cela s’améliorera avec le temps et la qualité des patchs, au pire ça sera irrémédiable.

De plus, vu la panique en cours et la course au patch, certains arrivent trop tôt ou pas encore fiables à 100%, et au 15 janvier la situation reste bancale : un patch Intel a même créé des effets de bord de type redémarrage intempestif20 et a décidé d’interrompre sa diffusion21, temporairement. Et maintenant Red Hat vient d’indiquer qu’ils arrêtaient de patcher une des variantes, estimant que cela ne relève que du fabricant du processeur ou du constructeur (intégrateur) du matériel22. On tourne en rond.

Intel publie régulièrement un état des mises-à-jour, et le moins que l’on puisse dire, c’est qu’il est difficile d’y retrouver ses petits. Le firmware de certains modèles sont même abandonnés23, alors qu’une version beta (de test) existait, sans qu’on n’ait beaucoup d’explications sur ces abandons24, ce qui rend les feuilles de routes purement indicatives puisqu’elles peuvent évoluer !

Corrections partielles

Certaines attaques comme GLitch, basées sur des canaux auxiliaires) peuvent être atténuées par logiciel ; les navigateurs web étant en première ligne comme porte d’entrée vers leur hôte, les principaux éditeurs ont déployés des patches diminuant la précision des timers(il en faut par exemple pour WebGL), rendant ainsi l’inférence difficile (laquelle nécessitait des mesures très précises). Mais cela reste dépendant des technologies mises en oeuvre, et la feuille de route de Wasm (WebAssembly) propose des évolutions permettant à nouveau l’écoute et l’inférence d’informations.

Du côté d’AMD

Les processeurs AMD étant aussi touchés par la variante 225, AMD a dû aussi retrousser les manches et chasser le fantôme. Moins exposé médiatiquement pour cette vulnérabilité, le fondeur a mis tout de même plusieurs mois26 avant de proposer une solution. Celle repose sur des pré-requis précis et qui ne sont pas toujours facile à mettre en oeuvre à grande échelle dans une entreprise :

  • Avoir la dernière version de Windows 10 et qu’elle soit à jour ! Rien de moins ! La correction pour Windows Server 2016 arrivera dans un 2e temps.
  • Utiliser un CPU datant au plus de la ligne Bulldozer (2011) .
  • Mettre à jour le firmware des cartes-mères concernées.

Pas de grosse différence avec Intel, hélas : cela signifie qu’il faut des opérations complexes et complètes pour être protégé.

Dans le futur

Ces vulnérabilités vont faire bouger les choses, et nul doute que plusieurs équipes de recherche vont tenter de trouver des solutions pour améliorer les choses, à défaut de pouvoir tout prévoir. Une refonte du design s’impose mais ça n’est pas une mince affaire, autant du point de vue théorique que du point de vue industriel ; des chercheurs ont posé des bases, reste à savoir si ça suffira et si on pourra industrialiser.

Des impacts structurants

Pour prévenir ce type de vulnérabilité, il faut parfois revoir de fond en comble les bases des architectures utilisées, comme dans le cas des hyperviseurs de machines virtuelles : la version 4.11 de Xen27, outil très largement utilisé et également à la base des grosses infrastructures cloud, a été remaniée en prenant en compte les failles du type de Spectre et Meltdown.

Sources externes

Sites officiels

Voir aussi

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *