Connexion
Abonnez-vous

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

Pass VIP

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.

Le 13 août à 14h28

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

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Faut juste changer de processeur, ça va :transpi:
votre avatar
La carte mère plutôt non ?
votre avatar
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é.
votre avatar
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).
votre avatar
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.
votre avatar
Ç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)
votre avatar
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.
votre avatar
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 ?
votre avatar
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.
votre avatar
yes pardon :)
votre avatar
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.
votre avatar
"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
votre avatar
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:
learn.microsoft.com 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!
votre avatar
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:
votre avatar
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...
votre avatar
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 ?
votre avatar
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) ?
votre avatar
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...
votre avatar
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) ?
votre avatar
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 ^^
votre avatar
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.
votre avatar
Totalement HS : magnifique ce cafard de Vitruve
votre avatar
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.
votre avatar
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.
votre avatar
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....
votre avatar
Ç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).
votre avatar
Un truc me parait peu clair... où est stocké le code malicieux ? Nos processeurs ont de la mémoire non volatile ???
votre avatar
Toute la description technique est peu claire, elle est peu claire aussi dans l'article de Wired.
votre avatar
cf mon commentaire plus haut
Une clarification sur l'emplacement exact du code malicieux qui est injecté (si connu) serait bienvenue.
votre avatar
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.
votre avatar
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.
votre avatar
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.
votre avatar
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".
votre avatar
Construire un rootkit SMM en modifiant la SMRAM c'est connu depuis un moment:

cyber.gouv.fr 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.
votre avatar
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...
votre avatar
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
votre avatar
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).
votre avatar
Mais… un espace noyau, sous Windows, ça veut dire : un simple pilote.
Sous Linux, c'est pareil. Inutile de pointer particulièrement Windows.
votre avatar
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
votre avatar
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.
votre avatar
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à.
votre avatar
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
votre avatar
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/
votre avatar
« un millier de fois »

Espèce de nerd.
votre avatar
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:
votre avatar
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:
votre avatar
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é.
votre avatar
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
votre avatar
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:
votre avatar
d'où ton pseudo ? :D
votre avatar
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:

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

Fermer