Selon BleepingComputer, trois vulnérabilités nouvellement divulguées affectent le runtime de conteneurs runC, utilisé par Docker et Kubernetes.

Trois failles critiques dans runC (Docker / Kubernetes) permettent d’échapper au conteneur

Des vulnérabilités dévoilées cette semaine dans runC — le runtime de conteneurs de référence OCI utilisé par Docker et Kubernetes — peuvent permettre à un attaquant d’obtenir des accès en écriture au système hôte avec les privilèges root si elles sont exploitées. Les CVE sont CVE-2025-31133, CVE-2025-52565 et CVE-2025-52881 ; des correctifs sont inclus dans runC versions 1.2.8, 1.3.3, 1.4.0-rc.3 et ultérieures (CVE-2025-31133 & CVE-2025-52881 affectent toutes les versions ; CVE-2025-52565 impacte runC 1.0.0-rc3 et suivantes).

Détails techniques (résumé) :

  • CVE-2025-31133 — le mécanisme qui « masque » des fichiers sensibles avec des bind-mounts sur /dev/null peut être détourné si un attaquant remplace /dev/null par un lien symbolique pendant l’initialisation du conteneur, entraînant un montage en lecture-écriture d’une cible contrôlée par l’attaquant.
  • CVE-2025-52565 — des courses temporelles / symlinks sur le bind mount de /dev/console peuvent faire monter une cible inattendue avant l’application des protections, exposant des entrées procfs modifiables.
  • CVE-2025-52881 — runC peut être amené à écrire dans /proc et voir ces écritures redirigées vers des cibles contrôlées, contournant parfois des protections LSM et permettant des écritures arbitraires (ex. /proc/sysrq-trigger).

Exploitabilité & détection :
Les chercheurs notent que l’exploitation requiert la capacité de démarrer des conteneurs avec des configurations de mounts personnalisées — vecteur accessible via images Docker ou Dockerfile malveillants. Aucun cas d’exploitation en production n’a été signalé publiquement pour l’instant. Pour la détection, surveiller comportements suspects de création/modification de symlinks pendant l’initialisation des conteneurs et alerter sur écritures anormales vers procfs.

Mitigations & recommandations (immédiates) :

  1. Appliquer les correctifs : mettre à jour runC vers 1.2.8, 1.3.3, 1.4.0-rc.3 ou version ultérieure dès que possible.
  2. Activer les user namespaces pour tous les conteneurs sans mapper l’utilisateur root de l’hôte dans l’espace de noms du conteneur.
  3. Préférer les conteneurs rootless quand c’est possible pour réduire l’impact d’une escalade.
  4. Surveiller et bloquer comportements de symlinks/replace sur /dev/null, /dev/console et écritures inhabituelles vers /proc.
  5. Restreindre la capacité à lancer des conteneurs avec mounts arbitraires (politiques d’admission, scanning d’images, contrôle des Dockerfile/CI/CD).

En résumé : patcher rapidement et appliquer les recommandations de hardening (user namespaces / rootless / contrôle des images) pour éviter qu’une image ou un Dockerfile malveillant transforme une faille runC en breakout hôte.

L’article met l’accent sur la gravité potentielle de ces vulnérabilités, compte tenu de la place de runC dans les déploiements de conteneurs, et souligne le risque d’élévation d’accès au-delà du conteneur. Il s’agit d’un article de presse spécialisé signalant des vulnérabilités et leur impact potentiel.

🔗 Source originale : https://www.bleepingcomputer.com/news/security/dangerous-runc-flaws-could-allow-hackers-to-escape-docker-containers/

🖴 Archive : https://web.archive.org/web/20251110080509/https://www.bleepingcomputer.com/news/security/dangerous-runc-flaws-could-allow-hackers-to-escape-docker-containers/