IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

422PARTAGES

23  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de emixam16
Membre chevronné https://www.developpez.com
Le 06/03/2019 à 14:45
D'un côté si il a fallu 20 ans pour trouver le problème, c'était pas si mal conçu que ça à la base.
Pas systématiquement.

Dans les cas de Spectre/Meltdown/Foreshadow/Spoiler, ces failles sont effectivement relativement balèzes (même si pas non plus exceptionnelles) et c'est compréhensible qu'elles aient mis du temps à être découvertes.

Mais des failles critiques, qui tiennent très longtemps dans le systèmes sont courantes. Voici deux exemples:
- La faille WinRar découverte récemment (https://www.developpez.com/actu/2479...-utilisateurs/) est très bête. Elle exploite une faille "bête" dans un format très peu utilisé (.ace). Et comme winrar ne prend pas en compte l'extension, en renommant simplement le fichier en .rar, je peux l'exploiter très facilement et compromettre une machine.
- L'idée derrière la faille HeartBleed était très basique aussi (principe expliqué en images par xkcd ici https://xkcd.com/1354/).

En résumé, qu'une faille n'ait été trouvé qu'après très longtemps ne veut pas dire que le logiciel était bien sécurisé... Juste qu'aucun chercheur en sécurité n'a regardé au bon endroit... Et vu le nombre d'endroits à regarder c'est compréhensible.
9  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 01/11/2019 à 22:38
@phil995511
Sauf que à ma connaissance pour mener ce type d'attaques il faut être physiquement présent sur une machine vulnérable dont les Bios / OS n'ont pas été patchés...
Tout le problème est là justement.
Les vulnérabilité découvertes dans les micro-archi Intel (et pour certaines même chez ARM/AMD) peuvent être exploités à "distances", puisqu'elles permettes de passer les barrières Mémoire/Processus mis en place par les OS pour empêcher les opérations d'écritures/lectures/exécutions sur une architecture à mémoire partagé.
Typiquement avec la bonne payload lancer sur un serveur cloud que ce soit dans un conteneur ou une VM, avec processeur Intel, il est possible de lire/écrire/exécuter des registres/buffers/instructions et leurs valeurs, sans que ce soit détectable.
De même une attaque par JS permettrait d'échapper à la sandbox mis en place par le navigateur est d'écouter en temps réelle tous ce qui passerait par le processeur.
Et ça, que la machine est été patché ou pas, puisque des dire même d'Intel, étant des bugs lié à la micro-architecture des processeurs, ce n'est pas "patchable".
La porté des attaques peut tout au plus être atténué, ce qui semble convenir à Intel ...moins à ses clients.

Intel de leur côté prétendent que la désactivation de l'Hyper Treading n'est pas nécessaire.
Tu m'étonne.
Tu voit une boite comme Intel venir expliquer à ses clients et leurs dires :
"Écouter, on s'est tromper il faudrait peut-être mieux désactiver l'HyperThreading sur nos processeurs en fin de compte.
Par contre vous allez perdre d'office 20% de performances et ne comptez pas sur un remboursement de notre part, même si c'est un vis cacher.
Parce qu'on à fait des erreurs OK, mais on ne va tout de même par rembourser tout le monde pour qu'ils aillent chez la concurrence".

Se mettraient-ils avec de telles affirmations potentiellement en porte à faux vis-à-vis de leurs clients au risque de les voir se retourner contre eux ?!
Là tu considère qu'Intel ne prend pas ses clients pour des pigeons, or ils démontrent tous les jours le contraire.
La preuve, ils continuent de vendre leurs processeurs/contrôleurs à des prix exorbitant, alors que ceux-ci sont toujours bugués et que les bios/UEFI des CM ne sont toujours pas systématiquement patchés en sortie d'usine (au bon vouloir des fabricants quoi ).
C'est un peu comme AMD qui demande à ses client de patcher une CM neuve pour pouvoir faire fonctionner leurs derniers Processeur "Compatible" .
Ça va 5 minute, mais ce n'est absolument pas normale.
Et quand une nouvelle faille apparait (ou qu'une fuite à lieu, parce que les Meltdown/Spectre c'est après 6 mois qu'on en a entendu parlé, alors qu'elles sont présentes dans tous les Processeurs Intel sortie depuis 95), leur premier réflexe a toujours été d'abord de le nier, puis d'en minimiser l'impact et enfin après un temps certain (pour ne pas dire un certain temps) de sortir des séries de patch bâclé qui font perdre X% de performances et qui finalement ne résolve rien puisque le problème est physique et ne peut être patché.

Finalement ils finissent par s'en sortir en promettant que la prochaine génération de processeurs sera exempt de failles, ce qui n'est pour l'instant toujours pas vrai.
Bref bel exemple de j'm'en bats les couillisme vis à vis de ses clients.

Au rythme auquel ils trouvent de nouvelles failles/vulnérabilités sur les CPU's ces derniers temps, si cela continue ainsi, on ne pourra bientôt plus rien faire de nos PC si ce n'est les recycler
C'est bien parce que l'on a pas vraiment le choix qu'ils ce permettent d'avoir ce comportement.
Si la masse de leurs clients avaient ne serait-ce qu'une architecture de replie, ils seraient plus avenant, or ce n'est pas le cas.
En l’état il n'existe aucunes architectures alternatives pour le grand publique.
L'industrie c'est orienté vers l'Intel x86 depuis l'IBM PC, finalement on va en subir les conséquences collectivement un jour ou l'autre.

En passant, j’attends encore les sanctions de l'Europe pour abus de position dominante d'Intel sur le x86 et divers autres IPs en leurs possessions.
9  0 
Avatar de benjani13
Membre extrêmement actif 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.
6  0 
Avatar de 23JFK
Membre expert https://www.developpez.com
Le 15/06/2018 à 21:10
De correctif en correctif, le fière i9 sera bientôt aussi efficace qu'un 8080 si cela continue.
6  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 13/12/2019 à 10:50
Ou, autrement dit : il faut déjà un accès quasi totale sur la machine pour pouvoir faire des mauvaises manipulations. Je pense que si quelqu'un à ring-0, il ne s'embêtera pas à compromettre la tension
Sauf à essayer de faire cramer le CPU par exemple.

Un accès "ring-0" et le niveau de privilège "NT authority" ...c'est la même chose ?
Non, le privilège NT authority correspond à des droits sous Windows. Il s'agit de comptes système avec des droits plus étendus que les comptes administrateurs, qui ne sont censés être utilsés que par les services Windows.

Le Ring 0 ne concerne que les CPU Intel/Amd. Le ring 0 étant le mode CPU avec le plus de privilèges, le ring 3 celui à moindre privilège (les ring 1 et 2 existent mais ne sont pas utilisés). Du code en Userland tournera en ring 3, du code Kernelland tournera en partie en ring 0 quand nécessaire. Le principe étant que le ring 0 restreint les accès matériel/mémoire/fonction CPU de modification de comportement pour le code en ring3. Quand un code en userland demande un accès qu'il n'a pas, l'OS va le gérer et lui attribuer ou non le droit (exemple, ajout de mémoire dans l'espace d'adressage pour un malloc : autorisé - accès à l'espace mémoire d'un autre processus : refus d'accès).

Les failles dont il est sujet ici évoque la possibilité d'accéder à des zones normalement accessibles qu'en ring0 par du code tournant en ring 3 par la mauvaise utilisation du cache par l’exécution spéculative. Les corrections effectuées sur les OS consistent à forcer l'invalidation des caches au moment opportun, ou de ne pas utiliser celui-ci. Voilà pourquoi ces patchs ont un impact sur les performances.

Les CPU Intel et AMD réagissent différemment car même si ils sont compatibles du point de vue code machine, brochage, ils ne sont pas câblés pareil à l’intérieur et ne font pas forcément exactement les mêmes choses pour arriver au même but. Le nombre d'attaques auxquelles les deux architectures sont sensibles est assez proche (il a été évoqué 5 pour Amd et 7 pour Intel). Et rien n'empêche de supposer que les CPU Amd peuvent être sensibles à des attaques auxquelles les CPU Intel ne le serait pas.

Un processeur non x86/Amd64 gèrera différemment avec par exemple un mode superviseur avec tous les droits et un mode utilisateur avec droits restreints. Un Windows 10 ARM n'aura donc pas de ring 0.

Mais pour moi le plus gros danger vient du Intel Management Engine qui contient un Minix un tourne ring -2 voire -3. (ring -1 étant l'hyperviseur pour les fonctions de virtualisation, au dessus du ring 0). A noter qu'il existe l'équivalent chez AMD le AMD Platform Security Processor (PSP) dont on entend moins parler mais qui n'est pas forcément mieux :
In September 2017, Google security researcher Cfir Cohen reported a vulnerability to AMD of a PSP subsystem that could allow an attacker access to passwords, certificates, and other sensitive information; a patch was rumored to become available to vendors in December 2017
6  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 15/06/2018 à 15:42
5  0 
Avatar de mattdef
Membre averti https://www.developpez.com
Le 05/11/2018 à 14:31
Il serait grand temps de mettre fin aux technologies HT et SMT... Les CPU d'aujourd'hui ont suffisamment de cœurs (merci AMD au passage) pour ne plus avoir besoin de cet artifice.
4  0 
Avatar de CaptainDangeax
Membre expérimenté https://www.developpez.com
Le 13/03/2019 à 11:34
Je suis allé il y a 2 semaines à une conférence sur les hardware trojans. Le conférencier a présenté 2 cas d'étude, mais qui sont extrèmement complexes à mettre en oeuvre et qui de plus requièrent un accès physique au matériel et qui sont en fait faciles à détecter. Donc ce vecteur d'attaque n'est pas utilisé.
Je reste persuadé qu'on risque bien plus par des attaques de social engineering, même si ça n'excuse pas Intel.
4  0 
Avatar de eldran64
Membre extrêmement actif https://www.developpez.com
Le 05/11/2019 à 9:59
Juste pour la petite info, désactivé l'hyperthreading sur un core I3 de 10ème génération, c'est perdre un peu plus de 30% de performance et non 20%.
Ça a fait partie des arguments qui m'ont poussé à passer sur une plateforme AMD à la place d'Intel.
4  0 
Avatar de eldran64
Membre extrêmement actif https://www.developpez.com
Le 12/12/2019 à 9:40
Les processeurs Intel sont vraiment daubés niveau archi.

La différence entre Intel et AMD c'est qu'AMD corrige ses failles de sécu d'une génération à l'autre.
Avec Intel, les failles de sécu ne sont pas corrigés et en plus comme leur archi datent de Mathusalem, le nombre de génération de processeurs touché par ses failles est très important.

Bref, avec Intel, il faut fuir comme la peste leur proco.
4  0