Évasion de VM et isolation matérielle des hyperviseurs

Une machine virtuelle (VM) n’est isolée que tant que la frontière imposée par l’hyperviseur tient. Une évasion de VM transforme une compromission locale en exécution de code sur l’hôte, puis potentiellement sur les autres locataires du même serveur. C’est le scénario qui fait passer le cloud mutualisé de promesse d’architecture à incident de périmètre.

→ Lire l’explication complète de la marmotte

Hyperviseur Type 1, Type 2 et frontière d’exécution

Un hyperviseur de type 1, ou bare-metal, s’exécute directement sur le matériel. VMware ESXi, Microsoft Hyper-V, Xen et KVM (Kernel-based Virtual Machine) relèvent de cette catégorie, même si KVM s’appuie sur le noyau Linux comme couche de contrôle. Un hyperviseur de type 2 s’exécute comme application sur un système hôte généraliste, par exemple VMware Workstation ou VirtualBox.

La différence est structurelle. Dans un type 1, l’hyperviseur contrôle directement les transitions entre le processeur, la mémoire et les machines invitées. Dans un type 2, le système d’exploitation hôte contrôle aussi les pilotes, les processus, le stockage et la planification. Compromettre ce système hôte revient généralement à posséder toutes les VM. Le type 2 reste valable pour le poste de développement et le laboratoire, pas pour héberger des charges multi-locataires à forte valeur. Présenter VirtualBox comme une fondation de cloud privé relève du même optimisme que protéger une salle serveur avec une plante verte.

L’isolation normale repose sur plusieurs mécanismes matériels et logiciels :

les extensions de virtualisation du processeur exécutent le noyau invité dans un niveau de privilège distinct ;
la traduction d’adresses de second niveau empêche une VM de mapper arbitrairement la mémoire physique de l’hôte ;
l’Input Output Memory Management Unit (IOMMU) borne les accès Direct Memory Access (DMA) des périphériques physiques ;
l’hyperviseur émule ou paravirtualise les périphériques exposés à chaque invité ;
le réseau virtuel sépare les ports, les tables de transfert et les politiques de filtrage.

Cette frontière n’est pas une enclave magique. L’hyperviseur traite des entrées fournies par la VM : registres virtuels, descripteurs de mémoire, commandes de disque, paquets réseau, données graphiques et requêtes de périphériques. Chaque émulation ajoute un parseur privilégié. Chaque parseur est une surface d’attaque. Les fondations de l’architecture cybersécurité commencent par cette règle peu glamour : une couche de contrôle qui interprète des données non fiables doit être traitée comme exposée.

Le compromis central est net. L’émulation de périphériques apporte compatibilité et densité de consolidation, mais multiplie le code privilégié accessible depuis les invités. Réduire les périphériques virtuels et désactiver ceux qui ne servent pas améliore l’isolation, au prix d’une compatibilité parfois moins confortable. Ce prix est acceptable pour les charges sensibles. Une carte son virtuelle n’a jamais sauvé une architecture, même sur une slide particulièrement inspirée.

Évasion de VM : classes de failles et précédents marquants

Une évasion de VM désigne l’exécution de code hors du périmètre prévu de l’invité. La cible directe est souvent le processus de virtualisation ou le noyau de l’hôte. Une fois ce niveau atteint, lire ou modifier la mémoire d’autres VM, installer un hyperviseur malveillant, intercepter les disques virtuels et voler des secrets devient possible.

La vulnérabilité VENOM, identifiée sous le numéro CVE (Common Vulnerabilities and Exposures) CVE-2015-3456, illustre la classe des pilotes de périphériques virtuels partagés. Le contrôleur de disquette émulé de QEMU contenait une erreur de validation lors du traitement de commandes fournies par l’invité. Une VM pouvait provoquer une corruption mémoire dans le processus QEMU et viser l’exécution de code sur l’hôte. Le périphérique était archaïque, mais actif par défaut dans de nombreux environnements. Le matériel obsolète virtuel garde exactement les mêmes défauts que le matériel obsolète physique : il survit parce que personne n’a osé demander pourquoi il existait encore.

Les sous-systèmes graphiques virtualisés constituent une seconde classe récurrente. CVE-2009-1244, connue sous le nom Cloudburst, concernait l’adaptateur graphique virtuel SVGA de VMware. Des commandes graphiques malformées permettaient d’exploiter le processus d’hébergement depuis une VM invitée. Les interfaces graphiques accélérées exposent des formats complexes, des tampons, des pointeurs et parfois des accès directs à la mémoire graphique. Sur un serveur sans besoin d’affichage accéléré, exposer une carte graphique virtuelle est une dette de sécurité sans rendement.

Les pilotes virtio, les contrôleurs SCSI, USB et réseau font partie de la même famille de risque. Aucun protocole de périphérique virtuel ne devient sûr par décret parce qu’il est performant. La paravirtualisation réduit certains coûts d’émulation, mais le pilote côté hôte reste du code privilégié qui désérialise des structures contrôlées par l’invité.

Les contre-mesures sont concrètes :

maintenir l’hyperviseur, le noyau hôte et les composants de virtualisation au niveau de correctifs supporté ;
retirer les périphériques inutiles : disquette, USB, audio, port série, affichage 3D, agent de presse-papiers et dossiers partagés ;
séparer les classes de confiance sur des hôtes distincts, même dans un même cluster ;
activer l’IOMMU et vérifier que les périphériques à passage direct sont placés dans des groupes réellement isolés ;
limiter les privilèges de gestion, car l’interface d’administration de l’hyperviseur est une voie d’évasion parfaitement légitime pour un attaquant déjà administrateur.

Une faille d’évasion ne garantit pas toujours un contrôle total. Les protections du système hôte, telles que l’Address Space Layout Randomization (ASLR), les protections de pile et le confinement de processus, peuvent compliquer l’exploitation. Elles ne restaurent pas le modèle de confiance. Un processus d’hyperviseur compromis reste une alerte de niveau critique, pas un ticket de maintenance à placer après la refonte du portail.

Isolation matérielle avec SEV-SNP et TDX

L’isolation logicielle suppose que l’hyperviseur reste honnête pour la confidentialité de la mémoire invitée. AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP) et Intel Trust Domain Extensions (TDX) modifient cette hypothèse : la mémoire d’une VM protégée est chiffrée avec une clé liée au processeur et distincte des autres VM.

Avec SEV-SNP, le processeur associe des attributs de propriété et de validation aux pages mémoire de l’invité. L’hyperviseur ne peut pas librement remapper une page privée d’une VM vers une autre VM, ni lire son contenu en clair depuis l’hôte. Avec TDX, une machine protégée, appelée domaine de confiance, dispose également d’un état mémoire que le moniteur de machine virtuelle ne peut pas inspecter directement.

Cette protection répond à un risque précis : l’administrateur malveillant de l’hôte, l’hyperviseur compromis ou l’outil de débogage privilégié qui tente de lire la mémoire d’une VM. Elle est particulièrement pertinente pour les charges traitant des clés privées, des secrets d’identité ou des informations inter-organisations. Elle complète les architectures de gestion des secrets et des clés, elle ne les remplace pas.

Le coût est réel. Les outils habituels de diagnostic mémoire perdent leur visibilité, les agents de sécurité doivent s’exécuter dans l’invité, certaines fonctions de migration à chaud ou de sauvegarde demandent un chemin de chiffrement compatible, et l’attestation devient une dépendance opérationnelle. L’attestation prouve qu’une VM démarre dans une configuration matérielle attendue. Elle ne prouve ni que son application est saine, ni que ses administrateurs applicatifs sont sages, ni que le code métier a cessé de concaténer du SQL à minuit.

La recommandation est de réserver SEV-SNP ou TDX aux VM qui manipulent des secrets dont l’hôte ne doit pas disposer. Pour une flotte homogène sans données particulièrement sensibles, le socle prioritaire reste le durcissement de l’hyperviseur, la séparation des locataires et une discipline de correctifs. Le chiffrement matériel ne justifie pas un hôte négligé : il réduit la lecture mémoire, pas l’ensemble des effets d’une évasion.

Exploitation, rotation et reprise après compromission

Une évasion de VM impose de considérer l’hôte comme compromis, ainsi que les secrets accessibles depuis cet hôte. Dans une architecture classique, cela inclut les disques virtuels, les instantanés, les images mémoire, les jetons d’administration, les clés de chiffrement de stockage et les identifiants injectés par les agents de déploiement.

La rotation doit être planifiée avant l’incident. Une clé privée utilisée par une VM compromise ne devient pas saine parce que la VM redémarre. Les clés doivent être versionnées, les certificats renouvelables sans intervention manuelle, et les jetons à durée de vie courte. Les mécanismes de sauvegarde doivent chiffrer les instantanés et restreindre leur accès : un snapshot lisible par l’équipe d’exploitation contourne souvent tous les efforts placés dans le système invité.

La supervision doit corréler les événements suivants : création ou modification de VM, ajout de périphérique, activation du passage direct, export de snapshot, changement de réseau virtuel, arrêt inattendu du processus d’hyperviseur et alerte d’intégrité matérielle. Une journalisation uniquement dans la VM ne suffit pas, puisqu’une évasion peut la modifier. À l’inverse, une journalisation uniquement sur l’hôte échoue face à un hôte compromis. Les deux plans sont nécessaires, avec export hors bande vers une plateforme dont les administrateurs de virtualisation ne contrôlent pas seuls la rétention.

La reprise suit une séquence stricte : isoler l’hôte, préserver les preuves, réinstaller depuis une image vérifiée, appliquer les correctifs, recréer les VM depuis des sources maîtrisées et renouveler les secrets exposés. Restaurer une image mémoire ou un snapshot pris après compromission réintroduit potentiellement le code malveillant. La sauvegarde est un mécanisme de disponibilité, pas une machine à remonter le temps moral.

Exemple : réduire les périphériques QEMU exposés

L’exemple suivant désactive les composants inutiles d’une VM QEMU lancée en ligne de commande. Il ne remplace pas le durcissement de l’hôte, mais réduit les parseurs accessibles depuis l’invité.

# Démarrer une VM sans interface graphique, sans USB ni périphérique audio.
# Le disque et le réseau virtio restent explicitement déclarés.
qemu-system-x86_64 \
  -enable-kvm \
  -machine q35,usb=off \
  -nodefaults \
  -display none \
  -vga none \
  -device virtio-scsi-pci \
  -drive file=/var/lib/libvirt/images/app.qcow2,if=none,id=osdisk,format=qcow2 \
  -device scsi-hd,drive=osdisk \
  -netdev tap,id=net0,ifname=tap-app0,script=no,downscript=no \
  -device virtio-net-pci,netdev=net0

-nodefaults est le point décisif : QEMU n’ajoute plus silencieusement des périphériques hérités. Chaque périphérique exposé devient une décision explicite, documentable et révisable. Tester le démarrage, l’installation système et la supervision après retrait est obligatoire. Les dépendances cachées finissent toujours par apparaître lors de la maintenance, avec l’enthousiasme d’un grille-pain dans une baie réseau.

🐝 Ce qui arrive si on s’en passe

Sans cette discipline d’isolation, le périmètre d’un incident cesse d’être calculable. Un hôte dont les périphériques hérités restent actifs par défaut ne permet plus de répondre à la question qui compte après une alerte : quelles machines invitées ont partagé ce processeur, cette mémoire et ce commutateur virtuel. La migration à chaud aggrave le flou, puisqu’une VM peut avoir résidé successivement sur plusieurs hôtes du cluster, et l’inventaire des voisins historiques manque le plus souvent. Sans attestation, rien ne distingue une plateforme au niveau de correctif attendu d’une plateforme modifiée. La conséquence pratique est une reconstruction élargie par précaution, portant sur des machines saines, avec des interruptions de service et des renouvellements de secrets bien plus étendus que le compromis réel.

🦫 Explication de la marmotte 🍫

Une machine virtuelle est un système informatique lancé à l’intérieur d’un serveur physique. Le programme qui organise plusieurs machines virtuelles sur ce serveur s’appelle un hyperviseur. Il attribue du processeur, de la mémoire, du réseau et des périphériques à chaque machine, tout en empêchant normalement une machine de lire ou modifier les données des autres.

Pour fonctionner, l’hyperviseur reçoit des demandes venant des machines virtuelles : utiliser un disque, envoyer un paquet réseau, afficher une image ou accéder à un périphérique. Si une erreur existe dans le programme qui traite une de ces demandes, une machine compromise peut envoyer des données conçues pour provoquer cette erreur. Le code malveillant peut alors s’exécuter sur le serveur hôte. À partir de là, l’attaquant peut viser les autres machines du même serveur.

Les protections matérielles récentes chiffrent la mémoire de chaque machine virtuelle avec une clé gardée par le processeur. Même si le programme de gestion du serveur est compromis, il ne peut alors pas lire directement cette mémoire protégée. Cette protection ne bloque cependant pas toutes les attaques : elle ne corrige pas une application vulnérable, ne protège pas un mot de passe déjà volé et ne remplace pas les mises à jour.

La défense repose donc sur plusieurs niveaux : réduire les périphériques exposés, corriger rapidement l’hyperviseur, séparer les charges sensibles et renouveler les secrets après une compromission.

Pages voisines

La citent

Évasion de VM et isolation matérielle des hyperviseurs

Elle cite

: les deux pages se citent l’une l’autre.

Évasion de VM et isolation matérielle des hyperviseurs

Évasion de VM et isolation matérielle des hyperviseurs

Hyperviseur Type 1, Type 2 et frontière d’exécution

Évasion de VM : classes de failles et précédents marquants

Isolation matérielle avec SEV-SNP et TDX

Exploitation, rotation et reprise après compromission

Exemple : réduire les périphériques QEMU exposés

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines