Ils ont détecté une vulnérabilité qui permet d'exécuter du code en dehors du conteneur et affecte Docker et Kubernetes

vulnérabilité

Si elles sont exploitées, ces failles peuvent permettre aux attaquants d'obtenir un accès non autorisé à des informations sensibles ou de causer des problèmes en général.

Récemment, les nouvelles du ddécouverte de nouvelles vulnérabilités dans runC (un outil CLI pour créer et exécuter des conteneurs sous Linux) CVE-2024-21626 et dans BuildKit (CVE-2024-23651, CVE-2024-23652 et CVE-2024-23653), étant celui qui suscite le plus de préoccupations CVE-2024-21626, puisqu'il s'agit d'une vulnérabilité critique qui permet d'accéder au système de fichiers du système d'exploitation hôte.

CVE-2024-21626 permet d'accéder au système de fichiers de l'environnement hôte à partir d'un conteneur isolé. Lors d'une attaque, un attaquant peut écraser certains fichiers exécutables dans l'environnement hôte et exécuter son code en dehors du conteneur.

Ceci est particulièrement préoccupant dans des environnements comme Kubernetes, où les conteneurs s'exécutent sur des nœuds partagés. En exploitant cette vulnérabilité, un attaquant peut obtenir un contrôle privilégié sur l'hôte, accordant potentiellement un accès non autorisé à d'autres pods et aux données d'autrui sur le même nœud.

De plus, cette vulnérabilité affecte également les processus de build exécutés dans des environnements de conteneurs, donnant aux attaquants la possibilité de prendre pied dans un processus de construction. Ce scénario pourrait amener un attaquant à obtenir des informations d'identification élevées, ce qui vous donnerait accès aux charges de travail de production critiques ou à d’autres environnements sensibles. Essentiellement, l’impact s’étend au-delà de la simple fuite d’informations ou de l’exécution de code arbitraire, et pourrait compromettre l’intégrité et la sécurité de l’ensemble de l’environnement de développement et de production.

Dans les environnements où Docker ou Kubernetes sont utilisés, une attaque peut être menée à l'aide d'une image de conteneur spécialement conçue. Une fois cette image installée et lancée, l'attaquant peut accéder à un système de fichiers externe depuis le conteneur. Dans le cas de Docker, il est possible d'opérer via un Dockerfile spécialement conçu. La vulnérabilité peut également être exploitée si des processus sont démarrés dans un conteneur à l'aide de la commande "runc exec" et en liant le répertoire de travail à l'espace de noms de l'environnement hôte.

Le problème principal est une fuite de descripteur de fichier et en faisant O_CLOEXEC tout le descripteurs de fichiers avant d'exécuter le code du conteneur, le fichier le descripteur est ouvert lors de l'exécution de setcwd(2), ce qui signifie que la référence peut être conservé en vie dans le conteneur en définissant le mode de travail du répertoire comme chemin résolu via le descripteur de fichier (vousLe bit non-dumpable n'est pas défini après execve(2), ce qui signifie qu'il y a plusieurs façons d'attaquer cela en plus des mauvaises configurations).

La cause de la vulnérabilité réside dans la fuite des descripteurs de fichiers internes. Avant d'exécuter le code à l'intérieur du conteneur, runc ferme tous les descripteurs de fichiers à l'aide de l'indicateur O_CLOEXEC. Cependant, les exécutions ultérieures de setcwd() laissent ouvert un descripteur de fichier qui pointe vers le répertoire de travail et reste accessible après le démarrage du conteneur. Plusieurs scénarios de base ont été proposés pour attaquer l'environnement hôte en utilisant le descripteur de fichier restant.

Il est mentionné que un exemple d'exploitation de vulnérabilité est si un conteneur a été configuré :

Pour définir process.cwd sur /proc/self/fd/7/, le processus pid1 résultant aura un répertoire de travail dans l'espace de noms de montage de l'hôte, et par conséquent le processus généré pourra accéder à l'ensemble des fichiers hôtes du système. Cela ne constitue pas à lui seul un exploit contre runc. Un attaquant peut également inciter un utilisateur à exécuter une image de conteneur malveillante, permettant ainsi à un processus de conteneur d'atteindre le système de fichiers hôte via runc. Cela peut s'étendre à l'écrasement des fichiers binaires de l'hôte, entraînant un échappement complet du conteneur. 

Enfin, il convient de mentionner que La vulnérabilité a été corrigée dans la version runc 1.1.12, il est donc recommandé de mettre à jour vers la nouvelle version. Si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.