Accueil » Actualité » Une faille SEVère dans les processeurs EPYC d’AMD

Une faille SEVère dans les processeurs EPYC d’AMD

EPYC fail !

Image 1 : Une faille SEVère dans les processeurs EPYC d'AMD

Les processeurs seraient-ils le nouveau cheval de bataille des experts en sécurité ? Depuis la découverte de Spectre et Meltdown il y a quelques mois, les failles logicielles et/ou matérielles touchant les CPU se suivent et ne ressemblent pas forcement. Des chercheurs viennent en effet d’annoncer être capables de mettre en défaut la technologie SEV (Secure Encrypted Virtualization) des processeurs EPYC d’AMD.

Une histoire de pages mémoires et de translation

SEV permet de chiffrer et déchiffrer à la volée le contenu des machines virtuelles stockées en mémoire vive. Il devient alors théoriquement impossible à l’hyperviseur ou à un malware de récupérer des données utilisables. Chaque machine virtuelle se voit assigner un identifiant d’espace mémoire, lié à une clé cryptographique stockée dans le SoC intégré au processeur EPYC : chaque VM bénéficie de sa propre clé, et tous les transferts entre les coeurs CPU et la mémoire sont protégés.

Pourtant, les chercheurs ont mis au point une technique baptisée SEVered qui serait capable de contourner les protections mises en place par SEV. Un hyperviseur, voire un compte administrateur, compromit par un malware pourrait récupérer des données protégées via une petite astuce : si la translation des adresses virtuelles en adresses réelles de l’OS invité (GVA vers GPA) est gérée par la VM elle-même et ne peut donc pas être lue par l’hyperviseur, c’est en revanche l’hyperviseur qui reste responsable du second niveau de translation (SLAT), transformant les adresses physiques de l’OS invité en adresses physiques de l’hôte (GPA vers HPA).

Ce manque de protection de l’intégrité de la mémoire principale pourrait permettre à un malware de modifier l’emplacement des pages mémoire de la VM au sein de la mémoire physique de l’hôte. Les chercheurs donnent l’exemple d’une extraction de données stockées dans la RAM d’une VM, via de simple requêtes HTTP lancée sur un serveur web tournant dans une autre VM sur le même système hôte. Il serait toutefois assez aisé de corriger le problème en protégeant l’étape de translation entre les adresses physiques de la VM et de l’hôte. Reste à savoir si cette modification peut être réalisée via un nouveau microcode, et sans perte de performances.