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 !

Bogues critiques touchant les CPU modernes : Google a informé Intel depuis des mois
Et confirmé qu'ils affectent plus Intel et ARM qu'AMD

Le , par Christian Olivier

209PARTAGES

7  0 
Les chercheurs de Google ont découvert que la temporisation du cache de données des processeurs modernes peut être utilisée de manière abusive pour récupérer illégalement les informations sur un ordinateur. Cette fonctionnalité est utilisée par la plupart des processeurs modernes pour optimiser les performances, mais elle peut également occasionner de graves problèmes de sécurité, car des attaquants pourraient tirer parti de l’exécution spéculative afin de lire le contenu de la mémoire du noyau d’un ordinateur qui en temps normal aurait dû leur être inaccessible.

Contrairement aux premières informations indiquant que ces vulnérabilités critiques causées par des problèmes de conception de microprocesseurs affectent uniquement les CPU Intel, la firme de Santa Clara n’est pas le seul acteur du marché des microprocesseurs à être touché par ce problème. Intel l’a d’ailleurs confirmé dans un communiqué paru récemment sur son site Web.

La réponse d’Intel au sujet des vulnérabilités critiques

Le fondeur de Santa Clara estime que « ;ces exploits n’ont pas le potentiel de corrompre, modifier ou supprimer des données ;». L’entreprise technologique américaine a tenu à préciser qu’il est incorrect de penser que les failles dont il est question n’affectent que ses produits, et insisté sur le fait que « ;de nombreux dispositifs informatiques équipés d’une grande variété de processeurs et de systèmes d’exploitation développés par différents fournisseurs sont sensibles à ces exploits ;».

La firme de Santa Clara « ;avait prévu de divulguer ce problème la semaine prochaine ;», mais aurait été prise de cours par l’apparition de rapports médiatiques inexacts. Elle a assuré collaborer avec les autres acteurs de l’industrie technologique concernés par ce problème, notamment AMD, ARM et les éditeurs d’OS populaires comme Android, les distributions Linux ou Windows, afin de trouver dans les meilleurs délais une solution constructive à ce problème.

Les premières informations fournies par certains rapports laissaient supposer que les correctifs qui seront déployés par la suite pour régler le problème pourraient causer des baisses de performances non négligeables sur les machines concernées (jusqu’à 30 %). Mais de l’avis d’Intel, « ;les impacts sur les performances dépendent de la charge de travail et, pour l’utilisateur moyen d’un ordinateur, ils ne devraient pas être significatifs et seront atténués au fil du temps ;».

Intel a recommandé aux utilisateurs de se référer aux consignes des vendeurs et des éditeurs d’OS pour obtenir plus de détails en ce qui concerne la procédure à suivre. L’entreprise a également tenu à rassurer en déclarant que « ;ses produits sont les plus sécurisés au monde et que, avec le soutien de ses partenaires, les solutions actuelles à ce problème offrent la meilleure sécurité possible à ses clients ;».

Intel était au courant depuis le 1er juin 2017 et son PDG a décidé de vendre ses actions

Cependant, la firme de Santa Clara était au courant depuis plusieurs mois déjà de l’existence de cette situation, et ce serait Google qui aurait pris soin de l’en informer. À ce propos, l’éditeur d’Android a confirmé sur son site qu’il a prévenu AMD, ARM et Intel de cette situation depuis le 1er juin 2017 et clarifié les détails relatifs à cette affaire en fournissant une liste des différentes variantes de la faille critique dont il est question.

Il faut souligner que le 29 novembre dernier, le PDG d’Intel, Brian Krzanich, a vendu les actions qu’il possédait dans la firme américaine pour 24 millions USD. Cette opération est survenue après qu’Intel a été informé par Google de vulnérabilités majeures affectant ses puces, celles-là mêmes qui ont été rendues publiques cette semaine. La société affirme que cette vente d’actions n’était pas liée à la découverte de la faille en question, mais qu’elle faisait partie d’un programme de cession planifié. Le PDG, dans son opération de vente, n’aurait conservé que 250 ;000 actions au sein du groupe, le strict minimum que l’entreprise lui exige de posséder en vertu de son contrat de travail.

Les résultats des investigations menées par Google

Grâce aux précisions fournies par une étude menée par le projet Zero de Google, on sait désormais que les vulnérabilités critiques touchant les CPU modernes affectent non seulement les CPU x86 64-bits d’Intel, mais aussi les puces basées sur l’architecture ARM. Les processeurs conçus par AMD sont aussi concernés, mais dans une moindre mesure seulement puisque Google estime le risque proche de 0 pour les CPU du fondeur de SunnyVale. Red Hat a prévenu de son côté que même certains CPU IBM sont concernés par cette annonce. Même si les entreprises AMD et ARM sont désormais affectées par cette faille de sécurité, leurs CPU sont beaucoup moins gravement touchés que ceux d’Intel.

Il existe trois variantes principales des exploits que Google a détaillées avec leurs mécanismes d’action respectifs dans un article : variante 1 (CVE-2017-5753), variante 2 (CVE-2017-5715), variante 3 (CVE-2017-5754). Deux d’entre elles ont été respectivement baptisées Meltdown et Spectre, elles affecteraient les processeurs depuis 1995. La variante 1 affecte presque tous les processeurs modernes (AMD, ARM et Intel notamment), alors que les variantes 2 et 3 de la faille affectent principalement les CPU Intel et une partie des CPU ARM. Google estime que « ;Spectre est plus difficile à exploiter que Meltdown, mais qu’il est également plus difficile à atténuer ;».

Alors qu'AMD avait affirmé que ses processeurs n'étaient pas affectés par les vulnérabilités critiques évoquées, la société précise maintenant que « l'ampleur de la menace et la nature des mesures à adopter concernant les trois variantes diffèrent selon le fabricant de microprocesseurs considéré, et AMD n'est pas sensible aux trois variantes ». La firme de SunnyVale soutient également que le risque serait quasi nul pour ses processeurs les plus récents.

ARM, de son côté, a reconnu que la fonctionnalité d’exécution spéculative de nombreux processeurs haute performance modernes, bien que fonctionnant comme prévu, présente également un risque non négligeable pour la sécurité. La société a précisé avoir développé des patchs spécifiques qu’elle recommande d’utiliser. En outre, ARM a inclus des informations au sujet d’une variante notée 3a qui figure dans le tableau ci-dessous. Ce tableau liste les puces ARM et les variantes de la faille susceptibles de les affecter.

Source : Intel, AMD, Google Project Zero, ARM, Business Insider

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Les grands éditeurs et fournisseurs de cloud s'activent pour patcher leurs produits contre les vulnérabilités dans les puces d'Intel, AMD et ARM
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 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 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 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 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 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 15/06/2018 à 15:42
5  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 15/01/2018 à 21:53
Citation Envoyé par transgohan Voir le message
Analyse intéressante, j'en viens à revoir ma définition d'une interruption matérielle du coup...

Mais du coup pour rebondir sur l'exemple des page fault, dans quelle case la rangerais-tu ? Elle a tout de l'exception matérielle si on tente de coller à tes deux définitions, mais la suite de ton message laisse à penser que tout ce qui est interne au processeur serait catégorisé comme interruption logicielle.
Ni l'une ni l'autre.

Il y a les interruptions:

  • intimement liées aux instructions en cours d'exécution sur le CPU (synchrones):
    • provoquées intentionnellement : software interrupts, instructions dédiées
    • provoquées involontairement : page-fault, division par zéro, etc. Elles sont en général inattendues mais quelques unes sont inévitables, par exemple les page-faults. Tout le mécanisme de pagination à la demande d'Unix/Linux et autres OS s'appuie sur elles.

  • pas du tout liées aux instructions en cours d'exécution sur le CPU (asynchrones):
    • peuvent survenir n'importe quand, que le CPU soit en train d'exécuter du code user, kernel our ien du tout (idle). Elles sont provoquées par un événement externe affectant un composant matériel, hardware interrupts. Elles sont aussi inévitables, sans hardware interrupts, pas de timers, d'entrées-sortie disque ou réseau, de communication USB, d'affichage video,...



Dans le même genre, que dire d'une interruption générée par un coprocesseur de communication (dédié à la gestion des SCC par exemple) ? C'est interne au processeur, mais ce n'est pas notre code qui la génère (au mieux c'est notre configuration, voir sous certains aspects totalement extérieur).
Ce que tu décris est une hardware interrupt.

Un composant extérieur peut être géré de trois façons (ou une combinaison des trois) :

  • envoi d'un interruption au processeur pour qu'il traite chaque événement le nécessitant (hardware interrupt)
  • utilisation d'un accès direct à la mémoire (DMA) pour éviter d'interrompre (trop) le processeur.
  • attente passive, c'est le driver qui va régulièrement voir s'il y a quelque chose à traiter dans le composant extérieur (polling), rare.
4  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 02/02/2018 à 14:27
Contrairement à Meltdown qui est une faille bien précise affectant certains processeurs, qui permet à un processus d'accéder à la mémoire du noyau et pour laquelle les parades sont bien identifiées, il vaut mieux ne pas parler de "la" faille Spectre, mais d'une nouvelle famille de vulnérabilités comportant deux vecteurs d'attaque (type 1: bound check bypass) et (type 2: branch target injection).

Spectre n'est pas une faille affectant des processeurs spécifiques, mais un effet de bord de l'architecture de la plupart des processeurs modernes. Spectre permet à un processus d'accéder à des données auxquelles on croyait qu'il n'avait pas accès.

Les documents sur Spectre indiquent que des attaques s'attaquant au processus lui-même sont faciles à implémenter, mais indiquent aussi que sont possibles des attaques plus complexes à mettre en œuvre permettant d'accéder à des données d'autres processus, au noyau et même, au delà du noyau, à des données de l'hyperviseur en cas de virtualisation.

Il n'y a donc pas une faille, mais, en fonction des processeurs, des applications, systèmes d'exploitation et hyperviseurs utilisés, un certain nombre de failles spécifiques identifiées ou non, divulguées ou non.

Corriger ces failles semble être un travail de titan. Il faut trouver des parades dans la façon de générer du code assembleur, donc modifier les compilateurs et tout recompiler. Patcher le microcode des CPU existants ne peut pas suffire car désactiver complètement l'exécution spéculative aurait un impact trop important sur les performances.
4  0 
Avatar de mattdef
Membre actif 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