Sinkclose : tous les processeurs AMD sont vulnérables à l’insertion de code malveillant
Pass VIP
AMD a un sérieux problème de sécurité sur les bras : des chercheurs ont trouvé le moyen de détourner un mécanisme de ses processeurs pour rendre des malwares pratiquement impossibles à déloger. La vulnérabilité, d’une sévérité de 7,5 sur 10 (CVSS 3.1), n’est atténuée que par l’obligation pour le pirate de disposer d’un accès à l’espace noyau sur la machine à infecter.
Le 13 août à 14h28
8 min
Sécurité
Sécurité
À la DEF CON qui se tient actuellement à Las Vegas, deux chercheurs ont présenté samedi leur travail sur les processeurs AMD. Enrique Nissim et Krzysztof Okupski, tous deux de la société de sécurité IOActive, ont débusqué l’année dernière un gros problème dans toutes les puces de l’entreprise remontant au moins jusqu’en 2006.
Même si la faille, estampillée CVE-2023-31315, ne peut être réellement exploitée que lorsqu’on possède déjà un accès à l’espace noyau du système, elle peut permettre l’installation d’un malware presque impossible à déloger. Une zone privilégiée pour un bootkit, capable de se relancer à tous les démarrages et que même un formatage complet du disque dur et une réinstallation du système d’exploitation ne peuvent effacer.
Des correctifs ont déjà été diffusés ou le seront bientôt, mais pas pour tout le monde.
Un mécanisme de compatibilité dans les processeurs AMD
La faille est complexe et réside dans une caractéristique – jugée « obscure » par les chercheurs – dans les processeurs AMD. Il faut d’abord évoquer TSeg. Il s’agit d’une protection mise en place par AMD pour protéger les systèmes d’exploitation d’écrire dans une zone spécifique de la mémoire, réservée au System Management Mode (SMM). Cette zone est connue sous le nom de SMRAM, pour System Management Random Access Memory. Le SMM a une grande importance : il effectue de nombreuses tâches en arrière-plan, vérifie l’alimentation, le refroidissement et autres. Son code est exécuté avant même que le système d’exploitation ne démarre.
Vient ensuite TClose. Cette fonction a été ajoutée il y a des années par AMD dans ses puces pour permettre aux systèmes d’exploitation de rester compatibles avec des mécanismes plus anciens pouvant se servir des mêmes adresses en mémoire que la SMRAM. Quand elle est activée – ce qu’elle est par défaut – les adresses mémoire sont « remappées » vers cette zone, en cas de besoin.
Que permet la faille ? De rediriger les données souhaitées vers cette zone protégée. Et par « données souhaitées », il faut comprendre un code malveillant, dont les instructions vont être remappées vers le System Management Mode, via TClose. De là, le code obtient non seulement un emplacement très protégé, mais il acquiert également les privilèges les plus élevés, supérieurs à ceux du noyau ou de l’hyperviseur, selon le type de configuration.
La faille a été nommée « Sinkclose » par les chercheurs, un mélange de « Sinkhole » – en référence à une faille du SMM trouvée chez Intel en 2015 – et TClose, la fonction dans laquelle réside le problème.
Un ordinateur « bon à jeter »
Enrique Nissim et Krzysztof Okupski ont indiqué à Wired qu’ils avaient décidé de se plonger dans l’architecture des processeurs AMD il y a deux ans. Ils estimaient en effet qu’elle n’avait pas été suffisamment examinée, l’attention étant surtout tournée vers Intel. Mais ayant observé des gains réguliers de parts de marché, particulièrement dans le domaine des entreprises et des centres de données (via la gamme EPYC), ils ont creusé.
Enrique Nissim a notamment indiqué qu’il avait lu la page de la documentation d’AMD contenant la faille « un millier de fois ». « Et c'est à la mille et unième fois que je l'ai remarquée », a-t-il ajouté.
Sur la gravité de leur découverte, Krzysztof Okupski propose un scénario : « Imaginez que des pirates d'un État-nation ou quiconque veuille persister sur votre système. Même si vous effacez votre disque dur, il sera toujours là. Il sera presque indétectable et presque impossible à réparer ».
Presque ? Selon le chercheur, c’est faisable en théorie. Il faudrait établir une connexion physique à une certaine partie des puces mémoire de l’ordinateur via un outil spécifique (reprogrammeur SPI Flash) et procéder à un examen approfondi de la mémoire pour vérifier la présence d’un code malveillant. Un processus long et laborieux, qu’Okupski résume ainsi : « En fait, vous devez jeter votre ordinateur ».
Des droits élevés à l’entrée
Un seul facteur empêche la faille d’être considérée comme critique, mais il est de taille : le ou les pirates doivent avoir déjà établi un accès au système d’exploitation et se débrouiller pour obtenir des droits d’accès au noyau. Pour rappel, nous avons évoqué ces droits dans une description du fonctionnement des solutions de sécurité, dans le cadre de la panne mondiale CrowdStrike.
Ce n’est pas simple, mais loin d’être impossible. Les deux chercheurs indiquent ainsi que des vulnérabilités de ce type sont découvertes presque tous les mois dans Windows et Linux. En outre, si l’on parle de pirates soutenus par des États-nations, alors ils « ont déjà des exploits de noyau pour tous ces systèmes », affirme Enrique Nissim.
Posséder une telle faille ne fait cependant pas tout. Selon le type de machine que l’on souhaite viser, il sera peut-être nécessaire d’obtenir un accès physique à la machine. Dans le cas d’un centre de données par exemple, l’opération peut se révéler extrêmement délicate, la sécurité étant intensément scrutée.
Délicate, mais le jeu en vaut la chandelle. Les pirates, après avoir obtenu l’accès, peuvent implanter leur code malveillant dans le processeur AMD et tenter de partir sans laisser de traces. Si l’intrusion n’a pas été remarquée, le code malveillant laissé en SMRAM sera virtuellement indétectable. Pour peu que les pirates aient bien fait leur « travail », ils jouiront d’un emplacement privilégié pour d’autres opérations.
« Si les fondations sont brisées, la sécurité de l'ensemble du système l'est aussi », résume Enrique Nissim.
La délicate question des correctifs
Enrique Nissim et Krzysztof Okupski ont prévenu AMD il y a une dizaine de mois. L’entreprise texane a reconnu le problème et a demandé à ce que les chercheurs attendent avant de détailler leur découverte, ce qu’ils ont accepté. AMD souhaitait pousser plus avant ses investigations et préparer des solutions.
Sur le site de l’entreprise, une page officielle a été mise en ligne pour lister les processeurs touchés. On peut y lire plusieurs éléments importants. D’abord, qu’un certain nombre de processeurs ont déjà été mis à jour ou reçu des mesures d’atténuation depuis le début de l’année. C’est le cas notamment pour les processeurs EPYC de la 1re à la 4e génération.
Ensuite, et bien que les chercheurs aient estimé que Sinkclose était présente sur toutes les puces AMD depuis au moins 2006, on trouve surtout dans la liste des modèles datant de 2017 au plus tôt.
En outre, même les puces référencées ne vont pas toutes obtenir un correctif. Sur les processeurs de bureau par exemple, les Ryzen 3000 n’en auront pas. Concernant les séries 4000 à 8000, les correctifs ont été distribués le 30 juillet. En revanche, sur portable, toutes les références depuis la 3000 ont reçu un correctif au cours des dernières semaines. Pour de nombreuses puces Embedded (EPYC ou Ryzen), le correctif devrait arriver en octobre.
On peut se poser la question sur les processeurs Ryzen 3000 : très populaires à leur lancement, notamment chez les joueurs, pourquoi n’ont-ils pas de correctif, alors qu’AMD a corrigé plusieurs failles dans ces modèles en début d’année ?
Les mises à jour sont proposées depuis plusieurs mois via les constructeurs. Sous Windows normalement, elles doivent être « normalement » disponibles dans Windows Update. À ce stade, on ignore en revanche si elles ont été diffusées sous une forme prioritaire ou rangées dans les mises à jour facultatives (Windows Update > Options avancées > Mises à jour facultatives).
Pour les serveurs, les systèmes embarqués et les ordinateurs sous Linux, la distribution est plus complexe. Tout dépend du système et de ce qui est décidé par les constructeurs.
Sinkclose : tous les processeurs AMD sont vulnérables à l’insertion de code malveillant
-
Un mécanisme de compatibilité dans les processeurs AMD
-
Un ordinateur « bon à jeter »
-
Des droits élevés à l’entrée
-
La délicate question des correctifs
Commentaires (52)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 13/08/2024 à 14h47
Le 13/08/2024 à 14h47
Le 13/08/2024 à 15h13
Le 13/08/2024 à 15h38
Ça me fait me poser des questions... Dans certains cas, faut un accès physique, mais avec un accès physique, on peut flasher le bout de stockage SPI.
J'avais aussi l'impression que le code du SMM était a minima signé.
Le 13/08/2024 à 17h03
Le 14/08/2024 à 02h20
Rénumérer un électronicien compétent pour corriger la carte mère reviendrait à une part non-négligeable -si ce n'est plus cher- que son remplacement par un modèle propre.
Le 14/08/2024 à 17h43
Mais d'une façon générale, si tu as l'accès physique et qu'il n'y a pas de signature, pas besoin d'exploit SMM...
Ton flasher SPI permet sûrement de faire un dump, peut-être une bonne idée
Sinon flasher peut se faire avec un Pi, un arduino... Attention à la tension d'alimentation de la puce (et du flasher)
Le 20/08/2024 à 14h10
=> N'importe quelle image d'upgrade BIOS distribuée pour le type exact de processeur visé permet de récupérer les firmwares non signés, qui le seront alors au 1er démarrage et en utilisant l'ID unique du processeur.
Le 20/08/2024 à 14h49
(Et si signés à la distribution, une recopie devrait marcher, si on ne copie que le firmware).
Donc on en revient à : firmwares non signés à la distribution, donc de toutes façons, pas besoin de faille pour pouvoir changer le code qui tourne en SMM, "suffit" de flasher la machine (soit avec un flasheur hardware auquel cas faut pouvoir déclencher le mécanisme de signature, soit en soft avec une mise à jour par l'UEFI). Exact ?
Modifié le 20/08/2024 à 16h22
Car les firmwares, à commencer par le ME qui a la main avant même la partie x86 chez Intel (une partie est claquée dans le PCH, l'autre chargée en SPI avant le BIOS), sont en effet signés en SPI au 1er (re)démarrage : En fabrication initialement, puis après upgrade BIOS si le FW en question doit être MAJ vs version actuelle.
EDIT/Rajout: Les FW (ME, contrôleur réseau...) pouvant être MAJ indépendamment, à ma connaissance un firmware non signé dont on disposerait et flashé au dediprog ou autre dans la bonne zone (lire le mapping via la FDT, ou Flash Description Table, en début de SPI boot) sera pris en compte et s'auto signera à l'execution.
Le but ici, c'est d'éviter de voir une flash tapée à son insu entre 2 MAJ intentionnelles.
Le 13/08/2024 à 16h43
Le 13/08/2024 à 15h21
2. Définir pour ce processus une zone mémoire (SMRAM) avec un accès ultra protégée (TSeg).
3. Créer une fonctionnalité pour rediriger cette zone mémoire ailleurs (TClose).
4. ...
5. Problème.
Modifié le 13/08/2024 à 15h26
Parce que ca n'a pas d'intérêt.
L'intérêt de l'utilisation de la faille est assez limité en réalité, mis à part les serveurs.
Les méchants pirates iront pas trop s'emmerder à pousser un malware qui va exploiter une faille pour obtenir un accès au noyau, pour installer un code dans SMM, effacer les traces, pour exploiter plus tard.
Les méchants pirates, ils font plus simple, ils t'envoient une facture PDF qui va chiffrer ton PC et te demander des bitcoin
Modifié le 13/08/2024 à 16h45
Certes, il est peu probable que les CPU desktop soient infectés. Mais les CPU dektop AMD commencent à équiper les marchés de PC d'entreprises. Donc cibles potentiellement + intéressantes que le PC de Mme Michou.
Mais si j ai bien pigé, le + gros soucis avec cette faille est qu il est quasi impossible de détecter une infection. On ne peut donc PAS savoir si son CPU est touché!
Qu on puisse pas la réparer est une autre pb, mais si au moins on peut savoir si on est touché, on peut décider de changer de machine.
Un autre pt critique sur les R3000 est qu'il sont supportés par Windows 11. Donc le strict support mini d AMD devrait AMHA correspondre à la liste de Microsoft:
Microsoft
ou à l'inverse, Microsoft pourrait supprimer les CPU non corrigés de cette liste, ce qui ferait encore + de bruit.
Tout les CPU non corrigés par AMD peuvent encore très bien faire tourner les dernières versions de Linux (et même les 1ers Athlon x64 de 2006!). Il serait alors vraiment utile d avoir un outil Linux pour détecter l infection!
Le 13/08/2024 à 17h06
Le 14/08/2024 à 14h29
En réalité, pour peu qu'un toolkit soit développé permettant d'industrialiser l'infection en utilisant un chaînage de failles, on peut se retrouver avec une armée de machines zombies, mobilisables à volonté pour générer du trafic réseau, faire du minage, envoyer du spam, récolter des données personnelles en masse (y compris des données sensibles), servir de point de rebond pour des attaques plus ciblées...
Modifié le 14/08/2024 à 17h43
Édit : rien à voir mais comment on fait pour citer un (passage de) commentaire ?
Modifié le 13/08/2024 à 15h38
Le 14/08/2024 à 14h31
Le 14/08/2024 à 16h00
Le 14/08/2024 à 16h56
Le 14/08/2024 à 16h06
Le 13/08/2024 à 15h47
Le 13/08/2024 à 16h20
Le 13/08/2024 à 16h21
https://securite.developpez.com/actu/361354/La-faille-Sinkclose-presente-dans-des-centaines-de-millions-de-puces-AMD-permet-des-infections-profondes-et-pratiquement-irremediables/
Mais Vincent ici a fait une meilleure analyse: j'avais pas vu le "No fix planned" pour les AMD Ryzen™ 3000 Series Desktop Processors “Matisse”. C est en effet questionable, alors que les 3000 Picasso et Castle Peak (Threadripper) ont un fix.
D'ailleurs, je trouve cela assez choquant que les Threadripper 1900 et 2900 soient aussi ignorés.
Bref, 5 ans de support max pour des CPU PC, c est relativement peu de la part d AMD.
Modifié le 13/08/2024 à 16h54
Comme ça même pas a savoir si on est touché ou pas, on passe la clef sur toutes les machines....
Modifié le 13/08/2024 à 20h49
Mais le code malveillant injecté pourrait peut-être empêcher cette réécriture, où se réinstalller immédiatement.
Peut-être qu'un reflashage via BIOS flashback (pour les cartes mères qui en disposent) pourrait fonctionner, puisque c'est sans CPU.
C'est l'EC (le microcontrôleur qui gère la carte mère) qui lit la clé USB et écrit la flash, donc à moins que le firmware en question, qui est spécifique à chaque carte mère, soit aussi attaqué, c'est plus sûr).
Le 13/08/2024 à 17h27
Le 13/08/2024 à 17h41
Modifié le 13/08/2024 à 18h04
Une clarification sur l'emplacement exact du code malicieux qui est injecté (si connu) serait bienvenue.
Le 13/08/2024 à 18h06
En russe, peut-être, mais je ne parle pas russe.
Mais si quelqu'un a un tel lien, qu'il le fournisse ou a minima des explications sur comment fonctionne Tclose et le SMM.
Modifié le 13/08/2024 à 19h08
Je suppose que la difficulté tient au fait que le code SMM a probablement la capacité de cacher la modification aux couches supérieures (ou au moins d'injecter des modifications pour désactiver les vérifications).
Et donc une vérification de la signature côté UEFI, ou une lecture de la flash SPI depuis l'OS pourraient très bien retourner un résultat normal.
Le 13/08/2024 à 19h24
Un pointeur vers une doc technique AMD pourrait aider à comprendre.
Le 13/08/2024 à 19h27
Le 13/08/2024 à 19h25
République Française
https://labs.ioactive.com/2022/11/exploring-security-configuration-of-amd.html
Ce qui est nouveau c'est de passer par TClose pour tromper la sécurité TSeg.
Pour en savoir plus sur TClose sans être pollué par les résultats "sinkclose", recherchez "MSRC001_0113" dans votre moteur de recherche habituel.
Le 14/08/2024 à 17h56
Donc, le SMM est du code qui tourne en mode 16 bits avec beaucoup de privilèges (appelé ring -2 car a plus de permissions qu'un hyperviseur (ring -1) ou qu'un noyau (ring 0)).
On peut voir ici que les chercheurs avaient accumulé pas mal de connaissance sur les failles. Leur dernière découverte est la suite logique.
Je suis aussi tombé sur la doc AMD et un truc de la doc m'a interpelé justement dans la description de ce registre.
TClose renvoie à AClose pour une partie de son fonctionnement et il y est écrit :
J'ai l'impression que l'on peut faire des trucs intéressants en n'effaçant pas le bit et en forgeant un "save state" sur mesure. Mais je ne connais pas assez ces processeurs pour pousser la réflexion. J'ai perdu l'habitude de lire ce genre de doc, surtout pour le plaisir.
Mais c'est peut-être ça qu'ils ont lu dans la doc AMD...
Modifié le 15/08/2024 à 18h03
(SMM = "System Management" Mode ). Du code qui s'exécute dans ce mode à effectivement énormément de privilèges car il est dans la protection ring -2.
Pour le reste, je ne vois rien d'évident dans la spec de AMD qui permet de contourner la sécurité. Le registre MSRC001_0113 est en lecture-seule tant qu'on n'est pas dans le mode SMM. Donc, sur le papier, c'est impossible de modifier le bit TClose du registre si on est en ring 0.
Je me dis que s'il a fallu 1000 relectures de la spec par des experts pour voir le problème, ca ne doit pas être si evident que cela.
Modifié le 13/08/2024 à 18h04
Et il est de notoriété publique & ancienne que l'écrasante majorité des pilotes est de faible qualité… et pas seulement chez des tiers : j'ai appris à ma grande surprise e la part de connaisseurs que les pilotes Xbox sont connus pour créer des BSoD.
Si on combine le tout, il suffit donc de s'intéresser à un ensemble de pilotes pour couvrir une population satisfaisante pour l'intérêt de l'attaque, et une fois en espace noyau de déployer le bousin. Rien d'insurmontable pour un attaquant motivé par de la persistance à long-terme.
On pourrait même tout simplement imaginer la location de botnets, qui disposent déjà de membres avec accès noyau, le temps de déposer la charge utile (à court-terme donc, limitant le coût).
Le 13/08/2024 à 18h08
Le 15/08/2024 à 20h48
En corollaire, il est tout aussi vrai que soulever Linux en contre-argument du noyau Windows lorsque l'on parle d'un potentiel d'infection massive persistante est tout à fait adapté à la réalité.
Le 15/08/2024 à 21h19
Pour ta gouverne, je n'utilise que du Linux, mais j'essaie de rester objectif sur ces sujets ce qui n'est pas ton cas.
Le 13/08/2024 à 18h34
Le 13/08/2024 à 18h45
Oh Wait
how the NSA tampers with US-made internet routers
Le 13/08/2024 à 22h43
https://www.bleepingcomputer.com/news/security/ceo-who-sold-fake-cisco-devices-to-us-military-gets-6-years-in-prison/
Le 13/08/2024 à 20h21
Espèce de nerd.
Modifié le 13/08/2024 à 22h39
Modifié le 14/08/2024 à 02h28
J'achète un I5-4590. Un jour arrive Spectre et Meltdown. Les patchs sortent, mais mon modèle est celui qui souffrira le plus en terme de performances avec -15%
J'incite une connaissance à acheter un I7-13700K. Récemment survient le problème d'oxydation et de microcode survolté. On a constaté la différence de voltage avant (± 1,51v) et après (± 1,35v) et on tente encore d'évaluer les dégats
Je tourne sur un Ryzen 3700X et comme par hasard c'est LA gamme qui ne sera pas corrigé
Je dispose de 2 écrans LG d'un modèle (plus à la vente) connu plus tard pour un problème récurrent de carte mère mourrante par surchauffe du microprocesseur central.
Conseils à tous : si je publie sur le forum ou ailleurs ce que je compte prendre, PRENEZ AUTRE CHOSE
L'informatique depuis 10 ans c'est n'importe quoi... On ne fabrique plus comme avant
Le 14/08/2024 à 10h30
Le 14/08/2024 à 12h06
Le 14/08/2024 à 13h13
Mais en y repensant, j'ai eu un Razer Blade 15" de 2019 qui a vu son GPU cramer ou se dessouder ou peu importe car il ne fonctionne plus qu'avec l'IGP, ce qui semble être aussi un problème courant de ce modèle
J'ai aussi recommandé il y a un an et demi un Lenovo Legion 16ACHG6 à un ami, sauf que maintenant les prises USB-A sont incapables de délivrer l'énergie demandée par même une bête souris bas de gamme
Le 14/08/2024 à 15h32
Le 16/08/2024 à 02h40