Hypervisor Escape : Évasion VMware, KVM et QEMU

L'évasion d'hyperviseur (hypervisor escape) constitue l'une des attaques les plus redoutées en environnement virtualisé : un attaquant contrôlant une machine virtuelle guest parvient à exécuter du code sur l'hôte, compromettant l'ensemble de l'infrastructure de virtualisation. Les hyperviseurs VMware ESXi, KVM/QEMU et Hyper-V sont des cibles de choix, avec des surfaces d'attaque allant des périphériques émulés (carte réseau, carte graphique, USB) aux interfaces paravirtualisées (virtio, VMCI). Ce guide technique couvre les techniques d'exploitation des hyperviseurs, depuis la modélisation de la surface d'attaque jusqu'aux chaînes d'exploitation complètes, en passant par les vulnérabilités des périphériques émulés et les mécanismes d'isolation. Les architectes cloud, les chercheurs en sécurité et les équipes de pentest d'infrastructures virtualisées trouveront ici une référence technique approfondie avec des études de CVE et des méthodologies d'audit.

Surface d'Attaque des Hyperviseurs

Un hyperviseur expose plusieurs interfaces au guest, chacune représentant un vecteur d'attaque potentiel :

Exploitation VMware ESXi et Workstation

VMware est la cible la plus lucrative en compétition Pwn2Own (jusqu'à 150 000$ pour un escape). Les principaux vecteurs d'attaque sont :

• SVGA device : le périphérique graphique virtuel VMware SVGA II implémente des commandes 3D complexes (shaders, surfaces, contexts). La complexité du parsing de ces commandes crée des vulnérabilités de type heap overflow, integer overflow et UAF dans le processus vmx sur l'hôte.
• VMXNET3 : la carte réseau paravirtualisée haute performance. Les descripteurs de paquets forgés par le guest sont parsés par le driver côté hôte, créant des opportunités d'OOB read/write.
• VMCI (Virtual Machine Communication Interface) : interface de communication entre VMs et avec l'hôte. Les datagrammes VMCI forgés peuvent déclencher des vulnérabilités dans le handler côté hôte.
• Backdoor I/O port : le port I/O 0x5658 est l'interface de communication bas niveau entre le guest et VMware Tools. Les commandes non validées peuvent corrompre l'état du VMX.

Exploitation KVM/QEMU

QEMU est un émulateur qui, combiné avec le module kernel KVM (Kernel-based Virtual Machine), fournit une virtualisation performante sur Linux. QEMU émule des dizaines de périphériques en userspace — chaque device est un vecteur d'attaque potentiel :

# Surface d'attaque QEMU typique
qemu-system-x86_64 \
    -device virtio-net-pci \    # Réseau paravirtualisé
    -device virtio-blk-pci \    # Stockage paravirtualisé
    -device virtio-gpu \        # GPU paravirtualisé
    -device qxl \               # Affichage (QXL/Spice)
    -device usb-ehci \          # Contrôleur USB émulé
    -device intel-hda \         # Audio émulé
    -device e1000 \             # Carte réseau émulée (e1000)
    -chardev socket \           # Interfaces de contrôle
    -monitor telnet              # Console de gestion

Heap Exploitation dans QEMU

QEMU utilise son propre allocateur mémoire basé sur glib (g_malloc/g_free). Les vulnérabilités dans les périphériques émulés (OOB write dans les registres MMIO, UAF dans les descripteurs DMA) corrompent le heap de QEMU en userspace. L'exploitation suit les techniques classiques de heap exploitation userspace : tcache poisoning, overlapping chunks, corruption de la GOT ou des pointeurs de fonction des structures de périphériques QEMU.

// Exemple : exploitation d'un OOB write dans un device QEMU
// Le guest écrit dans un registre MMIO qui indexe un tableau sans bounds check

// Côté guest (dans un module kernel ou en userspace avec /dev/mem) :
volatile uint32_t *mmio = mmap_device(DEVICE_MMIO_BASE);

// Écriture OOB : l'index dépasse la taille du tableau côté QEMU
mmio[REGISTER_INDEX] = 0xFFFF;     // Index hors limites
mmio[REGISTER_DATA] = 0x41414141;  // Donnée écrite en OOB dans le heap QEMU

// Le résultat : corruption du heap QEMU sur l'hôte
// → exploitation classique (tcache poisoning, GOT overwrite)

Exploitation des Périphériques Virtio

Les périphériques virtio (paravirtualisés) sont plus performants que l'émulation complète mais exposent une surface d'attaque spécifique via les virtqueues — des files de messages partagées entre guest et host. Le guest contrôle les descripteurs dans les virtqueues, et le backend virtio côté hôte les parse. Les vulnérabilités typiques :

• Descriptor chain confusion : les descripteurs virtio forment des chaînes (next pointers). Un guest malveillant peut créer des boucles infinies ou des références hors limites.
• DMA mapping issues : les adresses guest dans les descripteurs sont traduites via IOMMU. Sans IOMMU, le guest peut référencer n'importe quelle adresse physique de l'hôte.
• Buffer overflow dans les backends : les backends vhost-net et vhost-user parsent les données des virtqueues, vulnérables aux overflows si les tailles ne sont pas validées.

Hyper-V : Architecture et Exploitation

Hyper-V est un hyperviseur de type 1 (bare-metal) de Microsoft, directement intégré dans Windows. Son architecture diffère de KVM/QEMU : la partition root (parent) et les partitions child communiquent via le VMBus — un bus de communication inter-partition. Les VSP (Virtualization Service Providers) dans la partition root fournissent des services aux VSC (Virtualization Service Clients) dans les partitions child.

Les vecteurs d'exploitation Hyper-V incluent : les hypercalls (appels système vers l'hyperviseur), le VMBus messaging (messages forgés entre partitions), les synthetic devices (périphériques synthétiques Hyper-V), et le RemoteFX (GPU virtualisé, surface massive — désactivé en 2021 pour raisons de sécurité).

IOMMU et VT-d : Protection DMA

L'IOMMU (Input/Output Memory Management Unit) — implémenté comme Intel VT-d ou AMD AMD-Vi — est la mitigation principale contre les attaques DMA depuis les VMs et les périphériques PCIe. L'IOMMU traduit les adresses DMA des périphériques via des tables de pages dédiées, empêchant un périphérique (ou un guest avec passthrough) d'accéder à la mémoire de l'hôte. Sans IOMMU, un guest avec accès PCI passthrough peut lire/écrire n'importe quelle adresse physique de l'hôte.

Sandboxing des Processus d'Émulation

Les hyperviseurs modernes isolent les processus d'émulation :

• QEMU sandboxing : -sandbox on active les filtres seccomp-bpf qui restreignent les syscalls autorisés. Le processus QEMU ne peut plus execve(), fork(), ni accéder aux fichiers système.
• ChromeOS crosvm : chaque périphérique virtuel s'exécute dans son propre processus sandboxé avec un namespace séparé. Un escape dans le device GPU n'a pas accès au device réseau.
• AWS Firecracker : microVM minimaliste avec seulement 5 devices émulés et un filtre seccomp strict. Surface d'attaque réduite de ~90% par rapport à QEMU standard.
• Apple Hypervisor.framework : l'hyperviseur Apple isole chaque VM dans un sandbox macOS dédié avec des entitlements restreints.

FAQ — Questions Fréquentes