Une faille dans Runc rend vulnérable Docker et Kubernetes

Une vulnérabilité dans le runtime de container Runc met à mal la sécurité des environnements Docker, Kubernetes mais également Apache Mesos. Un patch est disponible pour éviter une prise de contrôle et l’exécution de containers malveillants au niveau du code racine.

Encore une mauvaise nouvelle pour les entreprises faisant appel à l’outil d’orchestration de containers Kubernetes. Après une première faille critique en décembre 2018, une autre vulnérabilité a été trouvée. Découverte par les chercheurs en sécurité Adam Iwaniuk et Borys Poplawski, cette faille touche non seulement l’orchestrateur, mais également Docker ainsi que les environnements LXC, Apache Mesos, cri-o et containerd. Cette vulnérabilité touche plus spécifiquement le runtime de container Runc, un composant essentiel pour démarrer les containers, bien qu’il ne prenne pas en charge les activités de plus haut niveau (gestion des images, pull, API…).

Dans un billet de blog, Aleksa Sarai, l’un des développeurs chargé de maintenir Runc, a livré quelques précisions sur le niveau de dangerosité de cette faille et ses conséquences. « Cette vulnérabilité permet à un conteneur malveillant (avec une interaction minimale de l’utilisateur) d’écraser le fichier binaire runc de l’hôte et d’obtenir ainsi une exécution de code de niveau racine sur l’hôte », explique Aleksa Sarai. « Le niveau d’interaction de l’utilisateur permet d’exécuter n’importe quelle commande au niveau racine d’un conteneur dans l’un ou l’autre des contextes suivants : création d’un nouveau conteneur à l’aide d’une image contrôlée par l’attaquant, exécution d’un conteneur Docker existant auquel l’attaquant disposait auparavant d’un accès en écriture ».

Identifiée en tant que CVE-2019-5736, cette faille n’est pas bloquée par défaut par les règles AppArmor et SELinux mais peut l’être pour peu qu’une utilisation correcte des espaces de noms d’utilisateurs soit réalisée « où la racine de l’hôte n’est pas mappée dans l’espace de noms d’utilisateur du conteneur », précise Aleksa Sarai. Un patch a été proposé et le code de l’exploit va être poussé auprès des fournisseurs de cloud public afin de pallier la vulnérabilité avant qu’elle soit publique d’ici 7 jours.