Leaky Vessels : des vulnérabilités de Docker et runc permettant de s’évader des conteneurs (janvier 2024)

Rory McNamara, chercheur en sécurité chez Snyk, et l’équipe des Snyk Security Labs ont repéré quatre vulnérabilités surnommées « Leaky Vessels ». Ces vulnérabilités touchent des composants centraux de l’infrastructure des conteneurs et permettent justement de s’évader de ces derniers. Un attaquant pourrait utiliser ces moyens d’évasion pour obtenir depuis le conteneur un accès non autorisé au système d’exploitation sous-jacent. Ensuite, il pourrait potentiellement accéder aux données de ce système, notamment à des données sensibles (identifiants, informations client, etc.), et lancer de nouvelles attaques. Après avoir découvert, puis confirmé ces vulnérabilités, l’équipe des Security Labs a lancé le processus de divulgation responsable en commençant par alerter Docker, qui après examen, a communiqué l’une des vulnérabilités au groupe de sécurité du projet open source runc. Le calendrier de la divulgation est présenté ci-dessous. 

Ces vulnérabilités touchent des composants de bas niveau d’un moteur de conteneur et des outils de création de conteneurs. Par conséquent, Snyk recommande vivement aux utilisateurs de vérifier si les fournisseurs de leurs outils de génération et d’exécution de conteneurs, notamment leurs fournisseurs Docker et Kubernetes, les services de conteneurs dans le cloud et les communautés open source, proposent des mises à jour. Vous devez mettre à jour les systèmes exécutant des moteurs de conteneur et des outils de création de conteneurs dès que leurs fournisseurs proposent des correctifs.

À propos des vulnérabilités

Le 31 janvier 2024, les gestionnaires de runc, un outil CLI permettant de créer et d’exécuter des conteneurs sous Linux, ont annoncé la découverte d’une vulnérabilité (CVE-2024-21626) touchant la commande WORKDIR et liée à l’ordre des opérations. Cette vulnérabilité permet une évasion des conteneurs. En effet, l’exploitation de cette vulnérabilité peut permettre de quitter le conteneur pour accéder au système d’exploitation sous-jacent. Pour ce faire, il faudrait exécuter une image malveillante ou générer une image de conteneur à partir d’un fichier Dockerfile ou d’une image de base malveillante (par ex. avec FROM). D’après les gestionnaires, la version corrigée de l’outil, runc 1.1.12, a été publiée le 31 janvier 2024 à environ 15 h EST.

Pour en savoir plus, consultez cet article, qui évoque de manière générale la vulnérabilité qui a touché runc à proprement parler. Rory et l’équipe des Snyk Security Labs ont également repéré trois autres vulnérabilités du même type, soit quatre au total. Vous les trouverez ci-dessous, accompagnées des liens vers leur CVE et des articles de présentation correspondants :

• CVE-2024-21626 : runc process.cwd & leaked fds container breakout

• CVE-2024-23651 : Buildkit Mount Cache Race

• CVE-2024-23653 : Buildkit GRPC SecurityMode Privilege Check

• CVE-2024-23652 : Buildkit Build-time Container Teardown Arbitrary Delete

Outils Snyk permettant de détecter ces vulnérabilités

Ces vulnérabilités ne touchent pas les images des conteneurs, mais l’infrastructure et les outils de création sous-jacents. Snyk Container est une solution pensée pour aider les développeurs à éliminer les vulnérabilités de leurs images de conteneurs. Par conséquent, cette solution n’est pas adaptée dans cette situation. Néanmoins, nous avons développé deux outils open source qui font office d’implémentations de référence pour détecter les tentatives d’exploit de ces vulnérabilités. Notez que ces outils ne bénéficient pas de l’assistance Snyk. Il s’agit simplement d’exemples destinés à aider la communauté. 

Détection des exploits à l’exécution (leaky-vessels-runtime-detector)

La nouvelle équipe Helios de Snyk a créé un outil de détection à l’exécution pour cette vulnérabilité. Appelé leaky-vessels-runtime-detector et publié sous licence Apache-2.0, vous pourrez le trouver ici. Cet outil autonome fournit une implémentation de référence pour détecter les vulnérabilités au moment de leur exécution. Il associe des hooks eBPF à des fonctions du noyau et de niveau utilisateur, ainsi qu’à un détecteur de paquets. Il peut ainsi signaler les appels de création de conteneurs et les conteneurs en cours d’exécution qui présentent des caractéristiques suspectes. Attention, toutes les distributions et versions de Linux ne prennent pas en charge eBPF. Par ailleurs, il est peu probable que les clients de services cloud puissent l’utiliser.

Détection statique de commande de conteneur (leaky-vessels-static-detector)

Le deuxième outil est un programme d’analyse statique, leaky-vessels-static-detector, lui aussi publié sous licence Apache-2.0. Il analyse les fichiers Dockerfile et les couches des images pour détecter des commandes qui semblent essayer d’exploiter les vulnérabilités. Cet outil génère une sortie au format JSON qui indique s’il a détecté des commandes suspectes. Il est important de noter que chaque résultat demandera une vérification manuelle pour déterminer s’il s’agit véritablement d’un exploit ou d’une utilisation légitime des commandes de création de conteneurs.

Nous proposons ces deux outils en open source avec des implémentations de référence pour détecter des tentatives d’exploit. L’outil d’analyse au moment de l'exécution devrait probablement donner des résultats plus fiables que l’outil statique. Toutefois, en raison de la nature des exploits et des commandes de création, les deux produiront des faux négatifs et des faux positifs. Les membres de la communauté peuvent s’appuyer sur ces exemples pour créer leurs propres outils ou les exécuter directement dans leurs environnements. Il est important de noter que ces outils ne corrigent pas les vulnérabilités, pas plus qu’ils n’empêchent leur exploitation. Ils permettront néanmoins d’identifier les zones à risque. La stratégie la plus prudente consiste à mettre à jour les plateformes d’orchestration concernées dès que des correctifs sont disponibles. 

Ces vulnérabilités sont-elles activement exploitées ?

L’équipe de Snyk a vérifié des fichiers Dockerfile issus de registres publics en choisissant les images qu’elle a estimé être les plus utilisées. Cette étude n’a rien d’exhaustif, mais nous n’avons trouvé aucun élément suggérant que ces vulnérabilités soient exploitées. Snyk recommande de maintenir votre environnement sous surveillance et de vérifier vos conteneurs jusqu’à ce que des correctifs soient disponibles et déployés. En raison de la nature des problèmes, Snyk a créé deux outils open source, présentés ci-dessus. L’un est dynamique et montre comment détecter les actions liées à la vulnérabilité lors de l’exécution. L’autre est statique et permet d’analyser les images et fichiers Dockerfiles pour révéler un exploit potentiel.

Comment préparer la correction

La correction doit concerner l’infrastructure et les outils de code. Restez à l’affût de communiqués ou nouvelles versions, le cas échéant, du fournisseur de vos systèmes d’orchestration et de création de conteneurs.  Vous devrez probablement mettre à jour vos démons Docker et vos déploiements Kubernetes, ainsi que tout outil de création de conteneurs que vous utilisez dans vos pipelines CI/CD, vos serveurs de build et les stations de travail de vos développeurs. Il est également important d’analyser vos conteneurs existants avec des outils comme ceux proposés par Snyk pour déterminer si vos nœuds d’orchestration ou votre infrastructure de création sont déjà touchés.

Voici les dernières informations disponibles sur différents outils et services très utilisés :

Détail de la divulgation

Le calendrier de divulgation d’une vulnérabilité est parfois complexe, d’autant plus quand plusieurs acteurs sont dans la boucle. Il est impératif de procéder de manière responsable pour que les acteurs malveillants n’apprennent pas l’existence de la vulnérabilité avant qu’un correctif soit disponible. 

Dans le cas qui nous intéresse, les vulnérabilités ont été découvertes il y a deux mois. Snyk a alors lancé le processus de divulgation responsable. En voici les principaux jalons.

Chaque étape implique une collaboration au sein des organisations et entre les organisations. Ces organisations sont parfois des entreprises, mais aussi les équipes qui assurent la gestion des composants, dont les membres sont souvent des représentants variés de la communauté.

À propos de l’équipe des Snyk Security Labs

L’équipe des Snyk Security Labs a contribué à la divulgation de plus de 3 200 vulnérabilités dans des paquets de premier plan au sein de divers écosystèmes. Nous travaillons en étroite collaboration avec les gestionnaires de paquets open source pour nous assurer que toutes les vulnérabilités sont traitées de manière responsable et efficace. Notre expertise nous a permis de gagner la confiance de grands noms de la sécurité. Vous pensez avoir trouvé une vulnérabilité et ne savez pas comment la divulguer de manière responsable ? Renseignez ce formulaire pour obtenir de l’aide de nos équipes.

Les vulnérabilités Leaky Vessels ont-elles touché Snyk ?

Pour en savoir plus sur la façon dont Snyk traite les vulnérabilités dans son propre environnement, rendez-vous sur le portail de confiance Snyk.

En résumé

Nous mettrons cet article à jour dès que nous en saurons davantage et prévoyons d’organiser un webinaire intitulé Leaky Vessels Container Breakout Vulnerabilities - What You Need to Know le mardi 6 février à 11 h, heure de l’Est des États-Unis. Les experts techniques de Snyk y procéderont à une analyse technique approfondie de l’une de ces vulnérabilités, de ses origines, des façons dont elle peut être exploitée, et le plus important, des mises à jour et du suivi à mettre en place pour la résoudre.

Nous vous encourageons à nous faire part de toutes les questions que vous pouvez avoir sur ces vulnérabilités. Si vos questions portent sur nos outils open source, créez un ticket GitHub sur les outils concernés (dynamic-detector et static-detector) ou contactez-nous sur le Discord de la communauté Snyk. 

Pour en savoir plus sur les vulnérabilités Leaky Vessels, consultez les ressources suivantes :

• Leaky Vessels — runc Vulnerability Explained (YouTube)

• Leaky Vessels deep dive: Escaping from Docker one syscall at a time (article de blog)

• Hands-on lesson: runc process.cwd Container breakout vulnerability (Snyk Learn)

Cet article vous est fourni à titre d’information uniquement. Snyk ne saurait être tenu responsable de ses erreurs ou omissions ou des résultats obtenus par l’utilisation de ces informations.

Journal des modifications

• 31 janvier 2024, 15 h, heure de l’Est : publication initiale

• 31 janvier 2024, 18 h, heure de l’Est : ajout des URL des CVE et des informations sur AWS, containerd, GCP, Docker et Ubuntu

• 7 février 2024, 13 h, heure de l’Est : ajout de la vidéo YouTube et de liens d’analyse approfondie dans la section Résumé

• 8 février 2024, 10 h heure de l’Est : ajout de la leçon Snyk Learn à la section Résumé