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 !

Les processeurs Intel x86 souffriraient d'un défaut
Qui exposerait la mémoire noyau et impacterait surtout sur le marché serveur

Le , par Christian Olivier

334PARTAGES

7  1 
Des rapports circulant depuis quelques jours sur la toile font état d’une vulnérabilité qui affecterait de manière spécifique (c’est encore spéculatif) les processeurs modernes de l’entreprise américaine Intel (génération ≥ Pentium Pro). Cette vulnérabilité pourrait être considérée comme majeure parce qu’elle mettrait en exergue un éventuel problème de sécurité sur les processeurs Intel suffisamment grave pour obliger Microsoft et Linus Torvalds à produire à la hâte des patchs spécifiques pour leurs OS respectifs.

Si au départ la vulnérabilité, telle qu’elle avait été rapportée, avait pu faire croire que l’ensemble des processeurs exploitant l’architecture x86 64-bits étaient concernés, une déclaration récente d’AMD a permis de voir un peu plus clair dans cette affaire.

« ;Les processeurs AMD ne sont pas concernés par les attaques contre lesquelles les techniques d’isolation de la table du noyau protègent. La microarchitecture AMD n’autorise pas les références mémoire, y compris les exécutions spéculatives, qui tentent d’accéder à des données à privilèges plus élevés alors qu’elles s’exécutent dans un mode privilégié inférieur quand cet accès est susceptible d’entraîner une erreur ;», pouvait-on lire dans le communiqué de la firme de Sunnyvale.

On pourrait donc supposer que la firme de Sunnyvale dispose d’informations encore sous embargo pour clamer ne pas être concernée même s’il faut éviter de tirer des conclusions hâtives tant que toute la lumière n’aura pas été faite sur cette affaire et les détails rendus publics. Au passage, il faut signaler que les processeurs basés sur les architectures ARM/RISC ne semblent pas être affectés.


L’exécution spéculative est essentiellement une forme de préemption qui tente de prédire quel code va être exécuté après un branchement, puis de l’extraire et de l’exécuter avant que l’ordre réel n’arrive. Les processeurs modernes ont une architecture en pipeline : ils traitent un grand nombre d'instructions simultanément, en avançant un petit peu dans chacune à chaque cycle. Si un branchement est mal prédit, tout le pipeline doit être vidé : la perte en performance est loin d'être négligeable. Cette technique a ses avantages, mais elle présente également un risque non négligeable pour la sécurité, car aucune vérification de privilège n’est présente au niveau du noyau du système d'exploitation.

Le problème réside dans le fait que vous pouvez exploiter cette fonctionnalité pour exécuter de manière spéculative un code qui devrait être normalement bloqué en stoppant l’exécution du code avant qu’une vérification puisse être effectuée. Cela signifie en gros qu’une application de niveau 3 (droits normaux) peut lire les données du noyau de niveau 0 (réservé à l'exécution du noyau) en utilisant une exécution spéculative, car la vérification de privilège ne sera pas effectuée avant que le code ne soit exécuté.

Tout serait parti d’un article de blog paru en juillet 2017. Son auteur y décrivait une expérience dans laquelle il tente d’accéder à la mémoire protégée utilisée par le noyau à partir de l’espace utilisateur, l’espace mémoire utilisé par les programmes classiques, en exploitant les mécanismes d’exécution spéculative intégrés dans les CPU x86 64-bits modernes.

Ces processeurs disposent d’unités spécialisées dans la gestion de la mémoire (MMU) qui permettent de contrôler les accès qu’un CPU fait à la mémoire de l’ordinateur. Ils peuvent fonctionner suivant au moins deux modes de fonctionnement, dont un mode noyau qui n’impose pas de restrictions sur les instructions exécutées, et un mode utilisateur qui limite ce que peuvent faire les instructions.

Habituellement, le système d’exploitation met en œuvre cette distinction en faisant fonctionner les autres programmes en mode utilisateur et en se réservant le mode noyau. Cette distinction entre espace utilisateur et espace noyau est à la base du contrôle d’accès qui empêche les instructions des applications de l’espace utilisateur d’accéder à une zone mémoire ne leur appartenant pas. On parle aussi de lecture d’une adresse mémoire non autorisée lorsque ce dysfonctionnement survient. Cette situation débouche rapidement sur une trappe du noyau et, en général, la fermeture du programme incriminé. Il faut noter que la trappe est déclenchée par une interruption matérielle et le mécanisme de protection mémoire ne peut être implémenté efficacement de façon logicielle.


L’auteur du blog a essayé de s’attaquer à ce mécanisme en tentant d’exploiter l’intervalle de temps pendant lequel une instruction non autorisée est exécutée et génère une interruption. Même s’il a précisé ne pas avoir réussi à lire la mémoire protégée grâce à sa méthode, il s’est rendu compte que le chargement mémoire interdit est bel et bien effectué par le CPU même si le processeur ne copie jamais l’information dans le registre. Il a remarqué que l’exécution spéculative se poursuivait dans les unités d’exécutions internes du CPU jusqu’à ce que l’interruption soit effective et que cette situation pouvait favoriser la survenue d’attaques potentielles basées, par exemple, sur les temps d’exécution des instructions pour déterminer les adresses mémoires utilisées par le noyau.

Qu’il soit possible, à partir d’un programme utilisateur, de déterminer les adresses mémoire utilisées par le noyau est une situation qui ne devrait pas se produire. Différentes techniques ont d’ailleurs été mises au point depuis des années pour respecter ce principe, l’une des méthodes les plus efficaces à l’heure actuelle étant l’ASLR (Address Space Layout Randomization). Cette dernière attribue un caractère aléatoire aux adresses mémoires utilisées par les applications et le noyau.

Cette « ;vulnérabilité matérielle ;» (parce que liée au fonctionnement spécifique des CPU modernes d’Intel comme semble le confirmer le mémo d’AMD) permettrait d’exploiter des processus en espace utilisateur en contournant la MMU et d’accéder à la mémoire noyau. Le problème étant matériel, dans la partie non reconfigurable du processeur, il ne serait apparemment pas envisageable de recourir à un patch via microcode pour corriger cette faille de sécurité.

La seule façon de contourner cette fonctionnalité au niveau logiciel serait d’utiliser une technique d’isolation de la table de correspondance (entre les adresses en mémoire virtuelle et en mémoire physique) du noyau (en anglais, KPTI) : cela rendrait le noyau complètement aveugle et le retirerait de l’espace mémoire virtuel jusqu’à ce qu’un appel système survienne. Il faudrait donc laisser aux éditeurs d’OS le soin de concevoir ces patchs via le système d’exploitation pour leurs produits respectifs.

À ce propos, il faut signaler que, durant ces derniers mois, KAISER, une nouvelle solution de sécurité proactive dédiée au noyau Linux, a vu le jour. Cette solution, qui a été renommée par la suite KPTI (Kernel Page Table Isolation), est censée limiter de manière significative l’impact d’éventuelles failles présentes ou à venir et mieux protéger les espaces mémoire du noyau. Il permettrait notamment de séparer les tables qui pointent vers les pages mémoires utilisées par le noyau de toutes les autres. Le 30 décembre dernier, Linus Torvalds a intégré KPTI directement dans la version 4.15-rc6 du noyau Linux et recommandé l’intégration de ce patch dans tous les noyaux encore maintenus, ce qui pourrait laisser penser que le problème devait être suffisamment grave pour que de telles mesures soient adoptées. Microsoft aurait également préparé des correctifs similaires à KPTI pour le noyau de Windows depuis novembre dernier.

Le problème avec ces patchs, c’est qu’ils introduisent une pénalité de temps pour le système et qu’ils ont un impact non négligeable sur les performances de certains types d’applications. Celles qui effectuent beaucoup d’appels aux instructions système devraient être les plus affectées. Pour une utilisation non serveur, tout semble pointer vers un impact nul ou infinitésimal. Côté serveur l’impact serait plus large et pourrait affecter massivement les infrastructures cloud où la virtualisation, très gourmande en appels système, est largement utilisée.

Source : Cyber WTF, AMD, Twitter info patch Windows, WccfTech

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Les processeurs Intel x86 souffrent d'un défaut qui permet d'installer des logiciels malveillants dans l'espace protégé des puces

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

Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 04/01/2018 à 11:24
Ce n'est plus du tout spéculatif. Google a publié les papiers de recherche qui expliquent les vulnérabilités ont étés publiés. La plus grave (Meltdown), n'affecte que les processeurs Intel tandis que la moins facilement exploitable (Spectre) fonctionne sur pas mal de processeurs (Intel, AMD et ARM).

Lien: Spectre et Meltdown

En bonus, la mauvaise fois ultime d'Intel. Juste pour ça, mon prochain CPU sera un AMD, car foirer un design sur un CPU c'est déjà pas génial mais répondre "Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers." le jour de la publication de la faille c'est juste nous prendre pour des cons.
10  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 05/01/2018 à 19:35
Citation Envoyé par chrtophe Voir le message
Je pense que les failles reposent sur le dispositif de prédiction de branchement.
Les trois failles reposent sur l'exécution spéculative, ce qui est un peu différent de la prédiction de branchement.

Avec la prédiction de branchement, lorsqu'il va y avoir un test (du style if/then/else) le processeur va charger l'instruction qu'il pense avoir le plus de chances d'être la suivante.

Avec l'exécution spéculative, le CPU charge une instruction qu'il estime avoir bonne chance d'être exécutée mais en plus, il l'exécute vraiment.

Dans les deux cas, si l'hypothèse est infirmée, l'exécution reprend vers la bonne instruction à exécuter. En théorie, on revient dans le même état que celui ou l'on aurait été sans ces optimisations, mais en pratique, l'exécution spéculative a des effets de bord: la perte de données qui étaient auparavant en cache et la présence dans le cache de données qui n'y seraient pas allées autrement.

Il n'y a pas d'instructions qui permettent de lire directement les données placées en cache par les techniques précédentes mais il existe des moyens détournés sophistiqués pour le deviner. Celui qui est le plus souvent décrit consiste à mesurer le temps mis à charger le contenu d'une adresse mémoire. Si ce temps est "long", c'est que le processeur est bien allé chercher la donnée en RAM. Si ce temps est court, c'est que cette adresse viens déjà d'être lue. On a donc réussi à lire le contenu du cache alors qu'il n'existe pas de moyen direct de le faire.

Avec Meltdown, on peut lire la totalité de la mémoire du noyau. On ne peut pas directement écrire dans cette mémoire, mais ce qu'on y lit, par exemple des mots de passe en clair ou des clefs privées pourra être exploité pour facilement devenir root.

Le cpu fait de l'exécution spéculative avec un gain de performance en cas de succès et une perte en cas d’échec, mais globalement cela donne un gain de perfs.
Il n'y a pas vraiment de perte de performance en cas d'échec (la durée du rollback doit être infime). Le temps passé par le CPU à faire de l'exécution spéculative aurait sinon été perdu à ne rien faire.


Corrompre les caches du CPU donnera un résultat aléatoire, je pense que c’est le principe de fonctionnement des exploits de ces failles.
Il n'y a pas de corruption des caches, mais au contraire chargement de données valides mais "interdites" dans les caches. Invalider complètement les caches supprimerait le risque mais serait inacceptable en terme de performance. Il faut cent à deux cents fois plus de temps pour charger des données de la RAM par rapport au cache niveau 1, vingt fois plus que le cache niveau 2.

Ces caches sont importants pour l'utilisation de la MMU, qui gère les droits d'accès aux pages mémoires.

Je pense que les patchs invalident les caches à des moments bien précis, ce qui fait perdre en perf.
Les patches qui sont disponibles pour Windows, Linux et OS X mettent en place une séparation franche entre espace mémoire utilisateur et espace mémoire noyau, ce qui n'était pas le cas jusqu'ici. L'objectif est de contrer Meltdown (spécifique aux processeurs Intel) mais avec un impact sur les performances qui est sujet à controverse (entre non mesurable et 30% suivant l'utilisation du processeur).

Il existe aussi des patches pour les compilateurs qui modifient le code assembleur généré pour contrer certains types d'attaques en replaçant les appels par un "retpoline" (return trampoline) et des patches pour le microcode des CPUs
10  0 
Avatar de emixam16
Membre expérimenté 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 codec_abc
Membre confirmé https://www.developpez.com
Le 04/01/2018 à 14:50
Citation Envoyé par abriotde Voir le message
Oui enfin c'est surtout que techniquement c'est assez difficile à exploiter, il semble falloir analyser tous l'espace d'adressage pour réussir à déterminer des adresse noyau (et a priori faire planter son programme des millions de fois) et ensuite arriver à comprendre qu'est-ce qu'il y a derrière ces adresses... la pluspart des malware n'ont pas envie de se casser la tête avec ça, il y a d'autres failles à exploiter plus facilement avant. Récupérer les données bancaires leur suffit
Par contre pour ceux qui se pencheront dessus, l'avantage que cela procure au programme c'est de pouvoir alors avoir un accès root mais plus que ça, pouvoir s'installer dans le système d'amorçage de l'ordinateur ou en mémoire noyau à un endroit ou il ne pourra pas être détecter par un anti-virus qui lui tourne en espace utilisateur (en root).
Alors il est vrai que ce n'est pas la peine de paniquer car ce sera peu exploiter et pas tout de suite mais ceux qui l'exploiteront auront tous de même un sacré avantage.
Comme dit dans le papier, il existe des techniques qui permettent de supprimer l'exception qui fait planter le programme, donc non le programme de plantera pas des millions de fois.

Aussi, il n'y pas pas besoin de dumper toute la mémoire car et la plupart des programmes (surtout natif) ont souvent des patterns d'allocations bien déterministe ce qui rend beaucoup plus rapide la recherche et l'analyse de la mémoire pour un programme malveillant. Bref, Meltdown n'est pas clairement pas impossible a mettre en œuvre, loin de la même. Pour rappel on a déjà eu Stuxnet qui consistait quand même a faire un virus qui reprogrammais les automates des centrifugeuses des centrales iraniennes pour ralentir leur programme nucléaire. Donc ça m'étonnerait que certaines organisation ne s'intéresse pas à cette faille qui leur laisse la porte ouverte a tout PC équipé d'un CPU Intel de moins de 10 ans.
7  0 
Avatar de e101mk2
Membre confirmé https://www.developpez.com
Le 08/01/2018 à 21:46
Entre Intel Management Engine, Meltdown et Spectre, Intel bat des records.

Les entreprises vont ce mettre à trembler dès qu'ils vont entendre parler d'Intel...
7  0 
Avatar de Nudger
En attente de confirmation mail https://www.developpez.com
Le 04/01/2018 à 16:17
Citation Envoyé par RyzenOC Voir le message
Depuis ce matin il semble que ce problème impacte aussi les cpu ARM et IBM Power 8/9.
AMD serait aussi un peu touché (Spectre) mais moins que intel.

A titre personnel je n'appliquerais pas le patch sur mes serveur linux. La perte de perf est trop importante et la faille est quand même difficilement exploitable pour un hacker. Il faut réunir quand même pas mal de condition pour l'exploiter.
Si vous êtes sur une machine dédiée et dont l'accès est suffisamment sécurisé, il n'y a pas trop d'inquiétude.
L'exécution d'un code qui exploite cette faille pourra difficilement se faire.

En revanche pour une machine virtuelle dans le cloud, c'est pas la même histoire : sur une même machine physique tourne plusieurs VM et rien ne dit qu'il n'y a pas un voisin malveillant qui va vouloir exploiter cette faille sur les CPU pour tenter de récupérer des données de votre propre VM.
6  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 expérimenté 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 MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 04/01/2018 à 16:14
Citation Envoyé par codec_abc Voir le message
Ce n'est plus du tout spéculatif. Google a publié les papiers de recherche qui expliquent les vulnérabilités ont étés publiés. La plus grave (Meltdown), n'affecte que les processeurs Intel tandis que la moins facilement exploitable (Spectre) fonctionne sur pas mal de processeurs (Intel, AMD et ARM).

Lien: Spectre et Meltdown

En bonus, la mauvaise fois ultime d'Intel. Juste pour ça, mon prochain CPU sera un AMD, car foirer un design sur un CPU c'est déjà pas génial mais répondre "Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers." le jour de la publication de la faille c'est juste nous prendre pour des cons.
"Moins facile à exploiter", c'est vite dit. Spectre requiert certes un ralentissement qui sera visible de l'utilisateur, et un code complexe, mais potentiellement un JavaScript executé dans le browser sans rien demander à l'utilisateur pourrait piller des cookies d'authentification ou des mots de passe. Et pour le ralentissement (qui ferait sans doute rebooter sa machine à l'utilisateur lambda), les papiers précisent qu'il "y a de la place pour optimiser". Et encore heureux que ce soit difficile à executer, parce que ce n'est pas loin d'être la faille ultime.
5  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 15/01/2018 à 11:52
Citation Envoyé par liberal1 Voir le message
Qu'est-ce que tu appelles interruption matérielle?
Tu as raison de poser la question. La terminologie est parfois floue et, suivant le contexte, il n'y a parfois pas consensus sur ce que recoupent les termes "trap", "exception", "interruption", etc.

J'ai assimilé un peu vite tout ce qui n'était pas interruption logicielle à interruption matérielle alors qu'un "page fault" sur du x86 n'est techniquement ni l'une ou l'autre.

Une interruption matérielle est liée à un événement extérieur et indépendante du code exécuté, c'est donc une interruption asynchrone.

Une interruption logicielle, c'est une instruction dont le rôle est d'interrompre le cours normal du code (trap, int, syscall, etc...), c'est une interruption planifiée

Une faute de page ("page fault" est aussi une exception synchrone (liée au code exécuté) mais elle n'est pas planifiée. La finalité de l'instruction entraînant cette exception n'est pas de générer une interruption, c'est juste une éventualité. La détection de cette exception se produisait dans un composant initialement indépendant des CPU (d'où ma confusion), mais les MMU sont maintenant intégrés aux CPU.

Quand elle survient dans du code utilisateur et qu'elle n'est pas ignorée, l'effet d'une interruption matérielle, logicielle ou d'une faute de page est de transférer le controle du thread affecté à une routine dédiée du système d'exploitation, via une table de vecteurs d'interruptions.

Meltdown exploite le fait que les CPU Intel autorisent du code utilisateur à (commencer à) accéder à une page du noyau sans que la faute de page attendue ne soit immédiatement remontée.
5  0