Spectre/Meltdown : de nouvelles failles dans les processeurs,
Elles permettent de lire les registres internes, la mémoire kernel et celle de l'hôte

Le , par benjani13, Membre chevronné
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.

Sources et lectures complémentaires



Et vous ?

Que pensez-vous de ces nouvelles failles sur les processeurs ?

Voir aussi

Vulnérabilités Meltdown et Spectre : Intel devrait livrer ses premiers processeurs dotés de protections intégrées plus tard cette année

Vulnérabilité Spectre : Google publie une nouvelle technique de mitigation, elle introduirait un impact négligeable sur les performances des machines

Vulnérabilités Meltdown et Spectre : état des lieux des navigateurs, Chrome, Mozilla et Edge face au vecteur d'exploitation JavaScript


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de - https://www.developpez.com
le 23/05/2018 à 12:26
Rien, c'est pas cela qui fera toutes les entreprises et gouvernements utiliser le " bouton d'arrêt d'urgence ". (stop économique/financier et autres traitements)
Je pense que la crainte que les " extraterrestres " prennent le contrôle via une IA ou autre méthode n'est pas fondé.
Avatar de LSMetag LSMetag - Expert confirmé https://www.developpez.com
le 23/05/2018 à 14:57
Qu'évidemment Intel continue de pleurer.

Car ces failles sont comme les autres, vecteur de contrôle, d'injection de code malveillant, de récupération de données personnelles ou sensibles,... Ca peut être un outil d'espionnage, industriel entre autre. Il y a des génies partout dans le monde prêts à les exploiter. Donc ça me tient à coeur.
Avatar de - https://www.developpez.com
le 23/05/2018 à 15:10
Citation Envoyé par LSMetag Voir le message
Ca peut être un outil d'espionnage, industriel entre autre. Il y a des génies partout dans le monde prêts à les exploiter. Donc ça me tient à coeur.
J'attend avec impatience la suite de l'actu. Surtout au sujet des cryptomonnaies. y a t-il un lien ?
Un virus ou cheval de troie à bien des façons " d'évoluer " sans avoir besoin de redémarrer.
Cela tient aussi à coeur mais peut-être pas de la même façon.

Bien complexe le monde dans lequel nous évoluons... L'introduction du libre arbitre hors servitude a été donnée avec le plein pouvoir.
Avatar de LSMetag LSMetag - Expert confirmé https://www.developpez.com
le 23/05/2018 à 15:38
Citation Envoyé par MikeRowSoft Voir le message
J'attend avec impatience la suite de l'actu. Surtout au sujet des cryptomonnaies. y a t-il un lien ?
Un virus ou cheval de troie à bien des façons " d'évoluer " sans avoir besoin de redémarrer.
Cela tient aussi à coeur mais peut-être pas de la même façon.

Bien complexe le monde dans lequel nous évoluons... L'introduction du libre arbitre hors servitude a été donnée avec le plein pouvoir.
On ne parle pas de l'évolution mais de la première intrusion. Car oui après tu peux mettre ça par exemple dans la mémoire ROM du bios ou équipements embarqués (ou autres), sur disque dur,...
Avatar de - https://www.developpez.com
le 23/05/2018 à 16:08
Citation Envoyé par LSMetag Voir le message
On ne parle pas de l'évolution mais de la première intrusion.
Je ne saurais pas identifier la volonté à faire cela.

Positif : J'ai eu un prof qui avant d'être prof faisait des petits boulots pour des boites. Récupérer le contrôle d'un serveur après qu'un administrateur ai été viré, etc.., a fait parti de ses activités "nocturnes". je pense pas qu'il ai été développeur.
Négatif : ... je ne me prononce pas ... mais celui qui l'a découvert (la possibilité d'intrusion) à surement éprouvé une forme de colère.

Au plus loin que je me souviens, j'ai jamais entendu parlé de l'informatique sans faille de sécurité logiciel et sans défaut de conception matériel.
Il y en a peut-être dans les automates industriels.

L'avion est encore parti des "systèmes" les plus fiables.
Je me demande bien comment les faussaires font ?
Avatar de dlandelle dlandelle - Membre du Club https://www.developpez.com
le 24/05/2018 à 15:45
Franchement, vu les gigaoctets de code de merde exécutés dessus, je ne vois pas bien ce qu'on peut récupérer avec ça.

Et puis les mises à jour qui font autant d'upload crypté que de download, cela me semble une beaucoup plus grosse menace pour la sécurité.

Désactiver les mises à jour, mettre un firewall, ça paraît plus efficace que d'avoir peur de ces menaces bidons ;-)
Avatar de pierre++ pierre++ - Membre actif https://www.developpez.com
le 24/05/2018 à 17:25
Ça me rappelle que dans les années 95 j'avais écris un petit programme en C qui explorait la mémoire du système ( windows 98, puis windows 98) à la recherche de la zone où était stockée la position des mines du jeu "Démineur". Histoire de ne pas sauter sur une bombe
Là c'est un peu plus subtile puisque c'est une exploration du cache du processeur, mais je doute que ce soit très compliqué pour un bricoleur de développer ça
Avatar de byrautor byrautor - Membre actif https://www.developpez.com
le 27/05/2018 à 11:34
Je ne me souviens pas que dans mon 6803 de Motorola qui fonctionnait avec des ROM on pouvait modifier mon programme.
sa mise à jour (mécanique) avec des EPROM ne risquait rien.
L'homme n'est ni ange ni bête, et le malheur veut que qui veut faire l'ange fait la bête. S'il se vante, je l'abaisse ; s'il s'abaisse, je le vante ; et le contredis toujours, jusqu'à ce qu'il comprenne qu'il est un monstre incompréhensible. Que l'homme maintenant s'estime à son prix.

Avatar de benjani13 benjani13 - Membre chevronné https://www.developpez.com
le 28/05/2018 à 11:54
Citation Envoyé par dlandelle Voir le message
Désactiver les mises à jour, mettre un firewall, ça paraît plus efficace que d'avoir peur de ces menaces bidons ;-)
- Désactiver les mises à jour? Non. Voyez ce qu'à donné le manque applications des mises à jour quand le virus WannaCry a frappé.
- Mettre un firewall? Oui. Mais ça ne protège pas de tout, loin de là.
- Des menaces bidons? Soyons sérieux, ces vulnérabilités ont des impacts démontrés. Que votre PC personnel sois touché par une de ces vulnérabilités, il y a peu de chance. Ces attaques sont difficiles, extrêmement dépendantes de l'OS et du processeur (donc il faut faire du cas par cas). Votre PC personnel n'est pas une cible assez intéressante pour y mettre ces moyens. Les cibles de ces attaques seraient principalement les fournisseurs de cloud et d'autres infrastructures du type.

Citation Envoyé par pierre++ Voir le message
Ça me rappelle que dans les années 95 j'avais écris un petit programme en C qui explorait la mémoire du système ( windows 98, puis windows 98) à la recherche de la zone où était stockée la position des mines du jeu "Démineur". Histoire de ne pas sauter sur une bombe
Là c'est un peu plus subtile puisque c'est une exploration du cache du processeur, mais je doute que ce soit très compliqué pour un bricoleur de développer ça
Effectivement c'est plus subtile car, contrairement à la RAM, le cache ne peut être accédé directement. On ne peut pas aller demander à lire la case xxx dans le cache. Là il faut trouver des astuces pour, par déduction, obtenir des valeurs dans le cache. Dans le cas de spectre cela marche comme cela:
- On vise à obtenir la valeur à l'adresse X dans la RAM sans la lire directement
- On charge la donnée à l'adresse X dans un registre du processeur (on a pas le droit de le faire, mais l’exécution spéculatif va le faire tout de même)
- Si le dernier bit de la valeur à l'adresse X vaut 1, on charge une variable A qui correspond à une adresse Y dans la RAM.
- Sinon (le dernier bit de la valeur à l'adresse X vaut 0), on charge une variable B qui correspond à une adresse Z dans la RAM.

Après tout ça, la variable qui aura été chargé (A ou B), aura sa valeur dans le cache. On procède ensuite comme suit:
- On lance un timer 1
- On charge la variable A
- On mesure le temps écoulé
- On lance un timer 2
- On charge la variable B
- On mesure le temps écoulé

Et on analyse:
- Si le chargement de A est plus rapide, donc c'est A qui a été chargé tout à l'heure. Donc la condition "est-ce que le dernier bit de la donnée à l'adresse X vaut 1" était vrai.
- Sinon, B est plus rapide et donc le dernier bits vaut 0.

Et on recommence le processus pour chaque bits de la donnée à l'adresse X, et on obtient sa valeur sans jamais l'avoir lu directement, uniquement en inférant avec le comportement du cache.
Avatar de dlandelle dlandelle - Membre du Club https://www.developpez.com
le 08/06/2018 à 15:53
Citation Envoyé par benjani13 Voir le message
Soyons sérieux, ces vulnérabilités ont des impacts démontrés ... Votre PC personnel n'est pas une cible assez intéressante
Que vous soyez croyant en wanacry n'est pas un argument !
Si vous voulez convaincre, donnez au moins un programme de démo, sinon c'est de la religion ;-)

Vous me jugez sans me connaître, ce n'est pas correct.

Citation Envoyé par benjani13 Voir le message
on recommence le processus pour chaque bits de la donnée à l'adresse X
Un seul bit à la fois ? vous êtes vraiment sûr de ce que vous affirmez ?
La lecture d'un mot mémoire (aligné) est une instruction indivisible, si vous avez un bit, vous avez le mot, non ?
Pourquoi un seul bit, pourquoi le dernier ???
Chaque accès mémoire, programme ou data, modifie le cache aussi, vous en tenez compte ?
Avec 2 timers, et 3 cases mémoire X Y Z, même si ne n'ai pas bien compris à quoi servent les 2 variables supplémentaires Y et Z ?
Pouvez-vous donner un exemple de code ? je comprendrai peut-être mieux.
Contacter le responsable de la rubrique Accueil