Vulnérabilité : évasion de conteneur avec runc, process.cwd et des descripteurs de fichiers (CVE-2024-21626)

Snyk a détecté une vulnérabilité dans toutes les versions de runc jusqu’à la 1.1.11. Cet utilitaire est utilisé par Docker Engine, mais aussi d’autres technologies de conteneurisation comme Kubernetes. Son exploitation peut permettre de quitter le conteneur pour atteindre le système d’exploitation hôte, soit par l’exécution d’une image malveillante, soit par la création d’une image à partir d’un fichier Dockerfile ou d’une image de base de nature malveillante (par exemple avec la commande FROM). Cette vulnérabilité est associée à la CVE-2024-21626.

Fonctionnement de la vulnérabilité CVE-2024-21626

Démo 1 : évasion du conteneur via la commande docker build. Dans cet exemple, nous exploitons la commande docker build pour quitter le conteneur et accéder au système de fichiers de l’hôte par des opérations arbitraires de lecture (ici, du fichier /etc/shadow de l’hôte) et d’écriture (le fichier DOCKER_BUILD_BREAKOUT).

Démo 2 : évasion du conteneur via la commande docker run. Dans cet exemple, nous montrons que l’exécution d’une image Docker malveillante basée sur la même vulnérabilité permet également de s’évader du conteneur Docker pour accéder au système d’exploitation hôte.

Cette vulnérabilité est liée à l’ordre des opérations effectuées lors de l’exécution de la directive WORKDIR définie dans le fichier Dockerfile. WORKDIR définit le répertoire de travail initial de l’ensemble des processus créés par le fichier Dockerfile, par exemple ceux exécutés lors de la création du conteneur avec la directive RUN et ceux exécutés lors de l’exécution du conteneur avec les directives CMD ou ENTRYPOINT. Le répertoire fourni est transmis avec la commande chdir avant que certains descripteurs de fichiers avec privilèges du répertoire hôte soient fermés. Il est possible de spécifier l’un de ces descripteurs de fichier en choisissant /proc/self/fd/ comme argument pour chdir. Ainsi, le descripteur de fichier à privilèges reste accessible même après que le descripteur de fichier lui-même est fermé lors des opérations standard, avant le passage à la commande définie dans le fichier Dockerfile, au moment de la création ou de l’exécution.

Lors d’une attaque réussie, le processus désormais en cours d’exécution vérifie que le répertoire actuel est un répertoire de l’hôte et traverse la structure des répertoires pour accéder à l’ensemble du système de fichiers racine de l’hôte. Par défaut, les privilèges d’accès sont les mêmes que ceux de la solution de conteneurisation utilisée, par exemple Docker Engine ou Kubernetes. Généralement, ces privilèges correspondent à ceux de l’utilisateur racine, et il est donc possible de passer de l’accès au disque à l’exécution de commandes root complètes sur l’hôte.

Comment résoudre la vulnérabilité CVE-2024-21626

runc a corrigé la vulnérabilité en s’assurant que le répertoire spécifié dans la directive WORKDIR existe dans le système de fichier racine du conteneur. runc a également mis en place des étapes de vérification supplémentaires pour garantir que les descripteurs de fichiers à privilège du répertoire hôte étaient bien fermés directement après leur utilisation.

Snyk recommande de prendre immédiatement les mesures nécessaires pour corriger la vulnérabilité, conformément à l’avis de runc. La version 1.1.12 de runc inclut un correctif. Les technologies reposant sur runc doivent également être mises à jour pour inclure ce correctif, et les avis des fournisseurs doivent être suivis dans le cas de solutions hébergées (services Kubernetes gérés des grands prestataires de cloud, par exemple).

Évaluation du risque

Cette vulnérabilité ne peut être exploitée que si un conteneur malveillant est exécuté ou créé au sein d’une infrastructure vulnérable. De par sa nature, elle est difficile à détecter. Une vérification au moment de l'exécution est le plus efficace pour y parvenir. Nos produits n’analysent pas les applications en cours d’exécution, et nous avons donc créé deux outils spécifiques.

Détection au moment de l'exécution

La nouvelle équipe Helios de Snyk a créé un outil de détection à l’exécution basé sur eBPF pour cette vulnérabilité. Appelé leaky-vessels-runtime-detector et publié sous licence Apache-2.0, vous pourrez le trouverici. eBPF est un mécanisme d’instrumentation fréquent intégré dans de nombreux noyaux Linux modernes.

Cet outil est capable d’identifier un conteneur en cours d’exécution qui tente d’exploiter cette vulnérabilité sur l’infrastructure sous-jacente et fait donc courir un risque à l’hôte. Attention : il ne bloque pas cette exploitation, mais ne fait qu’alerter.

Nous vous recommandons vivement de mettre à jour votre infrastructure de conteneur, mais vous pouvez néanmoins évaluer votre risque ou votre exposition à l’aide de cet outil s’il ne vous est pas possible de réaliser cette mise à jour dans l’immédiat. Les entreprises doivent se rapprocher du fournisseur de leur infrastructure de conteneur pour déterminer si celle-ci a été corrigée.

Installation et utilisation

Pour installer et utiliser notre outil de détection statique, procédez comme suit :

1. Clonez le dépôt https://github.com/snyk/leaky-vessels-dynamic-detector.

2. Compilez le fichier binaire Go avec la commande go build.

3. Exécutez l’outil de détection dans votre environnement de CI avec la commande sudo ./ebpf-detector.

Pour plus d’informations, consultez le fichier README.md.

Analyse statique

Si vous préférez éviter d’exécuter un fichier binaire sur votre hôte ou votre pipeline CI/CD, nous avons aussi créé un outil d’analyse statique, disponible sur https://github.com/snyk/leaky-vessels-static-detector, qui analyse les fichiers Docker et signale les tentatives d’exploit potentielles.

Cet outil examine les images en analysant le code de l’instruction FROM ou en interrogeant directement le démon Docker local ou les registres de conteneurs publics comme Dockerhub ou GCR. L’historique de l’image n’inclut pas toutes les instructions d’un fichier Dockerfile complet, mais il présente les instructions WORKDIR et ONBUILD de l’image parent, qui peuvent contenir des indices sur la malveillance potentielle d’une image.

Cet outil est utile pour se protéger des cas dans lesquels une image de base tierce a été corrompue et essaie d’exploiter les commandes run ou build de l’image enfant. L’approche statique présente un plus grand taux de faux positifs, en particulier pour les exploits qui utilisent la commande --mount flag, mais elle permet de détecter les images qu’il convient d’analyser plus en détail.

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.

Comme toujours, l’utilisation d’images de base correctement gérées par des sources de confiance et l’installation des versions les plus récentes, en effaçant les caches et en vérifiant la provenance des images, restent recommandées.

Installation et utilisation

Pour installer et utiliser notre outil de détection statique, procédez comme suit :

1. Clonez le dépôt https://github.com/snyk/leaky-vessels-static-detector.

2. Compilez le fichier binaire Go avec la commande go build.

3. Exécutez l’outil avec la commande ./static-detector dockerfile -f [PATH_TO_DOCKERFILE].

4. Pour plus d’informations, consultez le fichier README.md.

CVE-2024-21626 : résumé et recommandations

Cette vulnérabilité d’évasion de conteneur est grave et peut entraîner des dégâts sur toute infrastructure hôte sous-jacente qui exécute ou crée des conteneurs.

Snyk vous recommande de mettre à jour toutes les instances de runc vers la version 1.1.12 ou une version ultérieure, ainsi que tout logiciel dépendant de cet utilitaire. Par ailleurs, veillez à suivre les avis des fournisseurs en lien avec ce problème, car les services et infrastructures d’hébergement des conteneurs peuvent aussi être touchés.

Les recherches de Snyk ont également abouti à la découverte d’autres vulnérabilités du même type, dont les CVE sont les suivantes : CVE-2024-23652, CVE-2024-23651 et CVE-2024-23653. Vous pouvez consulter le résumé de nos découvertes pour toutes ces CVE ici.

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.