Dirty Frag : deux failles zero-day Linux menacent les conteneurs et les microVM

Le chercheur en sécurité Hyunwoo Kim, également connu sous le pseudonyme V4bel, a divulgué le 7 mai une famille de deux vulnérabilités zero-day du noyau Linux, baptisées Dirty Frag. Répertoriées sous les identifiants CVE-2026-43284 et CVE-2026-43500, ces failles permettent à un utilisateur non privilégié d’élever ses droits de manière déterministe jusqu’à obtenir un accès root sur la plupart des distributions Linux diffusées depuis 2017. Microsoft a confirmé dès le lendemain une exploitation active de ces failles.

Le mécanisme de l’attaque

L’exploit repose sur une primitive d’écriture dans le cache de pages (page cache) du noyau. En contournant les mécanismes de protection, il parvient à écraser le contenu en mémoire de fichiers système tels que /usr/bin/su ou /etc/passwd, ouvrant ainsi la voie à une escalade de privilèges. Contrairement à d’autres vulnérabilités exploitant des conditions de concurrence (race conditions), Dirty Frag est totalement déterministe et ne nécessite pas de synchronisation particulière.

Des implications majeures pour les environnements mutualisés

Dans un contexte multi-locataire, la menace est particulièrement sérieuse. Le cache de pages étant partagé sur l’ensemble de la machine, tout conteneur qui partage le noyau hôte est vulnérable. Les mécanismes d’isolation des conteneurs – espaces de noms (namespaces), seccomp et capacités réduites – sont tous mis en œuvre par le noyau lui-même. Un exploit qui s’attaque au noyau opère donc en dessous de la couche où ces isolations sont censées agir. Les chercheurs de la plateforme declaw.ai, spécialisée dans le sandboxing d’agents d’intelligence artificielle, comparent cette faille à Dirty COW (2016) et Dirty Pipe (2022) : le jour où une zero-day est dévoilée, avant qu’un correctif ne soit disponible, toutes les solutions de conteneurs partageant le noyau sont exposées.

Test pratiques : conteneur vs microVM

Pour évaluer l’efficacité de leur isolation, les équipes de declaw.ai ont exécuté la preuve de concept publique (PoC) de l’exploit dans deux environnements distincts, sur un noyau volontairement non patché.

Dans un premier test avec un conteneur Docker classique (seccomp activé, utilisateur non privilégié avec UID 1001, noyau hôte 6.8.0), l’exploit a permis de passer d’un utilisateur non privilégié à root en moins de deux secondes. Le profil seccomp était actif, mais il autorisait les appels système nécessaires à l’attaque. Une fois root, l’attaquant peut lire /etc/shadow, les paramètres de démarrage du noyau hôte et les chemins du système de superposition de Docker.

Dans un second test, réalisé avec une microVM Firecracker (noyau invité non patché, sans seccomp, démarrée en tant que root avec toutes les capacités, soit une configuration volontairement plus permissive que le test précédent), l’exploit a fonctionné à l’intérieur de l’invité, mais toutes les tentatives d’atteindre l’hôte ont échoué. Le noyau hôte reste invisible, les processus hôtes ne sont pas accessibles (l’invité possède ses propres processus, comme kthreadd ou kswapd), les ports de l’hôte sont fermés, seuls des périphériques de bloc virtuels sont disponibles, et aucune information sur le matériel hôte n’est accessible. Le cache de pages corrompu appartient au noyau de l’invité, qui est mappé dans une région restreinte de la mémoire hôte via les tables de pages étendues (EPT).

Pourquoi les microVM résistent mieux

Ce test illustre une asymétrie fondamentale : la microVM démarre avec plus de privilèges apparents que le conteneur, mais ne parvient pas à compromettre l’hôte. Ce qui importe n’est pas tant les permissions accordées par le logiciel que le fait que le noyau soit partagé ou non. Pour s’échapper d’une microVM Firecracker, il faudrait exploiter une vulnérabilité dans le gestionnaire de machine virtuelle (VMM), écrit en Rust et comprenant environ 50 000 lignes de code, ou dans KVM. Le concours de sécurité kvmCTF organisé par Google offre 250 000 dollars pour une évasion de l’invité vers l’hôte, et un seul cas a été démontré publiquement à ce jour.

Un correctif en attente, des leçons pour l’industrie

Les deux vulnérabilités n’ont pas encore de correctif officiel disponible dans les noyaux stables. En attendant, les hébergeurs mutualisés qui exécutent du code non fiable sont invités à examiner leur modèle d’isolation. Comme le résument les chercheurs de declaw.ai : si la réponse à la question « un utilisateur devenu root dans le sandbox peut-il atteindre l’hôte ou les autres locataires ? » est « tant que nous sommes patchés », cela signifie qu’il existe une fenêtre de vulnérabilité. L’isolation matérielle offerte par les microVM semble pour l’instant constituer une meilleure barrière que le partage du noyau avec des conteneurs. La preuve de concept est accessible sur le dépôt GitHub du chercheur V4bel, et l’analyse détaillée est publiée sur le blog de declaw.ai.