AMD confirme une vulnérabilité dans ses processeurs EPYC

Pour exploiter la faille, il faut disposer des privilèges d’administrateur local sur un serveur, donc au ring 0 depuis l’extérieur d’une machine virtuelle. Il est alors possible de charger des correctifs malveillants du microcode dans le ou les processeurs concernés.

Droit de regard sur les machines virtuelles

« Cette vulnérabilité pourrait être utilisée par un adversaire pour compromettre des charges de travail informatiques confidentielles protégées par la dernière version d'AMD Secure Encrypted Virtualization, SEV-SNP ou pour compromettre la Dynamic Root of Trust Measurement », indiquent les chercheurs.

Bien que l’exploitation requière des privilèges locaux importants, la sévérité de la faille est considérée comme haute (score CVSS 3.1 de 7,2 sur 10). Son exploitation peut, en effet, conduire à l’installation de logiciels malveillants obtenant des capacités de visibilité dans les machines virtuelles, dont une partie de la sécurité repose sur le tandem matériel SEV-SNP au sein des processeurs.

Mauvaise vérification

SEV, pour Secure Encrypted Virtualization, est une technologie cruciale chez AMD. Elle génère une clé unique de chiffrement pour chaque machine virtuelle. Elle permet d’isoler les machines et l’hyperviseur les uns des autres.

SNP, pour Secure Nested Paging (pagination imbriquée sécurisée), ajoute des fonctions pour contrôler l’intégrité de la mémoire, renforçant encore l’isolation des machines virtuelles et devant les protéger d’attaques basées sur l’hyperviseur. Les deux technologies renforcent également les protections contre les attaques par canal latéral.

La vulnérabilité signalée par les chercheurs permet de jeter à bas ces défenses. Estampillée CVE-2024-56161, la faille réside dans l’utilisation d’une fonction de hachage non sécurisée pour valider les signatures dans les mises à jour du microcode. De là, un pirate peut faire passer des vessies pour des lanternes. Les machines virtuelles chiffrées perdent alors leur intégrité selon le code envoyé dans les processeurs.

La mise à jour déployée depuis décembre

Dans son bulletin, AMD indique qu’une mesure d’atténuation a été fournie pour la faille. Elle passe par une mise à jour du microcode et demande donc un arrêt du serveur, même si certains processeurs sont capables d’un chargement à chaud.

Il faut également déployer une nouvelle version du firmware SEV sur certaines plateformes, afin qu’elles puissent prendre en compte l’attestation SEV-SNP. Cette dernière permet à une instance de prouver son identité et son état. Une mise à jour du BIOS et un redémarrage du système sont nécessaires pour permettre l’attestation de l’atténuation. « Un invité confidentiel peut vérifier que l'atténuation a été activée sur la plate-forme cible grâce au rapport d'attestation SEV-SNP », précise AMD.

Les chercheurs (Josh Eads, Kristoffer Janke, Eduardo Nava, Tavis Ormandy et Matteo Rizzo) ont été remerciés par AMD. Ils notent cependant qu’ils ont fait une exception à la règle habituelle de révélation des failles de sécurité chez Google, notamment la période de 90 jours. Il s’est écoulé en effet 131 jours entre la publication des premières informations et la communication à AMD, et 45 jours depuis la diffusion des correctifs.

Pour les mêmes raisons, et compte tenu « de l’importance de la chaine d’approvisionnement et de la coordination nécessaire pour résoudre ce problème », aucun détail supplémentaire ne sera donné avant le 5 mars.

Précisons enfin que ce n’est pas la première fois qu’une faille de sécurité touche SEV ou SNP chez AMD. En 2023, une attaque baptisée CacheWarp avait nécessité également une mise à jour du microcode. Exploitée, elle pouvait permettre l’infiltration d’un code malveillant dans les machines virtuelles chiffrées.

Ni Google ni AMD ne parlent du cas des processeurs Epyc de 5ᵉ génération, avec l’architecture Zen 5.

• AMD fait le plein de nouveautés : EPYC 9005, Ryzen AI « PRO » et Instinct MI325X castré