Les processeurs AMD Zen 5 sont vulnérables à une faille permettant de modifier le microcode et de contourner l'isolation SEV-SNP

La société AMD a inclus les processeurs basés sur l'architecture micro Zen 5 dans la liste des produits vulnérables à la faille EntrySign, permettant de contourner le mécanisme de vérification de la signature numérique lors de la mise à jour du microcode. Il était initialement prévu que la vulnérabilité n'affecte que les CPU AMD basés sur les générations 1 à 4 de l'architecture Zen. Ainsi, la vulnérabilité s'applique à des processeurs tels que les Ryzen 9000 (Granite Ridge), EPYC 9005 (Turin), Ryzen AI 300 (Strix Halo, Strix Point, Krackan Point) et Ryzen 9000HX (Fire Range).

En plus de la mise à jour du microcode, pour remédier à la vulnérabilité sur les systèmes utilisant l'attestation SEV-SNP, une mise à jour du firmware AMD SEV, fournie dans le cadre des mises à jour du BIOS, est également nécessaire. On affirme qu'AMD a transmis aux fabricants de matériel un firmware modifié (ComboAM5PI 1.2.0.3c AGESA) nécessaire pour corriger le problème, mais les mises à jour finales du BIOS destinées aux consommateurs peuvent être publiées par les fabricants des semaines ou des mois plus tard.

Les employés d'AMD ont également proposé d'inclure dans le noyau Linux un patch bloquant le chargement des mises à jour du microcode non officielles (il est à noter que les mises à jour correctes du microcode doivent être installées avec le BIOS du fabricant de matériel, mais des tentatives pour créer des corrections non officielles basées sur des fragments de microcode extraits du BIOS ont déjà été signalées). Les utilisateurs sont conseillés d'attendre les mises à jour officielles du BIOS.

La vulnérabilité EntrySign offrant la possibilité de modifier le microcode compromet le mécanisme AMD SEV (Virtualisation Sécurisée Chiffrée), utilisé dans les systèmes de virtualisation pour la protection machines virtuelles contre l'intervention du hyperviseur ou de l'administrateur de la machine hôte. Lors de l'attaque, il est possible de s'immiscer dans le fonctionnement des systèmes invités protégés par des extensions AMD SEV (Virtualisation Sécurisée Chiffrée) et SEV-SNP (Pagination Néstée Sécurisée), fournissant des garanties d'intégrité de la mémoire des machines virtuelles, isolant les registres de processeur et assurant un fonctionnement sécurisé avec des tables de pages de mémoire imbriquées.

La vulnérabilité est causée par l'utilisation, lors de la vérification du microcode, de l'algorithme de code d'authentification CMAC au lieu d'une fonction de hachage fiable. La société AMD utilise une clé RSA privée pour signer numériquement le microcode chargé dans le processeur, et distribue la clé publique avec le patch de microcode. Pour vérifier que la clé publique correspond à la paire de clés RSA d'origine, le processeur compare le hachage de la clé publique AMD, intégré lors de la fabrication du CPU, avec le hachage de la clé publique spécifiée dans le patch.

L'authentification du microcode dans le patch est effectuée en comparant le hachage fourni avec le patch, signé numériquement (RSASSA-PKCS1-v1_5), et le hachage calculé sur la base du microcode réellement inclus dans le patch. Si les hachages de référence et calculés correspondent, le patch est chargé dans la mémoire interne du CPU. Le problème est qu'au lieu d'utiliser les fonctions de hachage cryptographiquement sécurisées recommandées, l'algorithme CMAC, qui n'est pas conçu pour de telles opérations et n'est pas protégé contre les collisions, a été utilisé.

Le CMAC n'est pas une fonction de hachage, mais implémente un code d'authentification de message (Message Authentication Code) dépendant de la clé de chiffrement. Le fonctionnement de l'AES-CMAC consiste à utiliser l'algorithme cryptographique AES et à combiner le résultat de son application avec le bloc de données suivant à l'aide de l'opération XOR. Ce schéma garantit qu'une modification des données d'entrée entraînera une modification imprévisible des données de sortie. De plus, l'utilisation de CMAC comme fonction de hachage est inacceptable, car quiconque connaît la clé de chiffrement d'origine peut connaître les états intermédiaires de chiffrement et calculer des valeurs qui peuvent compenser les modifications des données d'entrée de sorte que le résultat de l'application de CMAC reste inchangé.

AMD utilise une clé de chiffrement unique pour AES-CMAC, fournie sur tous les CPU, depuis Zen 1. Ainsi, il suffit d'extraire cette clé de n'importe quel CPU AMD et elle sera applicable à tous les autres CPU. Des chercheurs ont découvert qu'une clé connue, extraite d'un exemple mentionné dans les recommandations sur l'utilisation des algorithmes de chiffrement par blocs NIST SP 800-38B, a été utilisée pour le chiffrement AES-CMAC dans AMD. Comme AES-CMAC est utilisé pour le hachage de la clé RSA intégrée et du contenu du microcode, en identifiant la clé de chiffrement AES-CMAC, il est devenu possible de substituer un autre clé RSA publique dans le patch et de modifier le contenu du microcode.

Pour créer un patch fictif, il suffit de générer une nouvelle clé publique qui produit le même hachage que celui généré par la clé publique authentique d'AMD, ainsi que de trouver des collisions pour la signature numérique. Les collisions sont créées en ajoutant un bloc supplémentaire au microcode, ressemblant à un ensemble de données aléatoires. De cette manière, il est possible de préparer un patch modifié avec un microcode qui correspond à la signature numérique de l'original patch d'AMD. L'outil Zentool, comprenant des utilitaires pour analyser le microcode et créer des patches pour modifier le microcode, est disponible sous licence Apache 2.0. Pour remplacer le microcode, des droits pour exécuter le code au niveau du Ring 0 sont nécessaires (les technologies VT-x et AMD-V permettent à la machine virtuelle de s'exécuter avec des droits Ring 0).

Source : opennet.ru