Une grave faille de sécurité dans runC peut entraîner une élévation des privilèges au niveau root dans Docker et Kubernetes

Une faille de sécurité découverte par Adam Iwaniuk et Borys Popławski dans le logiciel open source runC a été divulguée le 11 février 2019 et référencée sous le numéro CVE-2019-5736.

Cette vulnérabilité touche plusieurs moteurs de conteneurs, comme Docker et Kubernetes. Elle se trouve dans un composant essentiel de ces moteurs et permet aux conteneurs de sortir de leur environnement isolé et d’accéder au serveur hôte sur lequel ils s’exécutent. Ils peuvent ainsi accéder aux autres conteneurs et obtenir des privilèges root sur l’hôte.

Ce problème de sécurité fait suite à une vulnérabilité critique signalée le 3 décembre 2018, qui révélait qu’un composant de l’API Kubernetes était vulnérable à des attaques permettant d’exécuter des commandes arbitraires dans des conteneurs en cours d’exécution.

William Bowling a partagé sur Twitter une vidéo montrant la démonstration de l’attaque. Le binaire runC du serveur hôte est modifié depuis un conteneur en cours d’exécution à l’aide d’une version compromise :

Aujourd’hui, Iwaniuk et Popławski ont publié un article de blog détaillant l’attaque runC et expliquant ce qui les a conduits à mener les recherches ayant permis de découvrir la vulnérabilité.

La vulnérabilité

Comment cette vulnérabilité est-elle rendue possible ? Christian Brauner a écrit sur l’importance de comprendre la sémantique des conteneurs privilégiés et non privilégiés :

Un conteneur privilégié est un conteneur dans lequel la sémantique de l’ID 0 est la même à l’intérieur et à l’extérieur du conteneur, toutes choses égales par ailleurs. Je précise « toutes choses égales par ailleurs », car l’utilisation de LSM, de seccomp ou de tout autre mécanisme de sécurité ne change pas la signification de l’ID 0 à l’intérieur et à l’extérieur du conteneur. Par exemple, une évasion provoquée par un bogue dans l’implémentation du moteur d’exécution vous donnera un accès root sur l’hôte.

Dans un conteneur non privilégié, la sémantique de l’ID 0 à l’intérieur du conteneur diffère de celle de l’ID 0 à l’extérieur. Par exemple, une évasion provoquée par un bogue dans l’implémentation du moteur d’exécution ne vous donnera pas, par défaut, un accès root sur l’hôte. Cela ne devrait être possible que si l’implémentation des espaces de noms utilisateur du noyau présente un bogue.

La gravité élevée de cette vulnérabilité et son étendue s’expliquent par le fait que les conteneurs Docker s’exécutent par défaut avec des privilèges, ainsi que par la façon dont le binaire en ligne de commande runC est utilisé.

Comme l’explique Brauner, les implémentations de technologies de conteneurs telles que Docker exécutent le binaire runC à chaque commande destinée à un conteneur, puis le processus runC se termine. Par conséquent, un conteneur malveillant peut modifier le binaire runC, et toutes les commandes suivantes destinées aux conteneurs exécuteront le binaire runC modifié.

Cela diffère considérablement du fonctionnement de LXC, où un processus similaire ne se termine pas après l’exécution des commandes destinées aux conteneurs :

LXC ne peut pas être attaqué par le biais d’une image malveillante, car le processus de surveillance (unique pour chaque conteneur) ne s’arrête jamais pendant le cycle de vie du conteneur. Le noyau n’autorisant pas la modification des binaires en cours d’exécution, l’attaquant ne peut pas le corrompre. À l’arrêt ou à la suppression du conteneur, la tâche malveillante est arrêtée avant de pouvoir causer des dommages. Le processus de surveillance ne s’arrête que lorsque le dernier processus exécuté dans le conteneur a pris fin. Par conséquent, si vous exécutez des conteneurs OCI privilégiés avec notre modèle OCI et LXC, les images malveillantes ne vous exposent pas à cette vulnérabilité. Seul le vecteur passant par le binaire d’attachement reste applicable.

Cette vulnérabilité nous rappelle également le principe de sécurité du moindre privilège et les bonnes pratiques qui recommandent souvent de veiller à ce que le maillon le plus faible ne puisse pas servir de point de départ à une escalade de privilèges ou à l’exploitation d’autres failles.

Enjeux de sécurité et divulgation responsable

Le principe fondamental de la conteneurisation est d’isoler les différentes applications et les différents services. Il est donc légitime de s’inquiéter lorsque ce n’est pas le cas.

Les attaques visant la chaîne d’approvisionnement logicielle ne sont pas nouvelles dans l’univers des conteneurs et ont également fait la une de l’actualité concernant les bibliothèques applicatives. Dans un article publié sur threatpost en 2018, les recherches du Kromtech Security Center ont révélé que plus de dix-sept conteneurs malveillants étaient activement utilisés pour des activités illégales de cryptominage. Les images malveillantes étaient hébergées sur Docker Hub, le registre public officiel des images Docker, avant d’en être supprimées.

Dans une mise à jour sur la vulnérabilité runC, Aleksa Sarai, responsable de la maintenance de runC et ingénieur logiciel senior chez SUSE Linux, a indiqué hier qu’une autre technologie de conteneurs Linux, appelée LXC, était également vulnérable à la CVE mentionnée plus haut, mais par le biais d’un vecteur d’attaque différent.

Il a également été indiqué que le code d’exploitation serait rendu public le 18 février afin de tester et de vérifier que la vulnérabilité a bien été corrigée, et les utilisateurs ont été invités à appliquer les correctifs de manière responsable.

Si vous n’avez pas encore essayé Snyk, pensez à utiliser notre CLI pour lancer des tests en local ou à connecter vos dépôts de code source afin d’automatiser l’analyse et la correction. Si vous utilisez déjà Snyk, sachez que nous suivons cette vulnérabilité dans notre base de données.

Nous sommes heureux de constater que l’Open Container Initiative (OCI) a ajouté un fichier SECURITY.md à son registre afin de fournir aux chercheurs des consignes de divulgation responsable des problèmes de sécurité. Nous avions recommandé cette mesure par le passé, ainsi que d’autres bonnes pratiques de gestion sécurisée du code source, que vous trouverez dans nos bonnes pratiques de sécurité GitHub.

À retenir

• Évitez d’exécuter des images de base de conteneurs non fiables et non vérifiées.

• Appliquez toujours le principe du moindre privilège et choisissez d’exécuter des conteneurs non privilégiés.

• Analysez les bibliothèques open source à la recherche de vulnérabilités afin de repérer les serveurs non corrigés que vous pourriez avoir et qui restent vulnérables à cette CVE.