Un groupe de chercheurs des universités de Louvain, de Lübeck et de Birmingham a développé une méthode d'attaque BadRAM (CVE-2024-21944) permettant de contourner le mécanisme de vérification d'authenticité et de compromettre des environnements protégés utilisant l'extension SEV-SNP sur les processeurs AMD. Dans la plupart des cas, l'attaquant doit avoir un accès physique aux modules de mémoire et la capacité d'exécuter du code au niveau du ring zéro (ring0) sur le serveur exécutant les environnements invités protégés.
Les extensions AMD SEV (Secure Encrypted Virtualization) visent à garantir l'intégrité de la mémoire des machines virtuelles, ainsi que leur protection contre toute interférence et analyse de la part de l'administrateur du système hôte, capable d'exécuter du code au niveau de l'hyperviseur. À l'origine, la protection AMD SEV se limitait au chiffrement du contenu de la mémoire du système invité et à l'isolation des registres, mais par la suite, l'extension SEV-SNP (Secure Nested Paging) a été mise en œuvre dans les processeurs AMD EPYC pour un fonctionnement sécurisé avec des tables de pages mémoire imbriquées, garantissant l'intégrité de la mémoire et empêchant toute modification de la mémoire du système invité par l'hyperviseur.
Le mécanisme AMD SEV-SNP a été conçu pour empêcher que des agences de renseignement ou du personnel des centres de données et des fournisseurs de cloud où fonctionnent des systèmes invités protégés puissent interférer avec le fonctionnement du système invité. La méthode d'attaque BadRAM proposée permet de contourner les garanties fournies en modifiant les métadonnées SPD (Serial Presence Detect) dans les modules de mémoire DDR4 ou DDR5. En cas d'attaque réussie, l'attaquant peut réécrire des données chiffrées dans la mémoire du système invité (au niveau du texte chiffré, sans possibilité de déchiffrement) et contourner le mécanisme d'attestation, par exemple pour masquer l'injection d'une porte dérobée dans une machine virtuelle protégée par la technologie SEV-SNP.
L'attaque repose sur la falsification des paramètres SPD du module de mémoire, amenant le processeur à accéder à des adresses inexistantes, reflétées sur des zones de mémoire existantes. L'attaquant peut ajuster le SPD de telle manière que le module de mémoire retourne au processeur une taille supérieure aux caractéristiques réelles du module. Après cela, l'attaquant peut effectuer un mapping de la mémoire fictive inexistante sur une zone réelle dans la DRAM, déjà utilisée sous forme chiffrée dans les systèmes invités protégés. En conséquence, une situation se présente où différentes adresses pointent vers une même mémoire physique (deux zones sont reflétées sur une zone dans la puce DRAM), c'est-à-dire que l'adresse de la zone de mémoire fictive reflétée peut accéder à la mémoire réelle déjà utilisée et contourner les mécanismes de protection de la mémoire dans le CPU.
Pour réaliser l'attaque, il suffit de rassembler un programmateur simple d'un coût d'environ 10 dollars, composé d'un microcontrôleur Raspberry Pi Pico, d'un connecteur pour modules DDR4/DD5 et d'une alimentation. Les outils utilisés pour l'attaque, le module noyau et les prototypes d'exploits sont disponibles sur GitHub.
Pour les puces de certains fabricants, où la protection contre la réécriture du SPD n'est pas en place, l'attaque est possible par voie logicielle sans accès physique au serveur. Par exemple, il est possible de modifier les paramètres des modules de mémoire de la société Corsair avec éclairage RGB de manière logicielle. Dans le cas d'une attaque totalement logicielle, le système peut être compromis, par exemple, par l'utilisation d'une mise à jour BIOS malveillante ou par des actes de sabotage de la part des administrateurs. serveurs dans les services cloud.
Pour confirmer le fonctionnement de la méthode, deux attaques ont été démontrées. Dans la première attaque, la possibilité de reproduire le texte chiffré est montrée — en utilisant AMD SEV, les données en mémoire sont stockées sous une forme chiffrée, et l'attaquant ne peut pas déterminer le contenu, mais il a la possibilité de lire les données chiffrées puis de les substituer à d'autres contenus chiffrés.
La deuxième attaque démontre la possibilité de contourner le mécanisme d'attestation SEV-SNP, qui fournit une confirmation cryptographique de l'intégrité de la machine virtuelle exécutée dans un environnement protégé. L'attaquant peut intercepter le rapport d'attestation d'une machine virtuelle correcte et ensuite le substituer pour une machine virtuelle compromise, par exemple, en dissimulant les traces de l'injection d'un backdoor.
Le problème concerne les 3ème et 4ème générations de processeurs AMD de la série EPYC, livrés sous les noms de code Milan, Milan-X, Genoa, Bergamo, Genoa-X et Siena. Pour bloquer la vulnérabilité, AMD a déjà publié une mise à jour du firmware SEV, dans laquelle une vérification ALIAS_CHECK a été mise en œuvre pour empêcher les manipulations de mémoire, caractéristiques de l'attaque considérée.
Les technologies Scalable SGX et TDX proposées par Intel ne sont pas vulnérables à cette attaque, car les vérifications nécessaires sont présentes dès le départ. La technologie classique Intel SGX, qui a été classée comme obsolète par Intel en 2021, est partiellement vulnérable à l'attaque (de la même manière que l'attaque MemBuster connue précédemment, un attaquant peut analyser les accès à la mémoire chiffrée, c'est-à-dire qu'il est seulement possible de lire le texte chiffré, mais pas de le réécrire). Aucun test des extensions CCA (Confidential Compute Architecture) dans les processeurs ARM n'a été réalisé.
Une autre vulnérabilité concernant AMD SEV-SNP a également été signalée. La vulnérabilité a été identifiée dans le fork d'AMD du simulateur QEMU, destiné à l'exécution machines virtuelles avec SEV-SNP. Le problème permet à l'administrateur de l'environnement d'hébergement d'obtenir un accès root aux systèmes invités par le biais de manipulations des tables ACPI. La vulnérabilité est causée par le fait qu'à l'initialisation du système invité, une vérification de l'intégrité du noyau Linux, du disque RAM initial et des paramètres du noyau est effectuée, mais les tables ACPI ne sont pas prises en compte, à travers lesquelles le hyperviseur peut mettre en place un code AML (ACPI Machine Language) spécialement conçu, destiné à être exécuté dans l'environnement invité. Il est affirmé que le problème n'est pas spécifique à QEMU et se manifeste dans tous les hyperviseurs et émulateurs, car le noyau Linux fait confiance à toutes les données ACPI reçues du hyperviseur.
Source : opennet.ru
