Un chercheur a trouvé plusieurs failles graves dans le runtime de Docker pouvant casser la couche d’isolation entre le conteneur et le système d’exploitation hôte. Les pirates peuvent ainsi détourner des privilèges et voler des données.
Aleska Sarai, ingénieur logiciel chez Suse et membre du conseil d’administration de l’OCI (open container initiative) a publié une alerte sur la découverte trois failles de gravité élevée dans runc, le runtime de Docker. « Ces trois vulnérabilités permettent aux pirates de corrompre les conteneurs malgré les contrôles standard de renforcement et d’isolation ». Il ajoute que les failles touchent « la manière dont runc gère les écritures dans certains fichiers procfs, que les attaquants utilisent à l’intérieur des conteneurs pour détourner les privilèges hôtes en exploitant des chemins masqués, des montages de type Bind et des écritures de gadgets ».
Le responsable souligne que, même si ces attaques nécessitent des configurations de montage personnalisées ou des images non fiables, la menace est très réelle pour les systèmes conteneurisés, en particulier dans les orchestrateurs comme Docker ou Kubernetes. L’avis recommande vivement aux utilisateurs de mettre immédiatement à jour leurs versions ou d’appliquer les correctifs fournis.
Un problème de chemin masqué
Le premier des trois correctifs résout un problème de chemin masqué dans runc où le runtime du conteneur remplace un fichier par un montage de type Bind « /dev/null », un fichier de collecte de données sur les systèmes de type Unix. Si un attaquant parvient à transformer /dev/null en lien symbolique symlink vers un fichier procfs critique (par exemple, /proc/sys/kernel/core_pattern ou /proc/sysrq-trigger), le runtime monte par inadvertance cette cible en lecture-écriture, accordant ainsi à l’attaquant l’accès à l’hôte.
Dans une variante, runc ignore simplement l’absence de /dev/null et continue le processus, ce qui conduit à la divulgation d’informations via des fichiers masqués tels que « /proc/kcore » ou « /proc/timer_list », deux interfaces sensibles visibles par le noyau. M. Sarai avertit que, même si l’attaque ne peut pas monter directement des fichiers hôtes arbitraires, les méthodes sont suffisantes pour déclencher une évasion complète du conteneur ou un crash de l’hôte. La faille, référencée CVE-2025-31133, affecte toutes les versions connues de runc et a reçu un score de gravité de 7,3 sur 10. Elle a été corrigée dans les versions 1.2.8, 1.3.3 et 1.4.0-rc.3.
Deux autres failles graves
La deuxième vulnérabilité, référencée CVE-2025-52565, cible la gestion du montage « /dev/console ». Un attaquant peut remplacer le chemin cible par un lien symbolique symlink, ce qui entraîne le montage lié de la mauvaise cible par runc, permettant ainsi à l’attaquant d’obtenir un accès en écriture aux chemins procfs. « Comme pour la faille CVE-2025-31133, cela se produit après pivot_root(2) et ne peut donc pas être utilisé pour monter directement les fichiers hôtes, mais un attaquant peut tromper runc en créant un montage en lecture-écriture de /proc/sys/kernel/core_pattern ou /proc/sysrq-trigger, conduisant ainsi à une évasion complète du conteneur », a expliqué M. Sarai, ajoutant que les versions 1.0.0-rc3 et ultérieures restent vulnérables. La troisième faille référencée CVE-2025-52881 donne à un attaquant la capacité de contourner les modules de sécurité Linux Security Modules (LSM) tels que SELinux ou AppArmor en redirigeant les écritures vers les fichiers procfs. Une fois les étiquettes LSM neutralisées, les écritures vers les procfs au niveau de l’hôte deviennent possibles, ce qui peut entrainer une compromission entière de l’hôte.
« D’après notre analyse, ni AppArmor ni SELinux ne peuvent protéger contre la version complète de l’attaque par réécriture redirigée », a ajouté M. Sarai. « En général, le runtime du conteneur est suffisamment privilégié pour écrire dans des fichiers procfs arbitraires, ce qui est plus que suffisant pour provoquer une fuite du conteneur », a-t-il poursuivi. « L’utilisation de conteneurs en mode rootless peut aider, car cela bloquera la plupart des écritures involontaires », a indiqué M. Sarai. Une analyse supplémentaire de Sysdig, le spécialiste de la sécurité des conteneurs, de Kubernetes et du cloud, a confirmé que ces trois failles nécessitent de démarrer des conteneurs avec des configurations de montage personnalisées, ce qui est facilement réalisable à l’aide d’images de conteneurs et de fichiers Dockerfiles non fiables. « L’exploitation de ces failles peut se faire en surveillant les comportements suspects des liens symboliques », a déclaré Sysdig. À cet effet, le fournisseur a ajouté des règles de détection pour ses utilisateurs Secure et Falco.