Intel, des failles

Jeu de mot facile, mais les petits gars d'Intel nous gâtent avec Spectre & Meltdown ! Heureusement, la NSA ne connaissait pas ces failles[1]. 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 cas[2]), 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 longtemps[3].

On voit aussi qu'Intel a revalorisé son programme de chasse aux bogues[4] (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 chaotique[5]. Tout comme la diffusion (et l'efficacité) des premiers correctifs[6]. 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 Intel[8].

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 reconnu[9] 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 instruction[7].

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 localement[10] 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 menace[11]. Au fil du temps, on peut s'attendre à voir surgir de nouvelles techniques[12] et exploitations[13] 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 question[14]. Avec une mise en production au 2e semestre 2018. Et en priorité sur certains processeurs (Xeon), ceux utilisés pour les fournisseurs cloud[15] ; 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 performances[16][17][18][19] 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 intempestif[20] et a décidé d'interrompre sa diffusion[21], 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ériel[22]. On tourne en rond.

Intel publie régulièrement un état des mises-à-jour[23], 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és[24], alors qu'une version beta (de test) existait, sans qu'on n'ait beaucoup d'explications sur ces abandons[25], ce qui rend les feuilles de routes[23][26] 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 2[27], 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 mois[28] 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 Xen[29], 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

Références

  1. « La NSA est catégorique : elle ne connaissait pas les failles Meltdown et Spectre dans les processeurs Intel », sur numerama.com, (consulté le 11 janvier 2018)
  2. « Intel change l'architecture de ses puces pour les protéger de Spectre et Meltdown », sur www.msn.com (consulté le 18 mars 2018)
  3. (en) « Spectre Will Haunt Us For a Long Time », sur The first stop for security news | Threatpost (consulté le 28 juillet 2018)
  4. (en) Lee Bell, « Intel ups bug bounty programme reward to $250,000 in light of Meltdown and Spectre », sur ITPro, (consulté le 16 février 2018)
  5. Laura Hautala, « AMD : Oui, Spectre affecte nos processeurs », sur ZDNet.fr, (consulté le 12 janvier 2018)
  6. « Meltdown et Spectre : des patchs aussi pour Ubuntu, mais... », sur ZDNet.fr, (consulté le 12 janvier 2018)
  7. 7,0 et 7,1 Thomas Soete, « Spectre et Meltdown : explication technique des 3 failles de sécurité et des mesures correctives (pour un public averti) », sur OVH Blog, (consulté le 12 avril 2018)
  8. (en) « Facts about The New Security Research Findings and Intel® Products », sur Intel, (consulté le 15 janvier 2018)
  9. (en) JP Mangalindan, « AMD CEO on chip security flaws: ‘We're absolutely all over this’ », sur Yahoo Finance, (consulté le 15 janvier 2018)
  10. (en) Ryan Smith, « Understanding Meltdown & Spectre », sur AnandTech, (consulté le 15 janvier 2018)
  11. Louis Adam, « Meltdown/Spectre : des POC laissent entrevoir les futurs malwares », sur ZDNet.fr, (consulté le 2 février 2018)
  12. (en) Thomas Claburn, « Hate to ruin your day, but... Boffins cook up fresh Meltdown, Spectre CPU design flaw exploits », sur The Register,
  13. (en) Caroline Trippe, Daniel Lustig, Margaret Martonosi, « MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols » [PDF], (arXiv 1802.03802)
  14. « Cascade Lake, la réponse d’Intel aux attaques Spectre », sur ZDNet.fr,
  15. « Cascade Lake, la réponse d’Intel aux attaques Spectre », sur ZDNet France (consulté le 5 avril 2018)
  16. (en) Simon Sharwood, « Meltdown/Spectre fixes made AWS CPUs cry, says SolarWinds », sur The Register,
  17. Jérôme Gianoli, « Windows et les patchs Meltdown et Spectre, Microsoft confirme une baisse des performances », sur GinjFo,
  18. Jérôme Gianoli, « Correctifs Meltdown et Spectre, quel est l’impact sur les performances des processeurs Intel ? Réponse », sur GinjFo,
  19. (en) Terry Myerson, « Understanding the performance impact of Spectre and Meltdown mitigations on Windows Systems », sur Microsoft,
  20. (en) Simon Sharwood, « Intel’s Meltdown fix freaked out some Broadwells, Haswells », sur The Register, (consulté le 15 janvier 2018)
  21. « Intel met en pause le déploiement du patch Spectre », sur Les Numériques,
  22. (en) Catalin Cimpanu, « Red Hat Will Revert Spectre Patches After Receiving Reports of Boot Issues », sur Bleeping Computer, (consulté le 22 janvier 2018)
  23. 23,0 et 23,1 (en) « Intel microcode revision guidance » [PDF], sur intel.com, (consulté le 24 février 2018)
  24. « Spectre/Meltdown : Intel abandonne les patchs pour certains processeurs », sur ZDNet France (consulté le 5 avril 2018)
  25. « La variante 2 du Spectre hantera les vieilles plateformes Intel à jamais », sur Le Comptoir du Hardware, (consulté le 12 avril 2018)
  26. (en) « Microcode Revision Guidance » [PDF], sur Intel,
  27. (en) « AMD64 Technology : Indirect branch control extension (white paper) » [PDF], sur AMD (consulté le 12 avril 2018)
  28. « Spectre : AMD patche ses puces sous Windows », sur Les Numériques, (consulté le 12 avril 2018)
  29. « Re-engineering de Xen : l'hyperviseur open-source totalement remodelé », sur ZDNet.fr,
Spectre.pngMeltdown.png