Dans l'outil de gestion des conteneurs Linux isolés Docker une vulnérabilité (), qui dans certaines circonstances permet d'accéder à l'environnement hôte depuis le conteneur lorsqu'il y a la possibilité de lancer ses propres images dans le système ou d'accéder au conteneur en cours d'exécution. Le problème se manifeste dans toutes les versions de Docker et reste non corrigé (proposé, mais pas encore accepté, , implémentant la suspension du fonctionnement du conteneur pendant l'exécution des opérations avec le système de fichiers).
La vulnérabilité permet d'extraire des fichiers du conteneur vers n'importe quelle partie du système de fichiers hôte lors de l'exécution de la commande «docker cp». L'extraction des fichiers se fait avec les droits root, ce qui permet de lire ou d'écrire n'importe quel fichier dans l'environnement hôte, ce qui est suffisant pour prendre le contrôle du système hôte (par exemple, il est possible de réécrire /etc/shadow).
L'attaque ne peut être réalisée que lors de l'exécution par l'administrateur de la commande «docker cp» pour copier des fichiers dans le conteneur ou en sortir. Ainsi, l'attaquant doit d'une manière ou d'une autre convaincre l'administrateur Docker de la nécessité d'exécuter cette opération et prévoir le chemin utilisé lors de la copie. D'autre part, l'attaque peut être réalisée, par exemple, lors de la fourniture par des services cloud de moyens pour copier des fichiers de configuration dans le conteneur, construits en utilisant la commande «docker cp».
Le problème est causé par un défaut dans l'application de la fonction , qui calcule le chemin absolu dans le système de fichiers principal sur la base d'un chemin relatif tenant compte de l'emplacement du conteneur. Au cours de l'exécution de la commande «docker cp», une brève , au cours de laquelle le chemin a déjà été vérifié, mais l'opération n'a pas encore été exécutée. Étant donné que la copie se fait dans le contexte du système de fichiers principal de l'hôte, il est possible de remplacer le lien vers un autre chemin et d'initier la copie de données à un endroit arbitraire du système de fichiers en dehors du conteneur pendant cette courte période.
Étant donné que la fenêtre temporelle de manifestation de l'état de course est fortement limitée dans le prototype Lors des opérations de copie à partir d'un conteneur, une attaque réussie a pu être effectuée dans moins de 1 % des cas en remplaçant de manière cyclique le lien symbolique dans le chemin utilisé pour l'opération de copie (l'attaque a été réussie après environ 10 secondes d'essais continus pour copier le fichier avec la commande « docker cp »).
Lors de l'opération de copie dans le conteneur, il est possible d'exécuter une attaque répétée sur la réécriture d'un fichier dans le système hôte en seulement quelques itérations. La possibilité d'attaque est liée au fait que lors de la copie dans le conteneur, le concept de « chrootarchive » est appliqué, selon lequel le processus archive.go extrait l'archive non dans le chroot racine du conteneur, mais dans le chroot du répertoire parent du chemin cible, contrôlé par l'attaquant, et ne stoppe pas l'exécution du conteneur (le chroot est utilisé comme un indicateur pour exploiter une condition de compétition).
Source : opennet.ru
