Des failles sur les processeurs AMD et Intel comme s’il en pleuvait

Des failles sur les processeurs AMD et Intel comme s’il en pleuvait

Il faut aussi confiner les processeurs

Avatar de l'auteur
Sébastien Gavois

Publié dans

Hardware

10/03/2020 11 minutes
11

Des failles sur les processeurs AMD et Intel comme s’il en pleuvait

1…2… et 3 failles chez AMD et Intel. La première se loge dans la ROM du CSME des plateformes Intel et serait impossible à corriger. Encore chez Intel, la deuxième est liée à l’exécution spéculative, mais injecte des données au lieu d’en extraire. Enfin, la troisième concerne le prédicteur de cache L1D des processeurs AMD, mais le Texan n’est pas du même avis que les chercheurs.

Au cours des derniers jours, plusieurs publications font état de « nouvelles » failles dans les processeurs AMD et Intel, avec des niveaux de dangerosité plus ou moins importants suivant les cas (élévation de privilèges, exécution de code arbitraire, extraction de données, etc.). Avant d’entrer dans les détails, commençons par un rapide tour d’horizon.

On commence par Intel avec une faille concernant de nombreux SoC et plateformes x86. Elle prend racine dans la ROM du Converged Security & Management Engine, ce qui la rendrait impossible à corriger. Selon le chercheur, il faut même s’attendre à un « chaos total » par la suite puisqu’il serait possible d’extraire la « hardware key ».

Bitdefender est le dernier en date en proposant un Proof of Concept pour la brèche CVE-2020-0551. Elle touche elle aussi les processeurs Intel, mais concerne principalement les serveurs et datacenters (là où de la virtualisation est utilisée) et serait « particulièrement dévastatrice ».

Enfin, une équipe de chercheurs emmenée par Moritz Lipp se penche sur le cas des CPU AMD et plus particulièrement sur le prédicteur de cache L1 pour les données. Le Texan se défend et « estime qu’il ne s’agit pas de nouvelles attaques », un point sur lequel les chercheurs ne sont pas d’accord.

Le retour en force d’une ancienne faille qui serait « incolmatable »

Commençons par la publication de Positive Technologies dont les prémices remontent à mi-février lorsque Mark Ermolov, un chercheur spécialisé en sécurité informatique, publie un tweet où il explique qu’Intel a « rompu un embargo », sans donner beaucoup plus de détail. Début mars, un billet de blog signé Ermolov est finalement mis en ligne par Positive Technologies. Cette dernière précise qu’il s’agit d’une première étape et qu’un livre blanc complet est en préparation. Il sera mis en ligne dans un second temps, sans plus de précision.

Cette brèche n’est pas totalement nouvelle puisqu’elle avait fait l’objet d’une publication en mai dernier par Intel en personne. « De multiples vulnérabilités ont été découvertes dans Intel CSME, Intel SPS, Intel TXE, Intel DAL et Intel AMT 2019.1 QSR. Elles permettent à un attaquant de provoquer un déni de service à distance, une atteinte à la confidentialité des données et une élévation de privilèges », expliquait alors l’ANSSI.  

Le billet d’Intel a ensuite été mis à jour le 11 février 2020, déclenchant au passage le tweet de Mark Ermolov. Le fondeur y fait des rappels sur la sécurité des machines, précise que des mises à jour permettant de limiter les risques sont disponibles pour ses clients/partenaires et demandent aux « utilisateurs finaux de conserver la possession physique de leur machine ». 

Une vulnérabilité dans la ROM et c’est le drame

Selon Mark Ermolov, la brèche de mai dernier serait en fait bien plus importante que prévu. « Une vulnérabilité a été trouvée dans la ROM du Converged Security & Management Engine (CSME). Elle met en péril tout ce qu'Intel a réalisé pour construire de solides bases de sécurité sur ses plateformes », affirme-t-il.

Un pirate pourrait alors interférer avec la génération de clés de chiffrement et en profiter pour « falsifier le code de n'importe quel module du firmware CSME d’Intel, de telle manière que les vérifications d'authenticité ne puissent pas le détecter ». Pour résumer, c’est grave. Le chercheur ajoute qu’« Intel comprend qu'il ne peut pas corriger la vulnérabilité dans la ROM des produits existants. Il essaie donc de bloquer tous les vecteurs d'exploitation possibles ».

« Le plus gros problème étant que cette vulnérabilité permet de compromettre la machine au niveau matériel », explique Positives Technologies dans son billet de blog. Pour ne rien arranger, elle serait impossible à détecter pour les antivirus.

Processeur Intel
Crédits : yorkfoto/iStock

Un correctif partiel, d’autres pistes évoquées

La société et le chercheur ne s’arrêtent pas en si bon chemin : « Le correctif pour CVE-2019-0090 ne concerne qu'un seul vecteur d'attaque potentiel. Nous pensons qu'il pourrait y avoir de nombreuses façons d'exploiter cette vulnérabilité dans la ROM. Certaines peuvent nécessiter un accès local, d'autres ont besoin d'un accès physique ». Il n’en dit pas plus pour le moment, il faudra certainement attendre la publication du livre blanc.

Selon le chercheur, cette vulnérabilité concerne « tous les chipsets et SoC Intel disponibles aujourd'hui », mis à part les plateformes Ice Point et Comet Point, respectivement pour les processeurs Ice Lake et Comet Lake (10e génération) d’Intel.

Le « chaos total » pour bientôt ?

Ce n’est pas tout puisque la situation pourrait grandement s’aggraver à l’avenir selon le chercheur. Il pense en effet qu’il serait possible de récupérer la « hardware key » – qui ne dépend pas de la plateforme, mais qui est propre à chaque génération de chipset – enregistrée dans le Secure Key Storage (SKS) ; ce ne serait qu’une question de temps maintenant.

« Lorsque cela se produit, le chaos total régnera », prévient Mark Ermolov : « Les identifiants matériels seront falsifiés, le contenu numérique sera extrait et les données des disques durs chiffrés seront décryptées ». Étant donné que cette clé est inscrite dans la ROM, il ne serait pas possible de la changer, même si « l’Armageddon » devait arriver.

« Il ne sera plus possible de protéger les systèmes avec des mises à jour puisqu’il n’y aura plus la moindre fondation sur laquelle s’appuyer », explique Mark Ermolov. Seule solution envisage : changer de processeur…

Load Value Injection : injecter du code au lieu d’extraire des données

On reste chez Intel. Bitdefender entre en piste aujourd’hui avec une nouvelle faille baptisée CVE-2020-0551 : « Cette vulnérabilité permet à un attaquant d'injecter des fonctionnalités malveillantes au sein de certaines structures microarchitecturales qui sont ensuite utilisées par la victime et créant ainsi un risque important de vol de données sensibles », explique la société. Malgré la proximité temporelle, elle est différente de celle remontée par Positive Technologies.

Comme dans le cadre du trio Spectre, Meltdown et MDS (Microarchitectural Data Sampling), cette vulnérabilité est liée à l’exécution spéculative des processeurs Intel. Alors que jusqu’à présent de telles vulnérabilités étaient utilisées pour extraire des données, cette fois-ci les chercheurs en profitent au contraire pour injecter du code qui sera ensuite exécuté par la machine. Pour le nom, Bitdefender ne s’est pas foulé : Load Value Injection (LVI). 

Bitdefender explique que les serveurs et centres de données sont la cible première de cette attaque qui serait « particulièrement dévastatrice dans les environnements multitenants, les grandes entreprises et les datacenters » : « Un utilisateur ne disposant pas d’importants privilèges serait ainsi en mesure d’accéder à des informations sécurisées (clés de chiffrement, mots de passe en mémoire, etc.) détenues par des utilisateurs ayant des privilèges élevés ou issus d’autres environnements virtualisés, au-dessus de l’hyperviseur ».

Une contre-mesure possible : désactiver l’Hyper-Threading 

La société affirme que « les mesures d’atténuation mises en place pour les vulnérabilités Meltdown, Spectre ou MDS ne sont pas suffisantes. Pour supprimer complètement cette nouvelle vulnérabilité, il faut soit désactiver des fonctionnalités qui offrent d’importants gains de performances telles que l'Hyper-Threading […] soit remplacer le matériel lui-même… ». Selon Bitdefender, « Intel s'attaquera probablement à ce nouveau type de problème avec les prochaines générations de CPU ».

Un livre blanc contenant tous les détails techniques est disponible par ici. Bitdefender a signalé la brèche le 10 février à Intel. Deux semaines plus tard, le fondeur « a reconnu l’existence de cette vulnérabilité » et il a alors été convenu que les détails seraient dévoilés aujourd’hui. Un temps « très court » pour Bitdefender, qui indique ne pas avoir pu approfondir ses recherches et terminer un programme de démonstration de faisabilité (PoC) pleinement exploitable. À défaut, un PoC synthétique est disponible, mais pour une partie des différents scénarios possibles uniquement.

La société précise enfin qu’elle n’est pas la première à révéler cette attaque, une équipe d’autres chercheurs l’avait devancée auprès d’Intel. Elle est composée de Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss et Frank Piessens. « Les recherches de Bitdefender sont créditées de la mention "Proof of Concept" », explique la société.

AMD : Take A Way met à mal le prédicteur de cache L1D 

Enfin, une troisième faille a été annoncée pour les processeurs AMD cette fois-ci. Six chercheurs ont signé une publication dont le titre est « Take A Way: Exploring the Security Implications of AMD's Cache Way Predictors » : Vedad Hadžić, Arthur Perais et Clémentine Maurice sont sur la liste, ainsi que trois autres chercheurs également crédités par Bitdefender pour la faille LVI que nous venons d’évoquer : Moritz Lipp, Michael Schwarz et Daniel Gruss.

Ces trois noms vous rappellent certainement quelque chose : ils sont à l’origine de NetSpectre, une variante de Spectre exploitable sans accès local à la machine. Bref, tout ce petit monde continue de s’engouffrer allégrement dans les failles géantes ouvertes par les attaques par canal auxiliaire (side channel) et découvre de nouvelles ramifications au fil du temps. Bien que proche de Meltdown et Spectre sur son fonctionnement, Daniel Gruss affirme sur Twitter qu’il s’agit ici bien d’une nouvelle attaque de type side channel, pas d’une variante.

Les chercheurs expliquent que, afin d’optimiser la consommation énergétique et les performances de ses CPU, AMD a introduit depuis son architecture Bulldozer un « prédicteur » pour le cache de données L1 (alias L1D) : « nous sommes les premiers à l’exploiter. Nous avons procédé à une rétro-ingénierie du prédicteur du cache L1D dans les microarchitectures AMD de 2011 à 2019, résultant en deux nouvelles techniques d'attaque » : 

  • Avec Collide+Probe, un attaquant « peut surveiller les accès à la mémoire d'une victime »
  • Avec Load+ Reload, il est possible d’obtenir « des traces très précises d'accès à la mémoire de victimes partageant le même noyau physique »

Il ne s’agit pas de nouvelles attaques selon AMD…

Combiné avec une attaque de type Spectre, les chercheurs affirment être en mesure d’extraire des données. Pour les chercheurs, leurs travaux montrent que la conception des processeurs « AMD est vulnérable aux attaques de type side channel ». AMD n’est pas du même avis.

Le Texan s’est fendu d’une mise à jour de sa page dédiée à la sécurité : « Nous sommes au courant d’un nouveau livre blanc qui revendique l’exploitation de failles potentielles dans les processeurs AMD, par lequel un acteur malveillant pourrait manipuler une fonctionnalité liée au cache afin de transmettre potentiellement des données utilisateur d’une manière inattendue ».

« Les chercheurs associent ensuite cette manière de faire avec des vulnérabilités connues et atténuées au niveau logiciel ou sur l’exécution spéculative », ajoute le Texan. « AMD estime qu’il ne s’agit pas de nouvelles attaques fondées sur la spéculation », affirme-t-il en guise de conclusion… sans pour autant revenir précisément sur le prédicteur de cache L1D au centre de cette histoire.

Take  A Way AMD
Crédits : Take A Way: Exploring the Security Implications of AMD’s Cache Way Predictors

… les chercheurs persistent et signent

Les chercheurs ne changent pas d’avis. À la question de savoir si les contre-mesures actuelles sont suffisantes pour contrer les failles dont il est question, Vedad Hadžić est catégorique : « Non, le prédicteur [de cache] se comporte toujours comme décrit dans le document ».

Tom‘s Hardware.com qui s’est s’entretenu avec les chercheurs et AMD (avec pour seule réponse de la part du fabricant un lien vers leur mise à jour) résume ainsi la situation actuelle : « Tant que les deux parties ne seront pas d'accord, il n’est pas possible de déterminer quel point de vue est le plus juste ».

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le retour en force d’une ancienne faille qui serait « incolmatable »

Une vulnérabilité dans la ROM et c’est le drame

Un correctif partiel, d’autres pistes évoquées

Le « chaos total » pour bientôt ?

Load Value Injection : injecter du code au lieu d’extraire des données

Une contre-mesure possible : désactiver l’Hyper-Threading 

AMD : Take A Way met à mal le prédicteur de cache L1D 

Il ne s’agit pas de nouvelles attaques selon AMD…

… les chercheurs persistent et signent

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (11)


Bonsoir.



« Les identifiants matériels seront falsifiés, le contenu numérique sera extrait et les données des disques durs chiffrés seront décryptées »
Je comprends pas bien ce passage, on parle d’un cas spécifique non?



Exemple, si on chiffre son disque dur avec un conteneur LVS sous linux et une clef, ou si on utilise bitesecure sous windows 10, on sera impacté par la fuite de cette clef??? J’ai du mal à comprendre le lien.



Sinon ça craint ces grosses failles récentes. :/ On a du mal à voir l’impact et le niveau de facilité pour un attaquant d’en faire ce qu’il veut. :/


C’est violent quand même… La fin d’internet après ^^


Effectivement, il serait intéressant d’avoir des infos sur le type de risque encouru pour chaque type d’utilisateur : un particulier avec un pc perso connecté au net, un utilisateur dans un LAN d’entreprise, etc. Telle attaque doit avoir un accès physique au PC, ou un accès réseau depuis une session d’un PC du LAN de l’entreprise… Quels risques encourus : ransomware, vol de données,… ? Quelles ont été les exploitations des précédentes failles sur le terrain (spectre et autres), qui a été impacté… ?


Enfin, une équipe de chercheurs emmenée par Moritz Lipp se penche sur le cas des CPU AMD



L’équipe de chercheurs a été payé par Intel donc le but c’était de taper sur AMD



xillibit a dit:


_Enfin, une équipe de chercheurs emmenée par Moritz Lipp se penche sur le cas des CPU AMD_L’équipe de chercheurs a été payé par Intel donc le but c’était de taper sur AMD




Alors que c’est AMD qui aurait dû le faire et jouer la transparence, après c’est de bonne guerre, AMD avait été dans les premiers à pointer du doigt que les CPU INTEL étaient impactés par des failles.



Burn2 a dit:


Bonsoir.« Les identifiants matériels seront falsifiés, le contenu numérique sera extrait et les données des disques durs chiffrés seront décryptées » Je comprends pas bien ce passage, on parle d’un cas spécifique non?Exemple, si on chiffre son disque dur avec un conteneur LVS sous linux et une clef, ou si on utilise bitesecure sous windows 10, on sera impacté par la fuite de cette clef??? J’ai du mal à comprendre le lien.Sinon ça craint ces grosses failles récentes. :/ On a du mal à voir l’impact et le niveau de facilité pour un attaquant d’en faire ce qu’il veut. :/




De ce que j’ai compris ça serait qu’en ayant la master key de ton processeur, toutes les clés de chiffrement privé qui a priori est stocké en mémoire chiffrées avec la master key serait toutes déchiffrable et accessible en clair. Et du coup, oui, tes clé de chiffrement que tu es en train d’utiliser comme celle des partition chiffré, celle pour ton gestionnaire de mots de passe ou celle pour les DRM, tout ça risque d’être potentiellement accessible en clair.



tazvld a dit:


De ce que j’ai compris ça serait qu’en ayant la master key de ton processeur, toutes les clés de chiffrement privé qui a priori est stocké en mémoire chiffrées avec la master key serait toutes déchiffrable et accessible en clair. Et du coup, oui, tes clé de chiffrement que tu es en train d’utiliser comme celle des partition chiffré, celle pour ton gestionnaire de mots de passe ou celle pour les DRM, tout ça risque d’être potentiellement accessible en clair.




Ce qui veut dire que tout chiffrement ne sert à rien si exécuté sur une machine à base de chipset/CPU Intel :eeek2:


Merci.
Si c’est bien ça ça craint.
Reste la question de savoir s’il faut un accès à la machine etc.



Bref l’impact réel.




tazvld a dit:


De ce que j’ai compris ça serait qu’en ayant la master key de ton processeur, toutes les clés de chiffrement privé qui a priori est stocké en mémoire chiffrées avec la master key serait toutes déchiffrable et accessible en clair. Et du coup, oui, tes clé de chiffrement que tu es en train d’utiliser comme celle des partition chiffré, celle pour ton gestionnaire de mots de passe ou celle pour les DRM, tout ça risque d’être potentiellement accessible en clair.



De ce que je comprends, ce n’est pas le processeur qui est le problème ici (la 1ère faille), mais les “chipsets” et ROM intel qui implémentent cette cochonnerie de CSME (qui implémente, entre autre, TPM, qui est le descendant de Palladium).
Tout pleins de trucs que j’exècre, car leur principe est d’identifier, contrôler, vérifier un système à l’insu de son/ses utilisateurs, avec des secrets qu’ils ne peuvent pas contrôler.
Très pratique en entreprise (paraît-il) et complètement con sur un système de particulier qui aimerai bien être le seul à avoir les clés de SA maison.
Heureusement, toujours de ce que j’en comprends, si on utilise aucune des fonctions proposés par CSME, le risque me semble très limité. Et ce n’est peut-être même pas exploitable a distance. Et en plus comme le dit l’article cela dépendra de l’obtention de la fameuse clé hardware du SKS.
Mais une fois qu’elle aura été obtenu, pour les entreprises qui utilisent activement CSME, ça risque de ne pas être la joie.



Pour un utilisateur Linux qui chiffre son disque dur par exemple avec LUKS, j’ai l’impression qu’il n’y a aucun risque particulier lié à cette faille. J’ai pas l’impression que ce soit dans la philosophie de LUKS de se fier à un truc comme CSME que ce soit pour lui fournir un secret (mot de passe, clé, etc…), ou pour stocker un secret.
Un disque qui peut être déchiffrer sur différents PC sans manip particulière (du moment qu’on lui fourni le secret quand il le réclame) ne doit pas dépendre de CSME, à mon avis.
En entreprise cela peu être une toute autre histoire.



tazvld a dit:


Et du coup, oui, tes clé de chiffrement que tu es en train d’utiliser comme celle des partition chiffré, celle pour ton gestionnaire de mots de passe ou celle pour les DRM, tout ça risque d’être potentiellement accessible en clair.




Les clés gérées par le processeur: Par exemle Secure Boot, ou bitlocker en mode sans code. Tous certificats (ou chiffrement symétrique) gérés en logiciel (clé privée dans un fichier) ne seront pas impactés. Ex concret le gestionnaire de mot de passe ne sera pas impacté, tout comme les certificats HTTPS. Bref j’ai surtout l’impression que les pbs seont cotés machine virtuelle et DRM



tazvld a dit:


De ce que j’ai compris ça serait qu’en ayant la master key de ton processeur, toutes les clés de chiffrement privé qui a priori est stocké en mémoire chiffrées avec la master key serait toutes déchiffrable et accessible en clair. Et du coup, oui, tes clé de chiffrement que tu es en train d’utiliser comme celle des partition chiffré, celle pour ton gestionnaire de mots de passe ou celle pour les DRM, tout ça risque d’être potentiellement accessible en clair.




Pas exactement. En gros ils suspectent (car pour l’instant ils savent pas le faire) qu’il est possible d’extraire la master key du CSME, master-key qui est utilisée pour toutes les fonctionnalités de sécurité fourni par le CSME.



Pour prendre l’exemple Bitlocker, si tu chiffres ton disque avec, en stockant la clé dans le fTPM de ton processeur intel, il serait potentiellement possible d’extraire la hardware key du CSME et à partir de la récupérer la clé Bitlocker dans le fTPM et déchiffrer ton disque.