Des informations ont récemment été divulguées concernant une vulnérabilité mettant en danger les serveurs cloud. Cette vulnérabilité permet aux attaquants de prendre le contrôle total de la machine physique , un scénario cauchemardesque pour les fournisseurs d'infrastructure cloud.
Zapscape, référencée sous l'identifiant CVE-2026-64561, est une vulnérabilité critique de l'hyperviseur KVM sous Linux. Elle expose un risque que de nombreuses plateformes acceptent involontairement en activant la virtualisation imbriquée. Cette vulnérabilité permet à un attaquant disposant de privilèges noyau dans une machine virtuelle (couche 1) d'exécuter du code avec des privilèges root sur le système hôte (couche 0), compromettant ainsi l'isolation des environnements virtualisés.
Considéré comme une menace à fort impact, Zapscape facilite non seulement l'évasion de la machine virtuelle, mais ouvre également une voie d'élévation de privilèges locale pour les utilisateurs hôtes disposant d'autorisations d'écriture sur le périphérique /dev/kvm.
Bien que des organisations comme Red Hat aient attribué à la vulnérabilité un score CVSS de 7.0 axé sur l'instabilité et le déni de service, la preuve de concept publique (PoC) démontre une portée beaucoup plus destructrice : la création d'un fichier arbitraire directement à la racine de l'hôte.
Chaos dans l'unité de gestion de la mémoire
Le fonctionnement de Zapscape est masqué par l'unité de gestion de la mémoire (MMU) de KVM et par la manière dont l'hyperviseur gère les tables de pages lorsqu'une machine virtuelle (L1) fait office d'hyperviseur pour une autre (L2). Le problème provient d'une erreur d'ordre logique lors de la gestion des défauts de page. Dans les chemins d'exécution du noyau, la vérification de la présence d'une « racine obsolète » a été effectuée avant la fonction de récupération de la page, au lieu d'après.
Cette séquence incorrecte déclenche un scénario classique d'utilisation après libération . Lors de la récupération, KVM peut supprimer la racine qu'il utilise et la marquer comme invalide. Cependant, comme le contrôle d'intégrité a déjà été effectué, le système continue de créer des mappages sous une racine qui n'est plus valide. Il est intéressant de noter que ce problème de tri existait dans le code depuis 2008, mais il est devenu critique et exploitable après la publication du noyau Linux 5.9 en juillet 2020 , lorsqu'une directive a été introduite que le système a tout simplement cessé d'appliquer.
Exigences et limitations
Pour que Zapscape soit vulnérable, l' environnement doit répondre à des exigences très spécifiques. Premièrement, la virtualisation imbriquée doit être activée dans le module KVM, une configuration permettant une architecture à trois niveaux (L0, L1 et L2). L' attaquant doit initier l'attaque depuis la couche L1 , ce qui requiert des privilèges root sur cette machine virtuelle. De là, l'attaquant manipule les modes mémoire tandis que l'activité du sous-invité L2 force l'hôte L0 à lancer une récupération de pages de quota, provoquant ainsi une corruption de la mémoire.
Au niveau matériel, les conditions varient selon le fabricant. Sur les systèmes AMD utilisant des tables de pages imbriquées ( SVM ), la vulnérabilité est plus simple et ne requiert aucune fonctionnalité supplémentaire. En revanche, sur les processeurs Intel, le scénario exige que la machine virtuelle invitée de couche 1 expose des capacités de parcours de pages EPT à quatre et cinq niveaux . Cela limite le vecteur d'attaque sur Intel aux architectures les plus récentes, notamment à partir de la famille Ice Lake-SP.
Il convient de noter que, bien que la preuve de concept publique ait réussi à atteindre l'hôte dans des environnements contrôlés, des chercheurs en sécurité ont signalé que sur certains noyaux recompilés, l'exploit provoque simplement le plantage de la machine virtuelle de l'attaquant, agissant comme un déni de service plutôt que comme une évasion complète.
Mesures d'atténuation, correctifs et stratégies
La solution définitive à Zapscape est arrivée dans les dépôts Linux en juillet dernier avec un correctif qui modifie l'ordre de validation. Ce correctif déplace la vérification de la racine obsolète après l' allocation de pages MMU, garantissant ainsi que l'hyperviseur ne crée pas de mappages actifs sous une racine supprimée. Ces correctifs ont déjà été implémentés dans les branches stables du noyau et sont largement diffusés par diverses distributions.
Pour les administrateurs ne pouvant effectuer une mise à niveau immédiate, des solutions temporaires très efficaces existent. La priorité est de désactiver la virtualisation imbriquée sur tous les serveurs où elle n'est pas strictement nécessaire, en ajoutant le paramètre `nested=0` aux modules `kvm_amd` ou `kvm_intel` dans les fichiers de configuration modprobe. Cette mesure nécessite le rechargement du module, ce qui implique l'arrêt de toutes les machines virtuelles en cours d'exécution.
Enfin, si vous souhaitez en savoir plus, vous trouverez les détails en suivant ce lien.