Sinkclose : tous les processeurs AMD sont vulnérables à l’insertion de code malveillant

Sinkclose : tous les processeurs AMD sont vulnérables à l’insertion de code malveillant

Pass VIP

52

Sinkclose : tous les processeurs AMD sont vulnérables à l’insertion de code malveillant

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.

À 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.

Commentaires (52)


Faut juste changer de processeur, ça va :transpi:

eglyn

Faut juste changer de processeur, ça va :transpi:
La carte mère plutôt non ?

eliumnick

La carte mère plutôt non ?
Je crois oui...
Ç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é.

xlp

Je crois oui...
Ç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é.
Je n'ai pas bien compris au final si ça permettait de réécrire l'EFI ou si c'est un autre firmware dans le CPU ?? Si c'est "juste" l'EFI c'est relativement "facile" de flasher une ROM SPI avec un programmateur externe (j'en ai un, déjà fait pour des machines dont Windows a foiré la MAJ).

Puissante-Verveine-Éthérée

Je n'ai pas bien compris au final si ça permettait de réécrire l'EFI ou si c'est un autre firmware dans le CPU ?? Si c'est "juste" l'EFI c'est relativement "facile" de flasher une ROM SPI avec un programmateur externe (j'en ai un, déjà fait pour des machines dont Windows a foiré la MAJ).
C'est relativement "facile" mais c'est économiquement déraisonnable, c'est le vrai problème.

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.

Puissante-Verveine-Éthérée

Je n'ai pas bien compris au final si ça permettait de réécrire l'EFI ou si c'est un autre firmware dans le CPU ?? Si c'est "juste" l'EFI c'est relativement "facile" de flasher une ROM SPI avec un programmateur externe (j'en ai un, déjà fait pour des machines dont Windows a foiré la MAJ).
Ça permet probablement de réécrire l'EFI (je ne suis au courant que d'une puce de flash par carte mère).

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 :D

Sinon flasher peut se faire avec un Pi, un arduino... Attention à la tension d'alimentation de la puce (et du flasher)

xlp

Ça permet probablement de réécrire l'EFI (je ne suis au courant que d'une puce de flash par carte mère).

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 :D

Sinon flasher peut se faire avec un Pi, un arduino... Attention à la tension d'alimentation de la puce (et du flasher)
Chez AMD je ne sais pas, mais si chez Intel les firmwares sont en effet signés (c'est une des raisons pour lesquelles une recopie de boot flash d'une machine vers une autre, pourtant identique, ne fonctionnera pas ; une autre raison pouvant être le stockage d'une partie des paramètres de calibration DDR afin d'accélérer le démarrage, là il faudra attendre possiblement jusqu'à 90 jours, fréquence à laquelle on les refait systématiquement, pour compenser des dérives, ou pouvoir bidouiller la RTC ou retirer la pile pour que ces calibrations puissent arriver un peu aléatoirement, typiquement sur qq dizaines d'essais)... il faut bien pouvoir upgrader les boot-flash!

=> 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.

yl

Chez AMD je ne sais pas, mais si chez Intel les firmwares sont en effet signés (c'est une des raisons pour lesquelles une recopie de boot flash d'une machine vers une autre, pourtant identique, ne fonctionnera pas ; une autre raison pouvant être le stockage d'une partie des paramètres de calibration DDR afin d'accélérer le démarrage, là il faudra attendre possiblement jusqu'à 90 jours, fréquence à laquelle on les refait systématiquement, pour compenser des dérives, ou pouvoir bidouiller la RTC ou retirer la pile pour que ces calibrations puissent arriver un peu aléatoirement, typiquement sur qq dizaines d'essais)... il faut bien pouvoir upgrader les boot-flash!

=> 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.
Ta réponse casse un mythe pour moi. Je pensais les firmwares signés à la distribution. Du coup les images BIOS/UEFI ont quoi, juste une somme de contrôle ?
(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 ?

xlp

Ta réponse casse un mythe pour moi. Je pensais les firmwares signés à la distribution. Du coup les images BIOS/UEFI ont quoi, juste une somme de contrôle ?
(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 ?
Il est possible de signer la capsule d'upgrade (fichier genre cpio) globalement, maintenant la sécurité de l'affaire peut dépendre de l'implémentation du fabricant et en particulier de sa volonté de payer 1 image BIOS sur les mobo qu'il fabrique ou les deux possibles (car au delà de son développement, chaque image flashée se paie!). Dans un cas ce sera sans doute le soft d'upgrade qui vérifiera, dans l'autre ce sera le BIOS upgradant l'autre au redémarrage. Je ne connais pour ma part que le second cas. Mais c'est indépendant de ce qui sera signé une fois flashé en SPI.

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.
Modifié le 20/08/2024 à 16h22

Historique des modifications :

Posté le 20/08/2024 à 16h10


Il est possible de signer la capsule d'upgrade (fichier genre cpio) globalement, maintenant la sécurité de l'affaire peut dépendre de l'implémentation du fabricant et en particulier de sa volonté de payer 1 image BIOS sur les mobo qu'il fabrique ou les deux possibles (car au delà de son développement, chaque image flashée se paie!). Dans un cas ce sera sans doute le soft d'upgrade qui vérifiera, dans l'autre ce sera le BIOS upgradant l'autre au redémarrage. Je ne connais pour ma part que le second cas. Mais c'est indépendant de ce qui sera signé une fois flashé en SPI.

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.

eliumnick

La carte mère plutôt non ?
yes pardon :)
1. Créer un processus qui execute des instructions avec un privilège max (SMM).
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.
"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 ?"


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 à 15h26

Historique des modifications :

Posté le 13/08/2024 à 15h25


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 ?


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 à utiliser 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

Posté le 13/08/2024 à 15h25


"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 ?"


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 à utiliser 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

argument peu recevable AMHA.
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:
https://learn.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-amd-processors
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!
Modifié le 13/08/2024 à 16h45

Historique des modifications :

Posté le 13/08/2024 à 16h35


argument peu recevable AMHA.
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:
https://learn.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-amd-processors

ou a 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 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!

Posté le 13/08/2024 à 16h36


argument peu recevable AMHA.
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:
https://learn.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-amd-processors
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 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!

Moi qui pensais que c'était pour que les gamer puissent y cacher un logiciel de triche indétectable par les logiciels anti-triche. :fumer:
En première intention, en effet on peut se dire que c'est critique pour des serveurs ou machines stratégiques.
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...
Et je fais comment moi pour justifier le changement de matériel à ma femme avec un tel commentaire ? :o

Édit : rien à voir mais comment on fait pour citer un (passage de) commentaire ?
Modifié le 14/08/2024 à 17h43

Historique des modifications :

Posté le 14/08/2024 à 17h41


Et je fais comment moi pour justifier le changement de matériel à ma femme avec un tel commentaire ? :o

Mais s'il faut avoir un accès avec les privilèges de type "ring 0", il faut convaincre le noyau. En supposant que ce n'est pas possible et que ce noyau n'a pas de failles connues, il ne me vient à l'esprit pour aboutir à l'attaque que une clé usb insérée au démarrage de la machine, avec un programme de démarrage ayant par défaut le privilège "ring 0" (comme tous les programme de démarrage si j'ai bien compris). Sauf que si le "SecureBoot" est activée, et à supposer que la signature du programme de démarrage ne correspond à rien d'officiel, et à supposer que les "officiels" ne réalisent pas l'attaque, est-ce que cela est réellement exploitable en ayant accès à la machine comme c'est indiqué dans l'article (vrai question) ?
Modifié le 13/08/2024 à 15h38

Historique des modifications :

Posté le 13/08/2024 à 15h37


Mais s'il faut avoir un accès avec les privilèges de type "ring 0", il faut convaincre le noyau. En supposant que ce n'est pas possible et que ce noyau n'a pas de failles connus, il ne me vient à l'esprit que une clé usb insérée au démarrage de la machine, avec un programme de démarrage ayant par défaut le privilège "ring 0" (comme tous les programme de démarrage si j'ai bien compris). Sauf que si le "SecureBoot" est activée, et à supposer que la signature du programme de démarrage ne correspond à rien d'officiel, et à supposer que les "officiels" ne réalisent pas l'attaque, est-ce que cela est réellement exploitable en ayant accès à la machine comme c'est indiqué dans l'article (vrai question) ?

Pour le coup, le secure boot est parfois désactivé sur des machines ayant un OS un peu hors normes (certains Linux qui vont servir d'hyperviseur), donc ça peut quand-même faire des dégâts...

Kara(Wo)Man

Pour le coup, le secure boot est parfois désactivé sur des machines ayant un OS un peu hors normes (certains Linux qui vont servir d'hyperviseur), donc ça peut quand-même faire des dégâts...
Oui je suis d'accord. Après, sans vouloir entrer dans le troll, est-ce absolument nécessaire de sortir d'une distribution un peu commune si on veut un hyperviseur (je suis pas vraiment connaisseur du domaine) ?

JNSON

Oui je suis d'accord. Après, sans vouloir entrer dans le troll, est-ce absolument nécessaire de sortir d'une distribution un peu commune si on veut un hyperviseur (je suis pas vraiment connaisseur du domaine) ?
Oh, tout à fait d'accord que ça n'est pas vraiment une bonne idée, mais je connais des admins sys qui ont des opinions très tranchées sur la distrib à utiliser, tout en pestant contre le Secure Boot qui les bride ^^

Kara(Wo)Man

Pour le coup, le secure boot est parfois désactivé sur des machines ayant un OS un peu hors normes (certains Linux qui vont servir d'hyperviseur), donc ça peut quand-même faire des dégâts...
En complément de ma réponse précédente, il m'est aussi arrivé de signer moi même mes noyaux pour garder le SecureBoot. Il faut par contre installer sa clé publique dans le BIOS/UEFI. C'est plus pénible, mais c'est faisable.
Totalement HS : magnifique ce cafard de Vitruve
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 tard."


2017 au plus tôt serait plus juste.
J'écrivais justement hier sur la politique des correctifs d AMD sur le billet de developpez.com
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.
J'imagine que du coup, il doit être possible de créer une clef USB bootable qui va réécrire cette zone de mémoire particulière avec les données d'origine en fonction du processeur trouvé sur la machine ?
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 à 16h54

Historique des modifications :

Posté le 13/08/2024 à 16h49


J'imagine que du coup, il doit être possible de créer une clef USB bootable qui va réécrire cette zone de mémoire particulière avec les données d'origine en fonction du processeur trouvé sur la machine ?

Ça revient peut-être à reflasher le BIOS.
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).
Modifié le 13/08/2024 à 20h49

Historique des modifications :

Posté le 13/08/2024 à 19h20


Ça revient peut-être à reflasher le BIOS.
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 ça fonctionne 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).

Un truc me parait peu clair... où est stocké le code malicieux ? Nos processeurs ont de la mémoire non volatile ???
Toute la description technique est peu claire, elle est peu claire aussi dans l'article de Wired.

fred42

Toute la description technique est peu claire, elle est peu claire aussi dans l'article de Wired.
cf mon commentaire plus haut
Une clarification sur l'emplacement exact du code malicieux qui est injecté (si connu) serait bienvenue.
Modifié le 13/08/2024 à 18h04

Historique des modifications :

Posté le 13/08/2024 à 17h47


cf mon commentaire plus haut
Une clarification sur l'emplacement exact du code malicieux qui est injecté (si connu) serait bienvenue.

Posté le 13/08/2024 à 18h02


cf mon commentaire plus haut
Une clarification sur l'emplacement exact du code malicieux qui est injecté (si connu) serait bienvenue.

Edit : il est fort probable que ce soit dans le firmware du CPU et que reflasher l'EFI ne serve à rien... Je suis hors de ma zone de compétence.

Posté le 13/08/2024 à 18h02


cf mon commentaire plus haut
Une clarification sur l'emplacement exact du code malicieux qui est injecté (si connu) serait bienvenue.

Edit : il est fort probable que ce soit dans le firmware du CPU et que reflasher l'EFI ne serve à rien... Je suis hors de ma zone de compétence, je laisse les experts confirmer.

Puissante-Verveine-Éthérée

cf mon commentaire plus haut
Une clarification sur l'emplacement exact du code malicieux qui est injecté (si connu) serait bienvenue.
Mon commentaire était un appel pour un lien vers un article clair sur l'aspect technique, mais j'ai peur qu'il n'existe pas pour le moment, même en anglais.
En russe, peut-être, mais je ne parle pas russe. :fumer:

Mais si quelqu'un a un tel lien, qu'il le fournisse ou a minima des explications sur comment fonctionne Tclose et le SMM.

fred42

Mon commentaire était un appel pour un lien vers un article clair sur l'aspect technique, mais j'ai peur qu'il n'existe pas pour le moment, même en anglais.
En russe, peut-être, mais je ne parle pas russe. :fumer:

Mais si quelqu'un a un tel lien, qu'il le fournisse ou a minima des explications sur comment fonctionne Tclose et le SMM.
L'article parle de connecter un programmateur SPI, donc là code doit être dans la flash de la carte mère (à moins que le CPU comporte une flash intégrée pour le début du boot).

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.
Modifié le 13/08/2024 à 19h08

Historique des modifications :

Posté le 13/08/2024 à 19h08


L'article parle de connecter un programmateur SPI, donc là code doit être dans la flash de la carte mère (à moins que le CPU comporte une flash intégrée pour le début du boot).

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 cote UEFI, ou une lecture de la flash SPI depuis l'OS pourraient très bien retourner un résultat normal.

hwti

L'article parle de connecter un programmateur SPI, donc là code doit être dans la flash de la carte mère (à moins que le CPU comporte une flash intégrée pour le début du boot).

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.
On peut tous faire des suppositions, mais comme on n'a pas assez d'informations (c'est volontaire de la part de ceux qui ont trouvé la faille pour donner plus de temps pour colmater), on a peu de chance de tomber juste.
Un pointeur vers une doc technique AMD pourrait aider à comprendre.

hwti

L'article parle de connecter un programmateur SPI, donc là code doit être dans la flash de la carte mère (à moins que le CPU comporte une flash intégrée pour le début du boot).

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.
Si c'est bien le cas (ce dont je ne suis pas sûr), alors le chercheur est un peu trop catégorique. Il y a quelques personnes ou professionnels capables de reflasher une rom SPI (correctement ça c'est une autre histoire) à partir du binaire du fabricant. Souvent il y a des soucis avec la ME region pour Intel (AMD j'ai moins d'expérience), qu'il faut remettre à zéro car unique à chaque machine sous peine de fonctionnement lent ou erratique. Je l'ai déjà fait plusieurs fois sur des PC portables "briqués".

fred42

Mon commentaire était un appel pour un lien vers un article clair sur l'aspect technique, mais j'ai peur qu'il n'existe pas pour le moment, même en anglais.
En russe, peut-être, mais je ne parle pas russe. :fumer:

Mais si quelqu'un a un tel lien, qu'il le fournisse ou a minima des explications sur comment fonctionne Tclose et le SMM.
Construire un rootkit SMM en modifiant la SMRAM c'est connu depuis un moment:

https://cyber.gouv.fr/sites/default/files/IMG/pdf/Cansec_final.pdf
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.

127.0.0.1

Construire un rootkit SMM en modifiant la SMRAM c'est connu depuis un moment:

https://cyber.gouv.fr/sites/default/files/IMG/pdf/Cansec_final.pdf
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.
Merci.

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 :
[A,T]Close allows the SMI handler to access the MMIOspace located in the same address region as the [A,T]Seg. When the SMI handler is finished accessing the MMIOspace, it must clear the bit. Failure to do so before resuming from SMM causes the CPU to erroneously read the save state from MMIO space.


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. :D
Mais c'est peut-être ça qu'ils ont lu dans la doc AMD...

fred42

Merci.

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 :
[A,T]Close allows the SMI handler to access the MMIOspace located in the same address region as the [A,T]Seg. When the SMI handler is finished accessing the MMIOspace, it must clear the bit. Failure to do so before resuming from SMM causes the CPU to erroneously read the save state from MMIO space.


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. :D
Mais c'est peut-être ça qu'ils ont lu dans la doc AMD...
Pour pinailler, SMM ce n'est pas "du code qui tourne" mais un mode de fonctionnement.
(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. :D
Modifié le 15/08/2024 à 18h03

Historique des modifications :

Posté le 15/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)).


Pour pinailler, SMM ce n'est pas "du code qui tourne" mais un mode de fonctionnement.
(SMM = "System Management" Mode ). Du code qui s'exécute dans ce mode à énormément de privilèges.

Pour le reste, je ne vois rien d'évident dans la spec de AMD qui permet de contourner la sécurité. Le register MSRC001_0113 est en lecture-seule tant qu'on est pas dans le mode SMM. Donc, sur le papier, c'est impossible de modifier le bit TClose 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. :D

Posté le 15/08/2024 à 17h56


Pour pinailler, SMM ce n'est pas "du code qui tourne" mais un mode de fonctionnement.
(SMM = "System Management" Mode ). Du code qui s'exécute dans ce mode à énormément de privilèges.

Pour le reste, je ne vois rien d'évident dans la spec de AMD qui permet de contourner la sécurité. Le register MSRC001_0113 est en lecture-seule tant qu'on est pas dans le mode SMM. Donc, sur le papier, c'est impossible de modifier le bit TClose 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. :D

Posté le 15/08/2024 à 17h58


Pour pinailler, SMM ce n'est pas "du code qui tourne" mais un mode de fonctionnement.
(SMM = "System Management" Mode ). Du code qui s'exécute dans ce mode à énormément de privilèges.

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. :D

Posté le 15/08/2024 à 17h58


Pour pinailler, SMM ce n'est pas "du code qui tourne" mais un mode de fonctionnement.
(SMM = "System Management" Mode ). Du code qui s'exécute dans ce mode à énormément de privilèges.

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. :D

Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.

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).
Modifié le 13/08/2024 à 18h04

Historique des modifications :

Posté le 13/08/2024 à 18h02


Mais… un espace noyau, sous Windows, ça veut dire un simple pilote.

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 d'un botnet, qui dispose déjà de membres avec accès noyau, le temps de déposer la charge utile (à court-terme, donc, limitant le coût).

Posté le 13/08/2024 à 18h03


Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.

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 d'un botnet, qui dispose déjà de membres avec accès noyau, le temps de déposer la charge utile (à court-terme, donc, limitant le coût).

Posté le 13/08/2024 à 18h03


Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.

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 d'un botnet, qui dispose déjà de membres avec accès noyau, le temps de déposer la charge utile (à court-terme, donc, limitant le coût).

Posté le 13/08/2024 à 18h03


Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.

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 d'un botnet, qui dispose déjà de membres avec accès noyau, le temps de déposer la charge utile (à court-terme, donc, limitant le coût).

Posté le 13/08/2024 à 18h04


Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.

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).

Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.


Sous Linux, c'est pareil. Inutile de pointer particulièrement Windows.

fred42

Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.


Sous Linux, c'est pareil. Inutile de pointer particulièrement Windows.
Il est vrai que pointer Windows lorsque l'on parle de code malveillant est inadapté à la réalité.

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é.

:D

Berbe

Il est vrai que pointer Windows lorsque l'on parle de code malveillant est inadapté à la réalité.

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é.

:D
Cette vulnérabilité a aussi un fort intérêt sur des serveurs sous Linux. Ne réfléchir qu'aux PC pour taper sur Windows me semble malvenu.

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.
Un revendeur de matos d'occasion peu scrupuleux a une énorme backdoor qui lui est offerte ici. Le mec qui lui rachète le pc aura beau réinstaller l'OS, elle sera toujours là.
C'est pas comme si certaines agences avaient des centre de ré-emballage de matos informatique après modification.
Oh Wait

how the NSA tampers with US-made internet routers

Dj

C'est pas comme si certaines agences avaient des centre de ré-emballage de matos informatique après modification.
Oh Wait

how the NSA tampers with US-made internet routers
Ou comme si certains ne venaient pas des , mêlés à l’armée
https://www.bleepingcomputer.com/news/security/ceo-who-sold-fake-cisco-devices-to-us-military-gets-6-years-in-prison/
« un millier de fois »

Espèce de nerd.
Ouais, il se la pète un peu pour sous-entendre que la faille, elle était super méga difficile à voir et très subtil à détecter mais que lui après acharnement, ben elle lui ait apparue... dans le texte...
:fumer:
Modifié le 13/08/2024 à 22h39

Historique des modifications :

Posté le 13/08/2024 à 22h38


Ouais, il se la pète un peu pour sous-entendre que la faille, elle était super méga difficile à voir et très subtil à détecter mais que lui après acharnement, ben elle lui ait apparue... dans le texte...

:fumer:

En ce moment quand j'achète une pièce, c'est toujours le pire choix possible.

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% :eeek2:

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 :craint:

Je tourne sur un Ryzen 3700X et comme par hasard c'est LA gamme qui ne sera pas corrigé :censored:

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 :fume:

L'informatique depuis 10 ans c'est n'importe quoi... On ne fabrique plus comme avant :phiphi:
Modifié le 14/08/2024 à 02h28

Historique des modifications :

Posté le 14/08/2024 à 02h27


En ce moment quand j'achète une pièce, c'est toujours le pire choix possible.

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% :eeek2:

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 :craint:

Je tourne sur un Ryzen 3700X et comme par hasard c'est LA gamme qui ne sera pas corrigé :censored:

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 :fume:

L'informatique depuis 10 ans c'est n'importe quoi... On ne fabrique plus comme avant :phiphi:

J'ai un 13700K et j'ai l'habitude de faire de l'OC manuel donc pour 5.5GHz je m'étais aperçu qu'il ne fallait que 1.31V au lieu des 1.5 que le VID demandais. J'ai du coup passer le CPU en manuel à 5.5GHz à 1.31V et donc je pense qu'il n'y aura aucun impact en perf à moins qu'il soit oxydé.
Tu n'aurais pas acheté par hasard à l'époque un Dell XPS M1330 (connu à l'époque pour son énorme défaut de conception, carte graphique Geforce GS8400M qui surchauffe et finit par griller toute seule au bout de qques années car mal refroidie)? :D

Patch

Tu n'aurais pas acheté par hasard à l'époque un Dell XPS M1330 (connu à l'époque pour son énorme défaut de conception, carte graphique Geforce GS8400M qui surchauffe et finit par griller toute seule au bout de qques années car mal refroidie)? :D
Non pas celui-là. Tu ne pourras pas me faire endosser la responsabilité :D

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 :fume:

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 :mad2:
d'où ton pseudo ? :D

EricB

d'où ton pseudo ? :D
L'origine est liée à une config qui a pris très cher il y a 20 ans mais ce n'était pas supposé devenir une tendance :fume:
Fermer