Tavis Ormandy publie une note inquiétante au sujet de Zenbleed, une faille qui touche toutes les puces employant l’architecture AMD Zen 2. Ce chercheur en sécurité salarié de Google note que le problème est global. Il concerne les puces Ryzen 3000, 4000 et 5000 présents dans de nombreux MiniPC. Mais également les processeurs EPYC qui intègrent les serveurs. Si AMD a déjà des patches pour ses processeurs EPYC les plus critiques, les modèles grands public ne seront pas rustinés avant octobre, novembre ou décembre.
Contrairement à beaucoup d’autres failles connues sur les puces AMD et Intel, Zenbleed est un poil plus inquiétant car il ne nécessite pas d’accès physique aux machines pour être exécuté. Il suffit que l’utilisateur surfe sur une page web malicieuse pour qu’il rencontre le problème. D’où l’implication de Google dans l’équation. Le moteur de recherche s’inquiète évidemment de ce genre de soucis.
AMD a reconnu le problème et publié un bulletin de sécurité détaillé et prévoit de publier des correctifs d’ici la fin de l’année. En attendant, la faille permet une extraction de données de votre ordinateur vers un tiers à un rythme assez important. Zenbleed s’activant sur chaque cœur de votre machine il est possible de « pomper » jusqu’à 30 Ko par cœur et par seconde depuis votre PC vers le serveur. Et cela en récupérant des informations de tous les logiciels qui s’exécutent sur votre machine, machines virtuelles comprises.
Des solutions logicielles de protection peuvent être mises en place pour combattre cette faille mais cela aura un impact sur les performances des puces. Difficile de voir la portée et l’impact de Zenbleed pour le moment. Autant pour les entreprises que les particuliers. Le site Toms Hardware a publié une longue liste des puces affectées et des dates anticipées des patches de sécurité qu’AMD devrait fournir. En attendant, je n’ai pas de solutions à proposer si ce n’est de faire attention où vous cliquez ? Si quelqu’un tombe sur une solution efficace, qu’il n’hésite pas à la partager.
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
chaud chaud, j’espère que la version Zen3 en sera excempte
enfin une faille pour la ps5!!!!!on y croit :) enfin j ai envie d’y croire
@OCMan: C’est beau cet optimisme !
@Raph:
C’est mon cas également, Mini PC zen-3 avec un R7-5700G… Mais patience une autre faille nous concernera surement !
Alala gros souci qui me rappelle Spectre Meltdown. Le manque de correctif pour les particuliers est triste étant donné que d’ici à la fin de l’année, l’aspiration de données peut se faire royalement. Je peux comprendre que ça prenne du temps mais plusieurs mois en cyber-sécurité représente une éternité.
Je comprends pas comment ils accèdent au registre cpu avec une page web et un javascript, j’ai grave envie de voir la poc. Autant le reste ok mais là ?!
@to: Tu as un lien dans le billet qui pointe vers les process. C’est assez intéressant à lire.
Mouai. On nous promettait la catastrophe avec Spectre et Meltdown. Et finalement, rien n’est arrivé. Pourtant, il doit y avoir des tonnes de gens qui avaient et qui ont encore un Windows non patché.
La réalité, c’est que les processeurs et Windows sont super sécurisés (sans compter les pares-feu et les antivirus). Et ce depuis facilement Windows Vista. Et à moins d’installer un programme vérolé ou qu’un pirate ait un accès direct à la machine, ou éventuellement que des pirates super doués aient décidé de s’acharner à faire tomber votre PC par Internet, il n’y a aucun risque lors du surf.
@Iodir: Le « aucun risque » me fais tiquer. Perso je ne me risquerais pas à l’écrire.
@Iodir: on peut très bien aspirer des données sans le clamer haut et fort sur Internet. Un État ou un de ses organe n’a aucun intérêt à ce que ça se sache, même sur le darknet.
0Pierre
Je m’y risque parce que ce genre de faille, c’est du tout ou rien. Soit ça fonctionne comme c’est annoncé, à savoir que ça passe à travers toutes les protections logiciels et matériels, soit non.
Dans le premier cas, effectivement, c’est la catastrophe. Dans le deuxième, il n’y a rien. Et vu que pour Spectre et Meltdown, la catastrophe annoncée a fait long feu, personnellement, je ne m’inquiète pas trop.
Mais, peut-être que je me trompe. Wait and see.
@Iodir Si la faille ne nécessite réellement que l’accès à une page web piégée, toutes les protections ou conditions que tu énumères sont inopérantes. Bien sûr, si tu ne surfes que sur des sites connus, il ne devrait y avoir aucun risque (sauf si l’un de ces sites est piraté, ce qui arrive même à des sites ayant pignon sur web).
Pour plus d’informations (texte très technique) : https://web.archive.org/web/20230724143835/https://lock.cmpxchg8b.com/zenbleed.html
@Pierre Lecourt: C’est parce que j’ai lu les détails que je pose la question (et je suis pas le seul visiblement) et rien à part un type sur hacker news qui dit l’avoir fait sans en apporter la preuve. La poc fournie par le chercheur de chez google est en c et asm.
@Iodir: alors, si le serveur web sur lequel tu vas est compromis il peut balancer tout ce que tu lui transmets au hacker, notamment les cookies de session et les mots de passe et là c’est pas bon du tout et pour qu’un serveur web soit compromis il suffit que la machine sur laquelle il tourne soit compromise et pour que la machine soit compromise il suffit qu’une des vm qui tournent dessus soit compromise, imagine le zbeul dans le cloud ou un datacenter
Si je me sers de ma minimachine en tant que server alors je ne crains rien puisqu’il n’a pas le droit de surfer
@Iodir: Vista pouvait rapidement devenir un nid à virus dans ses premières versions, certes j’étais plus naïf en 2006-2007 sur internet :)
L’occasion de rappeler aux gens d’ajouter l’extension NoScript à leur navigateur, pour n’autoriser javascript que sur les sites qu’on connait, et surtout que les scripts nécessaires.
Perso je pense que c’est une grosse exagération, comme chaque fois, et que rien n’arrivera à personne, mais bon.
@Iodir: Ce que je veux dire c’est que je signe mes papiers, si je dis « Aucun risque » et que le risque est là, je commet une faute éditoriale. Par contre écrire ce que tu écris derrière un pseudo ne te fais courir aucun risque. Même si il s’avère que demain un petit malin propose des solutions classiques de scam pour récupérer les mot de passe de sites, services et autres.
Ca affecte les puces zen 1 aussi? ou c’est vraiment que zen 2?
Et sinon,vous restez zen?
@gouroudugange:
Doublement zen, c’est pas bon, il faut l’être triplement!
En effet, si les fonctions optimisées de traitement de chaînes de caractère de la libc (toute entrée utilisateur y passe) et de recopie mémoire (sans doute même celles propres au niveau kernel, au delà de la libc côté espace utilisateur, seront sans doute concernées donc tout ce qui les utilises genre la pile réseau etc…) deviennent ici exploitables cela sent pas bon.
En attendant qu’AMD se bouge, probable que la seule solution soit de forcer l’utilisation des versions non optimisées de toutes les fonctions touchées au niveau kernel et libc…
Sacrée faille quand même ! A côté de ça, Spectre et Meltdown font pale figure, non ?
Ce qui me gène aussi dans l’histoire c’est qu’AMD mettent plusieurs mois pour corriger aussi les processeurs grand public alors que les serveurs EPYC ont déjà été traitées.
Un patch Linux a été publié le jour même, d’après les coms de Tom’s, et apparemment bel et bien efficace. Mais sans que l’on ne connaisse la pénalité sur les perfs (en attendant les nouveaux microcodes en fin d’année…).
Comme souvent avec ce type d’attaque, la désactivation du SMT est bien souvent aussi efficace, mais avec généralement un bon -25% sur les perfs.
Seule Zen 2 est concerné, pas Zen 3 ni Zen/Zen+, pour ceux qui demandent.
(parc contre c’est l’occasion de constater que les Mendocino sont finalement déjà en circulation, 7320U et 7520U)
Pardon, mauvais interprétation de ma part. Dans les coms, il s’agissait de la diffusion des microcodes Threaripper, via une mise à jour Linux. Pas d’un correctif de l’OS pour les autres cpu. Mais il a tout de même essayé d’une commande ou d’un outils qui a l’air efficace chez tous le monde.
Une raison de plus pour traiter tout ce qui est sérieux : admin perso, boulot sur l’architecture Apple Silicon qui ridiculise la concurrence (pour rappel Mac Mini M2 en refurb = 500€), et si besoin, de faire mumuse sur l’architecture x86 à Papa.
Sous Linux, c’est une mitigation via un patch du Kernel qui permet de se prémunir de Zenbleed (sans doute au prix d’un impact sur les perfs, à voir.. sans doute sur Phoronix dans les jours qui viennent) jusqu’à ce que AMD se bouge pour publier le nouveau microcode pour ses puces (décembre, dans mon cas, c’est LONG).
Il est possible de checker les failles CPU avec cet outil : spectre-meltdown-checker (initialement pour les failles pré-citées, mais qui évolue avec l’ensemble des failles découvertes depuis). L’outils est bien suivi et présent dans les dépôts de Manjaro/Arch/… par exemple.
@Makoto: L’auteur de la découverte parle plutôt d’un « chicken bit », donc à priori d’un patch hardware, qui désactiverait une fonctionnalité ou une optimisation du cpu.
https://community.nxp.com/t5/LPC-Microcontrollers/What-is-Chicken-Bit-in-validation/m-p/787574
La bonne nouvelle c’est qu’à priori tous le monde peut le faire chez lui, quelque soit l’os. Mais sans en connaître pour le moment l’impact sur les perfs à l’heure actuelle. Et peut-être faut-il refaire la manip à chaque démarrage?
https://lock.cmpxchg8b.com/zenbleed.html
(voir tout en bas, « Solution »)
@to: En relisant les variables de ton programme, tout simplement. Elles passent tous à un moment donnée ou à un autre par les registres du cpu.
Là ce qui ce passe, c’est une optimisation spécifique de Zen 2 qui est en cause. Lorsqu’elle est exécuté par anticipation, si jamais la prédiction était mauvaise, il faut la rembobiner à l’envers, pour revenir à l’état initial et reprendre le chemin normal.
Mais c’est le déroulement à l’envers de cette optimisation qui est foireux, aboutissant à un état indéfini et causant le registre virtuel initial à se remapper sur un registre physique aléatoire (alors que l’optimisation l’avait détourné de son propre registre physique initial, pour le faire pointer vers un simple bit disant « je suis à zéro). Et il y a toutes les chances que le nouveau registre physique qui lui a été attribué au hasard soit en fait déjà mappé par un autre registre virtuel, appartenant lui à un autre processus.
L’application malveillante peut ensuite tout simplement récupérer le contenu de son registre virtuel en relisant ses variables, et y trouver des données appartenant en fait à quelqu’un d’autre (du fait de ce tour de passe-passe registres physiques/registres virtuels).
D’ailleurs pour ce coup-ci, la désactivation du SMT ne résous rien. Ce registre physique étranger peut tout aussi bien être celui alloué à un processus concurrent, qu’à un processus qui s’est exécuté juste avant lui, par temps partagés.
AMD liste dans sa documentation un bonne douzaine d’instructions cpu mettant en œuvre cette optimisation. Il faut les inclure dans une séquence particulière pour déclenché cette faille. Mais avec un peu de persévérance, ça ne devrait pas être bien compliqué de retrouver un petit bout de code javascript qui produise cette séquence. Puisqu’encore une fois, elle n’est pas unique, de nombreuses variantes fonctionnent.
Après, comme le dit l’auteur, le plus compliqué, c’est de provoquer une prédiction mauvaise. Sans cela, ça ne marche pas. D’où sans doute ses 30ko/s. Il faut optimiser les probabilités d’échec de la prédiction. Mais après, en restant à l’écoute suffisamment longtemps, l’utilisateur finira bien par se loguer quelque part. Faudra juste avoir « un peu de chance ».
(sous réserve que j’ai pas tout compris de travers…)
@TiTi: Merci pour le détail. C’est plus clair !
Alors, pour provoquer l’erreur de prédiction, le chercheur utilise un code assembleur cadencé de façon ultra précise (il explique d’ailleurs qu’en sérialisant juste quelques opcodes cassant les branchements, ça fait du code propre, son « oracle »).
Et, dans ces conditions idéales de laboratoire, il atteint alors les 30kb/s/core.
Pour une attaque par javascript sur le Web, il faut cumuler un tas de conditions inouïes, au final.
C’est peut être possible, mais je ne vois pas de vecteur pour l’instant.
En fait, pour arriver à faire un zenbleed par le web, il faudrait un code javascript qui exploite un bug d’une librairie système qui génère elle-même un zenbleed par inadvertance.
Ce qui signifie que :
– 1/ ça dépend du système (OS), et de sa version
– 2/ ça dépend du navigateur, et sa version
– 3/ ça dépend d’une librairie utilisée par le navigateur, et sa version
– 4/ ça dépend de la configuration système de chaque utilisateur
Beaucoup de si pour un résultat qui parait assez compliqué à obtenir.
En tout cas, sauf erreur grandiose d’un navigateur usuel, il n’existera pas de script général à déployer sur un site web malveillant qui attaquerait tous les ordinateurs qui surfent par là.
Ou si une injection de code est possible par un exploit, autant installer un troyen plutôt que d’exploiter zenbleed.
(dans tous les cas, pour le grand public, l’ingénierie sociale et le spam marchent tellement mieux…).
Par contre, une attaque plus proche du hardware, comme l’injection d’un code malicieux directement sur un serveur, est beaucoup plus vraisemblable ; c’est sûrement une cible industrielle privilégiée pour les datacenter (et sûrement pour ça que les patchs EPYC et linux sont déjà en place).
Faites attention aux clés USB que vous manipulez.
Bref, tout comme spectre, l’impact grand public sera nul ou du moins invisible.
Pas besoin de psychoter.
Mais, comme dit Pierre, le risque zéro n’existe pas. Et une très mauvaise nouvelle est toujours possible.
@StarDreamer: C’est si difficile que ça de trouver quelques lignes javascript qui derrière, aboutissent à cette séquence? (bien-sûr, pas reproductible sur chaque plateforme, en fonction des version).
Bon bin tant mieux alors.
@StarDreamer: Je vois même pas comment c’est possible en javascript vu que le js tourne dans une sandbox du navigateur et n’a donc jamais accès direct au registres cpu. C’est sans doute pour ça qu’ils sont pas pressés de mettre à jour les procs grand public alors que pour les procs à destination des serveurs ils ont fait fissa parce que là c’est vraiment urgent.
@to: Pas directement, mais indirectement, justement!
La machine virtuelle, pour pouvoir exécuter ce langage interprété, il va bien falloir qu’elle s’en remette au cpu à un moment ou à un autre. En transformant en quelque sorte les appels. Or actuellement, aucune machine virtuelle n’est au courant que cette séquence (qu’elles pourraient produire par mégarde en interprétant le script) est dangereuse.
D’ailleurs l’auteur précise bien que cette séquence n’est pas malveillante en soit, et qu’il est inutile pour les antivirus de tenter de rechercher les programmes qui l’exécuterait. C’est une séquence tout à fait légitime.
Mais machines virtuelles, sandbox, containers, processus, etc… il n’y a aucune barrière pour cette faille d’après l’auteur.
@TiTi: Justement non, le javascript n’a jamais accès à quoi que ce soit contrairement à la poc présentée qui lit en asm les registres indépendamment de l’endroit où elle s’exécute (d’où le problème) ; d’ailleurs chez aws ils ont clairement dit que leur hyperviseur n’était pas affecté et cloudlare a retiré son article donc à part le type sur HN qui a aussi disparu personne n’a montré de poc en js.
@to: Quant tu déclare une variable dans un programme, tu obtiens un emplacement en RAM. Et lorsque tu veux travailler avec, c’est emplacement est lu, chargé dans les registres, modifié par le cpu, puis finalement le résultat est replacé en RAM, à l’emplacement correspondant à ta variable.
Mais si dans la foulé, tu parvient à faire exécuter au CPU cette petite séquence, ce n’est pas ta variable modifiée que tu va récupérer, mais une donnée appartenant à un autre processus.
Que tu fasses ça en assembleur, en C ou en javascript, ça se passera toujours de la même manière.
Il est impossible de modifier ou déplacer une variable sans passer par le CPU, et donc de la charger/décharger dans ses registres. C’est impossible. Les machines virtuelles ne sont pas magiques, elles ne savent rien calculer par elle-même. Ça se saurait, si on pouvait se passer de CPU pour exécuter des trucs. Y aurait moyen de faire de grosses économie dans un ordinateur!
Là ce qui est compliqué, c’est de parvenir à manipuler la VM pour arriver à lui faire exécuter ce qu’on souhaite, par des commandes js haut-niveau d’un côté, qui in-finé débouchent sur des instructions machines de l’autre.
Je pensais les hackers malins, et qu’ils finirait par y arriver. Mais bon, peut-être bien que c’est impossible finalement. Et c’est très bien ainsi.
@TiTi: Quant tu déclare une variable dans un programme, tu obtiens un emplacement en RAM. Et lorsque tu veux travailler avec, c’est emplacement est lu, chargé dans les registres, modifié par le cpu, puis finalement le résultat est replacé en RAM, à l’emplacement correspondant à ta variable.
Pas en javascript dans v8 dans Chrome dans windows (dans une vm), il y a des indirections d’adressage pour entre autres empêcher ce genre de trucs. Là il y arrive parce qu’il tape DIRECTEMENT en asm dans le registre. C’est pour ça que aws dit que son superviseur n’est pas affecté, il remappe l’adressage.
@to: Et qui que tu crois qui s’occupe donc, de ces indirections d’adressages? Le CPU.
Pour déplacer une donnée d’une indirection à une autre, il va faire un LOAD, puis un STORE, la faisant transiter par ses registres.
Je persiste à penser que si certains annoncent leur système invulnérables, c’est parce qu’ils ont passé en revue la totalité de leur petits bout de code pré-compilé, et n’ont trouver aucun moyen de générer cette petite séquence permettant le déroutage… jusqu’à preuve du contraire.