Dans la boîte à outils de gestion des conteneurs Linux Docker isolés vulnérabilité (), qui, dans certaines circonstances, autorise l'accès à l'environnement hôte depuis un conteneur lorsqu'il est possible d'exécuter ses images sur le système ou lors de l'accès au conteneur en cours d'exécution. Ce problème survient dans toutes les versions de Docker et reste non résolu (proposé, mais pas encore accepté). , qui implémente la suspension du fonctionnement du conteneur pendant l'exécution des opérations avec le FS).
Cette vulnérabilité permet d'extraire des fichiers d'un conteneur vers une partie arbitraire du système de fichiers hôte lors de l'exécution de la commande « docker cp ». L'extraction des fichiers s'effectue avec les privilèges root, ce qui permet de lire et d'écrire n'importe quel fichier dans l'environnement hôte, ce qui suffit pour prendre le contrôle du système hôte (par exemple, vous pouvez réécrire /etc/shadow).
L'attaque ne peut être réalisée que lorsque l'administrateur exécute la commande « docker cp » pour copier des fichiers vers ou depuis le conteneur. L'attaquant doit donc convaincre l'administrateur Docker de la nécessité d'effectuer cette opération et prévoir le chemin d'accès utilisé pour la copie. En revanche, l'attaque peut être réalisée, par exemple, lorsque les services cloud fournissent des outils permettant de copier des fichiers de configuration vers un conteneur créé à l'aide de 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 à partir du chemin relatif, en tenant compte de l'emplacement du conteneur. Une courte pause est observée lors de l'exécution de la commande « docker cp ». , où le chemin a déjà été vérifié, mais l'opération n'a pas encore été effectuée. La copie étant effectuée dans le contexte du système de fichiers principal du système hôte, il est possible, dans le délai spécifié, de remplacer le lien par un autre chemin et de lancer la copie des données vers un emplacement arbitraire du système de fichiers, hors du conteneur.
Étant donné que la fenêtre de temps pour que la condition de course se manifeste est très limitée dans le système préparé Lors de l'exécution d'opérations de copie à partir d'un conteneur, il était possible de réaliser une attaque réussie dans moins de 1 % des cas en remplaçant cycliquement un lien symbolique dans le chemin utilisé dans l'opération de copie (une attaque réussie a été réalisée après environ 10 secondes de tentative continue de copier un fichier dans une boucle avec la commande « docker cp »).
Lors d'une copie vers un conteneur, il est possible de réaliser une attaque répétable visant à écraser un fichier sur le système hôte en quelques itérations seulement. Cette attaque est rendue possible grâce au concept de « chrootarchive » utilisé lors de la copie vers un conteneur. Selon ce concept, le processus archive.go extrait l'archive non pas vers le chroot de la racine du conteneur, mais vers le chroot du répertoire parent du chemin cible contrôlé par l'attaquant, sans interrompre l'exécution du conteneur (le chroot est utilisé comme indicateur d'exploitation d'une situation de concurrence).
Source: opennet.ru
