Spectre/Meltdown : de nouvelles failles dans les processeurs,

Gratuit
Recevez toutes nos informations et actualités par Email.
Entrez votre adresse email :

Elles permettent de lire les registres internes, la mémoire kernel et celle de l’hôte

Le 22 mai 2018, par benjani13, Membre expérimenté
En début d’année, plusieurs vulnérabilités affectant les processeurs depuis plusieurs années ont été dévoilées. Au nombre de trois « variantes », ces vulnérabilités exploitent des mécanismes internes aux processeurs. Elles sont souvent regroupées sous le nom de Spectre pour les variantes 1 et 2, et Meltdown pour la variante 3. Elles permettent de lire la mémoire kernel en tant que simple utilisateur, ou bien d’aller lire la mémoire de l’hôte depuis une machine virtuelle.
Hier, les détails de deux nouvelles variantes (3a, et 4) ont été publiés. Elles abusent des mécanismes d’exécution spéculative pour (3a) lire des registres internes des processeurs et (4) lire des données sensibles en mémoire.

Retour sur Spectre et Meltdown

Meltdown et Spectre abusent de certains mécanismes d’optimisations implémentés dans les processeurs, notamment celui dit d’exécution spéculative. Ce mécanisme permet au processeur d’exécuter certaines instructions en avance de phase afin de gagner du temps. Le processeur peut par exemple (variante 1) exécuter une série d’instructions se trouvant après une condition, sans savoir à ce moment-là si la condition sera remplie ou non. Si la condition n’est en fait pas remplie, le processeur revient à son état précédent l’exécution du bloc et tout se passe comme si rien ne s’était passé. Or il a été démontré que des traces de l’exécution erronée du bloc peuvent être retrouvées dans le cache du processeur, celui-ci n’étant pas remis dans son état original.

Ces vulnérabilités ont dû être patchées soit par la mise à jour du microcode des processeurs affectés, soit par la mise en place de mécanismes de protection au sein des systèmes d’exploitation. Néanmoins certaines de ces protections impliquent des baisses de performances, et certains patchs n’ont pas été totalement efficaces et ont subi plusieurs itérations avant d’être matures. AMD et Intel ont aussi pris en compte ces failles dans leurs futures architectures afin de livrer de nouveaux processeurs non vulnérables. Les fournisseurs d’infrastructure cloud, particulièrement impactés par ces vulnérabilités, ont aussi dû rapidement réagir en déployant des correctifs sur leurs serveurs. Aussi, des compilateurs ont implémenté des mécanismes pour contrer certaines variantes, et des guides de développement ont été publiés afin d’écrire du code moins sensible à ces attaques. Encore plus inattendu, les navigateurs web ont baissé la précision des timers JavaScript afin d’empêcher l’exploitation de ces failles depuis du code JavaScript.

Meltdown et Spectre ont donc été des vulnérabilités assez hors du commun, tant par le fait qu’elles attaquent les processeurs eux-mêmes, par leur impact très large (tous les OS étant concernés), et le travail qui a été nécessaire pour les corriger. En effet c’est toute l’industrie (fabricants de CPU, développeurs d’OS, fournisseurs d’infrastructure) qui a dû se coordonner, en secret, pendant plusieurs mois afin de fournir une réponse adaptée.

Nouvelles vulnérabilités

Il était pressenti que les chercheurs ayant découvert Meltdown et Spectre venaient d’ouvrir une porte sur tout un champ d’études encore très peu exploré et que d’autres variantes seraient découvertes. Le 21 mai 2018, deux nouvelles vulnérabilités mettant en jeu l’exécution spéculative ont été dévoilées.

Variante 3a : Rogue System Register Read (CVE-2018-3640)

Cette variante abuse des mécanismes d’exécution spéculative afin de récupérer les valeurs de certains registres internes des processeurs. Quelques données sensibles peuvent être récupérées suivant le processeur visé comme l’adresse physique de certaines structures de données et l’adresse de certains points d’entrée du kernel. Ces informations peuvent permettre d’outrepasser la protection KASLR (Kernel Address Space Randomization) en place dans les systèmes d’exploitation récents.

KASLR rend l’adresse de base du kernel (et donc de tout son contenu) aléatoire. Ainsi, si un attaquant exploite par exemple un driver kernel et se retrouve à pouvoir exécuter du code avec les mêmes droits, il ne pourra pas manipuler les informations du kernel, car il ne connaitra pas leurs adresses. Cette vulnérabilité peut paraitre minime mais réussir à contourner KASLR est une étape presque indispensable aujourd’hui pour réussir un exploit kernel.

Variante 4 : Spéculative store bypass (CVE-2018-3639)

Cette vulnérabilité abuse d’un mécanisme d’optimisation dans la lecture de la mémoire appelé « memory disambiguation ». En effet, les processeurs tentent de gagner du temps en réorganisant l’ordre des instructions à la volée. Si l’instruction 1 est jugée lente (lecture d’une donnée en RAM), le processeur peut démarrer l’exécution de l’instruction 2 si celle-ci est jugée rapide (lecture dans le cache). Bien sûr, pour que ce mécanisme se déclenche, il ne faut pas que l’instruction 2 dépende de l’instruction 1. Si l’instruction 1 écrit une valeur à l’adresse 3000 et que l’instruction 2 lit la valeur à l’adresse 3000, l’instruction 2 ne pourra pas être exécutée avant la 1. Ce mécanisme s’applique à plus que deux instructions bien sûr. Si l’instruction 2 consiste à charger une valeur, puis une troisième instruction incrémente cette valeur, c’est l’ensemble instructions 2 et 3 qui peut être exécuté avant l’instruction 1.
Il peut néanmoins arriver que le processeur se trompe, et qu’il se rende compte après coup que la seconde instruction était bien dépendante de la première. Dans ce cas-là, une fois que l’instruction 1 est terminée, le processeur revient en arrière et réexécute l’instruction 2 (et plus si besoin).

Tout comme les autres variantes, ce retour en arrière peut laisser des traces exploitables après coup, notamment dans le cache. En abusant de ce mécanisme, il est donc possible de tenter de faire charger des données sensibles et de les lire dans le cache, même si le processeur se rend compte de l’erreur et a effectué le retour en arrière.
Microsoft a annoncé que les patchs déjà publiés pour Windows corrigent une partie des scénarios exploitables avec cette variante. Microsoft précise qu’un travail est en cours avec les fabricants de CPU afin d’évaluer les solutions à implémenter au niveau des processeurs (firmware ou micro code).

En attendant d’autres variantes

Les recherches sur les vulnérabilités liées aux différents mécanismes d’exécution spéculatives se poursuivent et d’autres variantes seront sans doute découvertes. Bien que ces attaques peuvent paraitre peu signifiantes pour certains, il ne faut pas les sous-estimer, et le fait qu’elles forcent de nombreux acteurs de l’industrie à réagir démontre qu’il y a du souci à se faire. Cependant, ces failles de bas niveau sont difficiles à comprendre, et il n’est de fait pas aisé d’estimer l’impact de chaque variante. De plus les impacts de performances de certains patchs ont pu faire hésiter à les déployer. Il faudra néanmoins rester sur le qui-vive et être prêt à patcher dès que nécessaire, car c’est un nouveau pan de recherche qui s’est ouvert et nous pourrions encore être très surpris par ce qu’il se passe dans nos processeurs.

source: developpez.com
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »
  • »