Une vuln\u00e9rabilit\u00e9 CVE-2024-21626 a \u00e9t\u00e9 trouv\u00e9e dans l'outil de lancement de conteneurs isol\u00e9s runc, utilis\u00e9 dans Docker et Kubernetes, permettant d'acc\u00e9der au syst\u00e8me de fichiers de l'environnement h\u00f4te depuis un conteneur isol\u00e9. Lors d'une attaque, un malfaiteur peut \u00e9craser certains fichiers ex\u00e9cutables dans l'environnement h\u00f4te et ainsi ex\u00e9cuter son propre code en dehors du conteneur. Dans les environnements d'ex\u00e9cution crun et youki, qui utilisent runc, ainsi que dans LXC, le probl\u00e8me ne se manifeste pas. La vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 corrig\u00e9e dans la version runc 1.1.12. <\/p>\n
Lors de l'utilisation d'outils Docker ou Kubernetes, une attaque peut \u00eatre r\u00e9alis\u00e9e en pr\u00e9parant une image de conteneur sp\u00e9cialement con\u00e7ue, apr\u00e8s quoi, une fois install\u00e9e et lanc\u00e9e, il est possible d'acc\u00e9der au syst\u00e8me de fichiers externe depuis le conteneur. Avec Docker, il est possible d'exploiter cette vuln\u00e9rabilit\u00e9 via un Dockerfile sp\u00e9cialement con\u00e7u. La vuln\u00e9rabilit\u00e9 peut \u00e9galement \u00eatre exploit\u00e9e lors de l'ex\u00e9cution de processus dans le conteneur avec la commande \u00ab runc exec \u00bb en liant le r\u00e9pertoire de travail \u00e0 l'espace de noms de l'environnement h\u00f4te. <\/p>\n
La vuln\u00e9rabilit\u00e9 est caus\u00e9e par une fuite de descripteurs de fichiers internes. Avant l'ex\u00e9cution du code \u00e0 l'int\u00e9rieur du conteneur dans runc, tous les descripteurs de fichiers sont ferm\u00e9s \u00e0 l'aide du drapeau O_CLOEXEC. Cependant, apr\u00e8s l'ex\u00e9cution ult\u00e9rieure de la fonction setcwd(), un descripteur de fichier reste ouvert, pointant vers le r\u00e9pertoire de travail et continuant d'\u00eatre accessible apr\u00e8s le lancement du conteneur. Plusieurs sc\u00e9narios de base d'attaque sur l'environnement h\u00f4te, utilisant le descripteur de fichier restant, ont \u00e9t\u00e9 propos\u00e9s. <\/p>\n
Par exemple, un attaquant peut sp\u00e9cifier dans l'image du conteneur le param\u00e8tre process.cwd, pointant vers \u00ab \/proc\/self\/fd\/7\/ \u00bb, ce qui entra\u00eenera le lien du r\u00e9pertoire de travail au processus pid1 dans le conteneur, situ\u00e9 dans l'espace de montage de l'environnement h\u00f4te. Ainsi, dans l'image du conteneur, il est possible de configurer le lancement de \u00ab \/proc\/self\/fd\/7\/..\/..\/..\/bin\/bash \u00bb et, en ex\u00e9cutant un script shell, de remplacer le contenu de \u00ab \/proc\/self\/exe \u00bb, qui fait r\u00e9f\u00e9rence \u00e0 la copie h\u00f4te de \/bin\/bash. <\/p>\n
Une autre variante de l'attaque permet \u00e0 un attaquant, restreint au sein d'un conteneur, d'acc\u00e9der au r\u00e9pertoire de l'environnement h\u00f4te, si des processus privil\u00e9gi\u00e9s sont lanc\u00e9s dans le conteneur \u00e0 l'aide de la commande \u00ab runc exec \u00bb avec l'option \u00ab --cwd \u00bb. L'attaquant peut intercepter le chemin du processus lanc\u00e9 en le rempla\u00e7ant par un lien symbolique pointant vers \u00ab \/proc\/self\/fd\/7\/ \u00bb et par cons\u00e9quent, obtenir l'ouverture de \u00ab \/proc\/$exec_pid\/cwd \u00bb pour acc\u00e9der au syst\u00e8me de fichiers sur le c\u00f4t\u00e9 h\u00f4te. L'attaquant peut \u00e9galement r\u00e9ussir \u00e0 remplacer les fichiers ex\u00e9cutables sur l'environnement h\u00f4te en organisant le lancement d'un fichier ex\u00e9cutable depuis l'environnement h\u00f4te (\u00ab \/proc\/self\/fd\/7\/..\/..\/..\/bin\/bash \u00bb) avec un remplacement ult\u00e9rieur du fichier \u00ab \/proc\/$pid\/exe \u00bb, qui fait r\u00e9f\u00e9rence au fichier en cours d'ex\u00e9cution. <\/p>\n
De plus, cinq autres vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 identifi\u00e9es dans les composants de l'outil Docker : <\/p>\n