Des chercheurs en sécurité ont découvert quatre vulnérabilités dans des composants de Docker qui pourraient permettre à des attaquants d'accéder à des systèmes d'exploitation hôtes à partir de conteneurs. L'une de ces vulnérabilités se trouve dans runc, un outil de ligne de commande permettant de créer et d'exécuter des conteneurs sous Linux, qui est à la base de plusieurs moteurs de conteneurs, et pas seulement de Docker. Ce n'est pas la première fois que ce runtime de container est touché par des failles de sécurité. Les vulnérabilités ont été découvertes par Rory McNamara, un chercheur de la société de sécurité informatique Snyk, qui les a collectivement baptisées « Leaky Vessels », car elles permettent de rompre la couche d'isolation critique entre les conteneurs et le système d'exploitation hôte. « Ces évasions de conteneurs pourraient permettre à un attaquant d'obtenir un accès non autorisé au système d'exploitation hôte sous-jacent à partir du conteneur et potentiellement permettre l'accès à des données sensibles (identifiants, informations sur les clients, etc.), et lancer d'autres attaques, en particulier lorsque l'accès obtenu comprend des privilèges de super-utilisateur », a déclaré Snyk dans un billet de blog.

De multiples voies d'attaque à partir de runc

Runc peut être considéré comme la tuyauterie qui relie la plupart des moteurs de gestion de conteneurs tels que Docker, containerd, Podman et CRI-O aux fonctionnalités de sandboxing du noyau Linux : groupes de contrôle, espaces de noms, seccomp, apparmor, etc. Il prend en charge plusieurs commandes pour démarrer, arrêter, suspendre, mettre en pause et répertorier les conteneurs, ainsi que pour exécuter des processus à l'intérieur des conteneurs. La faille dans runc découverte par Rory McNamara, répertoriée sous le nom de CVE-2024-21626, provient d'un descripteur de fichier divulgué par inadvertance en interne au sein de runc, y compris un handle vers le groupe /sys/fs/c de l'hôte. Ceci peut être exploité de plusieurs façons : une repérée par McNamara et trois autres trouvées par les mainteneurs de runc. « Si le conteneur a été configuré pour que process.cwd soit défini sur /proc/self/fd/7/ (le fd réel peut changer en fonction de l'ordre d'ouverture des fichiers dans runc), le processus pid1 résultant aura un répertoire de travail dans l'espace de noms de montage de l'hôte et le processus engendré pourra donc accéder à l'ensemble du système de fichiers de l'hôte », avertissent les responsables de runc dans une note d'information. « Cela ne constitue pas en soi un exploit contre runc. Cependant, une image malveillante pourrait faire de n'importe quel chemin non-/ d'apparence inoffensive un lien symbolique vers /proc/self/fd/7/ et ainsi tromper un utilisateur en lui faisant démarrer un conteneur dont le binaire a accès au système de fichiers de l'hôte ». Cet exploit cible la commande runc run, qui est utilisée pour créer et démarrer un conteneur à partir d'une image. De nombreux conteneurs sont démarrés à partir d'images téléchargées à partir de dépôts publics tels que Docker Hub et des images malveillantes ont été téléchargées dans le registre au fil du temps.

Une autre variante de l'attaque concerne runc exec utilisé pour démarrer un processus à l'intérieur d'un conteneur existant. Pour ce faire, l'attaquant doit savoir qu'un processus administratif appelle runc exec avec l'argument -cwd et un chemin spécifique, puis remplacer ce chemin par un lien symbolique vers le descripteur de fichier /proc/self/fd/7. Une troisième attaque consiste à utiliser la technique runc run ou runc exec pour écraser les binaires du système d'exploitation hôte, tels que /bin/bash - l'interpréteur de commandes de Linux. Ces deux variantes sont connues sous le nom d'attaques 3a et 3b. « Alors que l'attaque 3a est la plus grave du point de vue de CVSS, les attaques 2 et 3b sont sans doute plus dangereuses en pratique car elles permettent une évasion depuis l'intérieur d'un conteneur plutôt que d'exiger qu'un utilisateur exécute une image malveillante », ont prévenu les responsables de runc. Cependant, cela dépend du contexte. Par exemple, dans les systèmes d'exécution de niveau supérieur comme Docker ou Kubernetes, toute personne ayant les droits de démarrer une image de conteneur peut exécuter l'exploit à distance. L'attaque peut également être lancée en utilisant la fonction ONBUILD dans les fichiers Docker. Bien que runc soit probablement le runtime de conteneur le plus populaire et le plus utilisé en raison de son association avec Docker, ce n'est pas le seul disponible. Les responsables de runc préviennent que d'autres runtimes sont potentiellement vulnérables à des attaques similaires ou ne disposent pas d'une protection suffisante contre celles-ci.

Comment atténuer la vulnérabilité runc de Docker

En plus du trou de sécurité runc, corrigé dans la dernière version 1.1.12, Rory McNamara a également trouvé des vulnérabilités d'échappement de conteneur dans d'autres composants Docker tels que BuildKit (CVE-2024-23652 et CVE-2024-23653) et une condition de course de cache (CVE-2024-23651). 

« Recherchez les annonces du fournisseur de vos systèmes de déploiement et d'orchestration de conteneurs concernant les mises à jour pour résoudre le problème ou les déclarations dans les cas où ils ne sont pas affectés », ont déclaré les chercheurs de Snyk. « Cela signifie probablement que vous devez mettre à jour vos Docker Daemon et vos déploiements Kubernetes, ainsi que tous les outils de construction de conteneurs que vous utilisez dans les pipelines CI/CD, sur les serveurs de construction et sur les postes de travail de vos développeurs ». Snyk a également développé deux outils open source qui permettent aux utilisateurs de surveiller leurs conteneurs pour détecter les signes de tentatives d'exploitation. L'un est un scanner d'exécution qui utilise des crochets eBPF pour surveiller les invocations suspectes de commandes de construction et d'exécution de conteneurs qui correspondent aux modèles de cet exploit, et l'autre est un scanner statique pour les fichiers et les images Docker.