Évasion de microVM Firecracker via la manipulation des registres KVM

Des chercheurs en sécurité ont démontré une vulnérabilité critique dans Firecracker, la technologie de virtualisation open source utilisée pour alimenter les plateformes d'informatique sans serveur (serverless). En manipulant les registres CPU sauvegardés lors d'une transition spécifique du noyau, ils ont réussi à exécuter du code avec les privilèges root sur la machine hôte. L'exploit, détaillé en novembre 2026, permet à un attaquant situé dans une machine virtuelle invitée de prendre le contrôle du processus hôte gérant cette VM sans la faire planter ni alerter les outils de surveillance standards.

Ce qui s'est passé

L'équipe de recherche, publiant sous le nom PWN.AI Security Research, a dévoilé la deuxième partie de sa série "PwnEscape". Ces travaux s'appuient sur une primitive mémoire précédemment divulguée qui permettait à une VM invitée de lire et écrire dans certaines zones de la mémoire physique de l'hôte. Dans ce volet de suivi, ils ont combiné cette primitive avec une technique permettant de localiser et modifier l'état d'exécution en cours du processus Firecracker sur l'hôte. La cible était Firecracker version 1.16.1 fonctionnant sur un système x86-64 avec le noyau Linux 7.0.0-1011-aws.

L'exploit ne repose pas sur des dépassements de tampon traditionnels ou des bugs logiciels dans la logique applicative. Il abuse plutôt du mécanisme par lequel le noyau Linux sauvegarde et restaure l'état du processeur lors du basculement entre la VM invitée et le processus utilisateur de l'hôte. En identifiant l'emplacement mémoire exact où les registres du thread hôte sont stockés lors d'une sortie KVM, les attaquants ont redirigé le flux d'exécution. Ils ont forcé le processus hôte à exécuter un appel système write, affichant une chaîne de marqueurs spécifique sur son flux d'erreur standard. Crucialement, après l'exécution de cette charge utile, l'exploit a restauré les valeurs originales des registres, permettant au processus Firecracker de continuer à fonctionner normalement. La VM est restée accessible via SSH, et aucune erreur n'a été consignée par le noyau hôte.

Comment cela fonctionne

Le cœur de l'attaque repose sur la compréhension de l'interaction entre les processeurs virtuels (vCPU) et l'hôte. Chaque vCPU dans une microVM Firecracker correspond à un thread dans le processus hôte. Lorsque l'invité doit effectuer une opération nécessitant une intervention de l'hôte, comme la gestion d'une interruption ou l'accès à du matériel émulé, le thread quitte le module du noyau KVM et retourne dans l'espace utilisateur. Lors de cette sortie, le noyau sauvegarde l'état actuel du thread — y compris le pointeur d'instruction et le pointeur de pile — dans une structure appelée pt_regs.

Les attaquants ont utilisé leur primitive d'accès mémoire existante pour scanner la mémoire physique de l'hôte à la recherche de ces structures de registres sauvegardées. D'abord, ils ont placé un motif d'octets unique, ou nonce, dans une page connue de l'invité. En parcourant les Tables de Pages Étendues (EPT), ils ont traduit l'adresse physique de l'invité en adresse physique de l'hôte. Ensuite, ils ont effectué une rétro-mapping des tables de pages de l'hôte pour déterminer quel processus hôte mappait cette page physique, identifiant ainsi efficacement le processus Firecracker et son organisation mémoire malgré la Randomisation de la Disposition de l'Espace d'Adressage (ASLR).

Une fois le processus identifié, ils ont cherché une trame pt_regs correspondant à l'état attendu d'un thread revenant d'un appel ioctl KVM_RUN. Ils ont validé les candidats en vérifiant que le pointeur d'instruction sauvegardé correspondait aux adresses connues du code Firecracker et en s'assurant que les arguments de l'appel système correspondaient à une requête KVM active. Après avoir localisé la bonne trame, ils ont modifié le pointeur d'instruction sauvegardé pour qu'il pointe vers une enveloppe write dans le binaire Firecracker et ont ajusté le pointeur de pile pour inclure leurs arguments de charge utile. Lorsque l'invité déclenchait une sortie KVM en écrivant sur le port série, le thread hôte reprenait à l'adresse contrôlée par l'attaquant, exécutait l'écriture, puis retournait à son chemin original via une séquence de retour soigneusement construite.

Détails clés

• Environnement cible : Firecracker v1.16.1 sur x86-64, noyau hôte 7.0.0-1011-aws, noyau invité 6.18.44+.
• Niveau de privilège : L'exploit a permis l'exécution de code en tant que root car l'instance de test a été lancée directement en tant que root sans jailer ni restrictions d'espace de noms.
• Discrétion : La VM est restée entièrement opérationnelle après l'exploit ; les connexions SSH ont persisté et les compteurs de disponibilité ont continué normalement.
• Primitive mémoire : L'attaque nécessite une capacité préalable à lire et écrire des pages spécifiques de la mémoire physique de l'hôte depuis l'intérieur de l'invité.
• Validation : Les chercheurs ont confirmé le succès en capturant la chaîne de marqueurs N8V23M2\n depuis stderr du processus hôte tout en vérifiant que le texte exécutable et les bibliothèques partagées restaient inchangés.
• Récupération : L'exploit restaure explicitement trois mots de pile modifiés après l'exécution, ne laissant aucune trace forensique immédiate dans la zone temporaire de la pile.

Pourquoi c'est important

Pour les ingénieurs construisant des plateformes serverless ou des environnements de conteneurs isolés, cette démonstration met en lumière les risques liés au fait de se reposer uniquement sur les limites de l'hyperviseur pour la sécurité. Firecracker est conçu pour une isolation haute densité, mais cet exploit montre que si un invité peut franchir la couche d'isolation mémoire, il peut détourner le thread de gestion lui-même. Cela est particulièrement dangereux car l'attaque ne plante pas le service, rendant sa détection difficile via les moniteurs de disponibilité standards.

L'impact dépend fortement de la configuration de déploiement. Les chercheurs ont noté que leur configuration de test exécutait Firecracker en tant que root sans couches de confinement supplémentaires comme les filtres seccomp ou les espaces de noms utilisateurs. Dans les environnements de production, ces contrôles limitent ce qu'un attaquant peut faire même s'il parvient à exécuter du code. Cependant, la capacité de rediriger le flux d'exécution au sein du processus VMM reste une menace sévère, pouvant potentiellement permettre aux attaquants de contourner les politiques seccomp s'ils peuvent manipuler les arguments des appels système ou sauter vers des chaînes de gadgets dans l'espace mémoire autorisé.

Ce que vous pouvez faire

• Auditer les niveaux de privilège : Assurez-vous que les processus Firecracker ne s'exécutent pas en tant que root. Utilisez le jailer intégré pour réduire les privilèges et restreindre l'accès au système de fichiers dès le démarrage.
• Activer les filtres seccomp : Configurez des profils seccomp stricts pour limiter les appels système disponibles au processus Firecracker, réduisant ainsi la surface d'attaque pour toute exécution de code potentielle.
• Utiliser les espaces de noms utilisateurs : Exécutez Firecracker à l'intérieur d'espaces de noms utilisateurs pour isoler le processus de l'utilisateur root de l'hôte, limitant l'impact de toute évasion.
• Surveiller les comportements anormaux : Implémentez une journalisation pour les sorties stderr inattendues ou les motifs d'appels système inhabituels provenant des processus VMM, bien que cet exploit soit conçu pour être discret.
• Restez à jour : Suivez les mises à jour du projet Firecracker et appliquez les correctifs relatifs à l'isolation mémoire et à la gestion des interactions KVM dès qu'ils deviennent disponibles.
• Examiner les primitives mémoire : Investiguer comment votre charge de travail pourrait exposer les mappages de mémoire physique de l'hôte aux invités et durcir ces interfaces contre les recherches de traduction non autorisées.