Les Googlers ont non seulement déterminé comment briser la sécurité d’AMD – leur permettant de charger un microcode non officiel dans ses processeurs pour modifier le comportement du silicium comme ils le souhaitent – mais ont également démontré cela en produisant un patch de microcode qui fait que les puces sont toujours à la sortie 4 lorsqu’ils sont demandés pour un nombre aléatoire.
Et cette capacité à modifier le microcode permet non seulement à Google et à d’autres de personnaliser le fonctionnement de leurs puces AMD, pour de bonnes et des raisons non liées, mais il brisait également les fonctionnalités de virtualisation cryptée sécurisée et de sécurité cryptée.
Arrière-plan
Microcode est un bloc spécial de programmes généralement chargés dans un processeur pendant le démarrage du système qui définit le fonctionnement de la puce. En fournissant un microcode aux utilisateurs, AMD peut ajouter certaines fonctionnalités, résoudre certains problèmes et étendre certaines fonctionnalités sans avoir à repenser et à rééditer le silicium physique. Il s’agit d’un correctif qui met à jour votre puce – Intel a des mises à jour similaires – et surtout uniquement AMD est censé produire des mises à jour de microcode de travail pour ses produits.
AMD cuit un mécanisme de sécurité cryptographique dans ses processeurs qui vérifie une mise à jour du microcode provenant vraiment d’AMD avant de l’accepter. Le format du microcode n’est pas non plus documenté publiquement et est très propriétaire et protégé. Tout cela est d’empêcher quelqu’un de proposer son propre microcode viable et de faire un processeur AMD faire des choses qu’il ne devrait pas ou de manière non standard.
Eh bien, les Boffins de Google ont découvert un moyen de créer leur propre microcode qui est accepté par les processeurs AMD et modifie avec succès le fonctionnement du silicium. Ils disent que leur technique fonctionne sur toutes les puces AMD basées sur Zen – toutes les pièces Ryzen et Epyc, en gros.
Comment (pas très) aléatoire
Pour sauvegarder ces affirmations, les Googlers ont sorti cette semaine détails initiaux de leurs résultats, et une mise à jour du microcode de preuve de concept pour les puces de serveur Milan-Family Epyc et les processeurs de bureau Ryzen 9 Phoenix-Family. Ce microcode de démonstration Force une puce à lire aléatoire (Rdrand) instruction pour toujours produire la valeur 4 plutôt qu’un nombre aléatoire réel, probablement une référence à Xkcd.
Les Googlers ont soigneusement stérilisé leur preuve de concept, notez-nous. L’instruction RDRAND modifiée efface toujours l’indicateur de transport du CPU Core à zéro, signalant aux applications que la valeur n’est pas valide. Ainsi, si certains mécréants devaient commencer à distribuer le correctif, des applications et des bibliothèques bien écrites devraient refuser d’utiliser le nombre statique sur les processeurs entravés. Ceci est important car RDRand est utilisé par le logiciel pour générer des valeurs aléatoires pour un cryptage sécurisé fort et d’autres cryptographies; Une valeur de toujours 4 détruira silencieusement cette protection des données. Cela dit, les logiciels peuvent obtenir des nombres aléatoires provenant d’autres sources.
Les implications de cela sont assez importantes. Il montre comment les instructions logicielles peuvent être modifiées ou étendues par des correctifs non officiels de microcode, que Google et potentiellement d’autres peuvent créer de tels patchs, et que ces correctifs pourraient être utilisés pour de bon – améliorer les opérations du processeur – et les mauvaises, telles que les systèmes de décompte ou affaiblir la sécurité. Il y a eu des recherches antérieures sur le format microcode d’AMD (par exemple, ici et ici) Bien que le travail de Google couvre les dernières pièces d’AMD à celles-ci en 2017.
Cette vulnérabilité pourrait être utilisée par un adversaire pour compromettre les charges de travail informatiques confidentielles
Surtout, vous devez accès au niveau du noyau, Ring-0 sur un système pour charger le microcode, donc cela ne peut être utilisé qu’une fois que vous avez suffisamment de privilèges. Cela rend cette technique plus utile pour ceux qui personnalisent leurs propres systèmes, ou pour les logiciels malveillants privilégiés qui souhaitent vraiment compromettre en profondeur un ordinateur infecté.
Mais considérez un scénario où vous exécutez une machine virtuelle sur un hôte distant en laquelle vous ne pouvez pas entièrement confiance, vous comptez donc sur la virtualisation cryptée sécurisée d’AMD à protéger votre machine virtuelle de l’hôte; Maintenant, l’hôte peut utiliser l’approche de Google pour charger le microcode qui sape ou souffle cette sécurité.
Le problème
D’après ce que nous pouvons dire, l’équipe Google a pu produire des mises à jour de microcode qui semblent être signées numériquement par AMD, ou signées d’une manière que le processeur s’attendra, tout en contenant du code qui n’est pas d’AMD. Ceci est réalisé en exploitant un algorithme de hachage faible dans la puce, nous dit-on.
« Nous avons démontré la capacité de fabriquer des correctifs de microcode malveillants arbitraires sur Zen 1 via ZEN 4 CPU », a expliqué lundi l’équipe de sécurité de Google.
« La vulnérabilité est que le CPU utilise une fonction de hachage non sécurisée dans la validation de signature pour les mises à jour du microcode.
« Cette vulnérabilité pourrait être utilisée par un adversaire pour compromettre les charges de travail informatiques confidentielles protégées par la dernière version de la virtualisation cryptée sécurisée AMD, SEV-SNP ou pour compromettre la racine dynamique de la mesure de la confiance. »
Le réparer
AMD et Google considèrent tous les deux ce chargement de correctifs non officiels de processeur comme une vulnérabilité de sécurité, dont nous avons eu un aperçu en janvier lorsque Asus a sauté le pistolet en révélant accidentellement un correctif de sécurité lié au microcode.
Le défaut, répertorié comme CVE-2024-56161 avec un score CVSS de 7,2 sur 10, a été découvert et signalé à AMD en septembre, et un correctif a été conçu d’ici décembre. Cette correction est déployée sous la forme de, ironiquement, une mise à jour officielle du microcode via des fabricants de systèmes d’AMD. Jusqu’à présent, il apparaît AMD a émis des correctifs pour les processeurs de classe Datacenter et intégrés, et rien encore officiellement pour ses puces informatiques personnelles.
Cela dit, la fuite d’Asus de plus tôt était une mise à jour du BEA BETA pour les cartes mères de jeu alimentées par AMD qui ont résolu ce problème de sécurité des microcodes, de sorte que les mises à jour pour les composants Ryzen et Threadripper peuvent être en route. Nous recherchons des éclaircissements.
AMD stressé CVE-2024-56161 n’est exploitable que par une personne ayant accès à l’administrateur hôte. « Une fois ce niveau d’accès atteint, presque tout est possible », a déclaré un porte-parole Le registre.
Nous notons également que le trou ne peut pas être exploité par un administrateur dans un invité virtualisé; Vous avez besoin d’un accès Ring-0 au niveau du noyau sur l’hôte, en dehors de toutes les machines virtuelles en cours d’exécution.
« AMD a mis à disposition une atténuation de ce problème qui nécessite une mise à jour du microcode sur toutes les plates-formes touchées pour aider à empêcher un attaquant de charger un microcode malveillant », a expliqué le concepteur de puces.
« De plus, une mise à jour SEV du micrologiciel est requise pour que certaines plates-formes prennent en charge l’attestation SEV-SNP. La mise à jour de l’image du BIOS système et le redémarrage de la plate-forme permettra d’attestation de l’atténuation. Un invité confidentiel peut vérifier que l’atténuation a été activée sur la plate-forme cible à travers le rapport d’attestation SEV-SNP. «
Les processeurs EPYC qui remontent à 2017 sont affectés au moins. Plus de détails devraient être publiés par Google le mois prochain.
« En raison de la chaîne d’approvisionnement en profondeur, de la séquence et de la coordination requises pour résoudre ce problème, nous ne partagerons pas tous les détails pour le moment afin de donner aux utilisateurs le temps de rétablir la confiance sur leurs charges de travail confidentielles », le G- L’équipe a écrit. « Nous partagerons des détails et des outils supplémentaires le 5 mars 2025. »
AMD a remercié les Googlers Josh Eads, Kristoffer Janke, Eduardo ‘Vela’ Nava, Tavis Ormandy et Matteo Rizzo pour leur aide pour identifier et résoudre le problème. ®
