Annonces de sécurité Docker

Mise à jour de sécurité Docker Desktop 4.41.0 : CVE-2025-3224, CVE-2025-4095, et CVE-2025-3911

Dernière mise à jour le 15 mai 2025

Trois vulnérabilités dans Docker Desktop ont été corrigées le 28 avril dans la version 4.41.0.

• Correction de CVE-2025-3224 permettant à un attaquant ayant accès à une machine utilisateur d'effectuer une élévation de privilèges lors des mises à jour de Docker Desktop.
• Correction de CVE-2025-4095 où les politiques de Gestion d'Accès au Registre (RAM) n'étaient pas appliquées lors de l'utilisation d'un profil de configuration MacOS, permettant aux utilisateurs de tirer des images depuis des registres non approuvés.
• Correction de CVE-2025-3911 permettant à un attaquant avec accès en lecture à la machine d'un utilisateur d'obtenir des informations sensibles à partir des fichiers de log de Docker Desktop, y compris les variables d'environnement configurées pour l'exécution de conteneurs.

Nous vous encourageons fortement à mettre à jour vers Docker Desktop 4.41.0.

Mise à jour de sécurité Docker Desktop 4.34.2 : CVE-2024-8695 et CVE-2024-8696

Dernière mise à jour le 13 septembre 2024

Deux vulnérabilités d'exécution de code à distance (RCE) dans Docker Desktop liées aux Extensions Docker ont été signalées par Cure53 et ont été corrigées le 12 septembre dans la version 4.34.2.

• CVE-2024-8695 : Une vulnérabilité d'exécution de code à distance (RCE) via une description/changelog d'extension contrefaite pourrait être exploitée par une extension malveillante dans Docker Desktop avant la version 4.34.2. [Critique]
• CVE-2024-8696 : Une vulnérabilité d'exécution de code à distance (RCE) via une publisher-url/additional-urls d'extension contrefaite pourrait être exploitée par une extension malveillante dans Docker Desktop avant la version 4.34.2. [Élevé]

Aucune extension existante exploitant les vulnérabilités n'a été trouvée dans la Marketplace des Extensions. L'équipe Docker surveillera de près et examinera attentivement toute demande de publication de nouvelles extensions.

Nous vous encourageons fortement à mettre à jour vers Docker Desktop 4.34.2. Si vous ne pouvez pas mettre à jour rapidement, vous pouvez désactiver les Extensions Docker comme solution de contournement.

Dépréciation des connexions par mot de passe sur CLI lorsque SSO est appliqué

Dernière mise à jour juillet 2024

Lorsque l'application SSO a été introduite pour la première fois, Docker a fourni une période de grâce pour continuer à permettre l'utilisation des mots de passe sur le CLI Docker lors de l'authentification à Docker Hub. Cela était autorisé pour que les organisations puissent plus facilement utiliser l'application SSO. Il est recommandé que les administrateurs configurant SSO encouragent les utilisateurs utilisant le CLI à passer aux Jetons d'Accès Personnels en prévision de la fin de cette période de grâce.

Le 16 septembre 2024, la période de grâce se terminera et les mots de passe ne pourront plus authentifier sur Docker Hub via le CLI Docker lorsque SSO est appliqué. Les utilisateurs concernés sont tenus de passer à l'utilisation de PAT pour continuer à se connecter.

Chez Docker, nous voulons que l'expérience soit la plus sécurisée pour nos développeurs et organisations et cette dépréciation est une étape essentielle dans cette direction.

Attestation SOC 2 Type 2 et certification ISO 27001

Dernière mise à jour juin 2024

Docker est heureux d'annoncer que nous avons reçu notre attestation SOC 2 Type 2 et notre certification ISO 27001 sans exceptions ou non-conformités majeures.

La sécurité est un pilier fondamental des opérations de Docker, qui est intégré dans notre mission globale et notre stratégie d'entreprise. Les produits de Docker sont au cœur de notre communauté d'utilisateurs et notre attestation SOC 2 Type 2 et notre certification ISO 27001 démontrent l'engagement continu de Docker envers la sécurité pour notre base d'utilisateurs.

Pour plus d'informations, voir l'annonce du blog.

Avis de sécurité Docker : Multiples vulnérabilités dans runc, BuildKit, et Moby

Dernière mise à jour le 2 février 2024

Chez Docker, nous priorisons la sécurité et l'intégrité de notre logiciel ainsi que la confiance de nos utilisateurs. Les chercheurs en sécurité de Snyk Labs ont identifié et signalé quatre vulnérabilités de sécurité dans l'écosystème des conteneurs. Une des vulnérabilités, CVE-2024-21626, concerne le runtime de conteneur runc, et les trois autres affectent BuildKit (CVE-2024-23651, CVE-2024-23652, et CVE-2024-23653). Nous voulons assurer notre communauté que notre équipe, en collaboration avec les rapporteurs et les mainteneurs open source, a travaillé diligemment sur la coordination et l'implémentation des remédiations nécessaires.

Nous nous engageons à maintenir les plus hauts standards de sécurité. Nous avons publié des versions corrigées de runc, BuildKit, et Moby le 31 janvier et avons publié une mise à jour pour Docker Desktop le 1er février pour traiter ces vulnérabilités. De plus, nos dernières versions de BuildKit et Moby incluaient des corrections pour CVE-2024-23650 et CVE-2024-24557, découvertes respectivement par un chercheur indépendant et par les initiatives de recherche interne de Docker.

Que dois-je faire si je suis sur une version affectée ?

Si vous utilisez des versions affectées de runc, BuildKit, Moby, ou Docker Desktop, assurez-vous de mettre à jour vers les dernières versions, liées dans le tableau suivant :

Si vous ne pouvez pas mettre à jour vers une version non affectée rapidement, suivez ces meilleures pratiques pour atténuer le risque :

• Utilisez uniquement des images Docker de confiance (telles que les Images Officielles Docker).
• Ne construisez pas d'images Docker à partir de sources non fiables ou de Dockerfiles non fiables.
• Si vous êtes un client Docker Business utilisant Docker Desktop et incapable de mettre à jour vers v4.27.1, assurez-vous d'activer les fonctionnalités Docker Desktop Durci telles que :
  • Isolation de Conteneurs Renforcée, qui atténue l'impact de CVE-2024-21626 dans le cas d'exécution de conteneurs à partir d'images malveillantes.
  • Gestion d'Accès aux Images, et Gestion d'Accès au Registre, qui donnent aux organisations le contrôle sur les images et registres auxquels leurs utilisateurs peuvent accéder.
• Pour CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, et CVE-2024-23653, évitez d'utiliser un frontend BuildKit provenant d'une source non fiable. Une image frontend est généralement spécifiée comme la ligne #syntax de votre Dockerfile, ou avec le flag --frontend lors de l'utilisation de la commande buildctl build.
• Pour atténuer CVE-2024-24557, assurez-vous d'utiliser BuildKit ou de désactiver la mise en cache lors de la construction d'images. À partir du CLI, cela peut être fait via la variable d'environnement DOCKER_BUILDKIT=1 (par défaut pour Moby >= v23.0 si le plugin buildx est installé) ou le flag --no-cache. Si vous utilisez l'API HTTP directement ou via un client, la même chose peut être faite en définissant nocache sur true ou version sur 2 pour le point de terminaison API /build.

Détails techniques et impact

CVE-2024-21626 (Élevé)

Dans runc v1.1.11 et antérieures, en raison de certains descripteurs de fichiers divulgués, un attaquant peut accéder au système de fichiers hôte en causant qu'un processus de conteneur nouvellement engendré (à partir de runc exec) ait un répertoire de travail dans l'espace de noms du système de fichiers hôte, ou en trompant un utilisateur pour qu'il exécute une image malveillante et permettre à un processus de conteneur d'accéder au système de fichiers hôte via runc run. Les attaques peuvent également être adaptées pour écraser des binaires hôtes semi-arbitraires, permettant des échappements de conteneurs complets. Notez que lors de l'utilisation de runtimes de niveau supérieur (tels que Docker ou Kubernetes), cette vulnérabilité peut être exploitée en exécutant une image de conteneur malveillante sans configuration supplémentaire ou en passant des options workdir spécifiques lors du démarrage d'un conteneur. La vulnérabilité peut également être exploitée à partir de Dockerfiles dans le cas de Docker.

Le problème a été corrigé dans runc v1.1.12.

CVE-2024-23651 (Élevé)

Dans BuildKit <= v0.12.4, deux étapes de construction malveillantes s'exécutant en parallèle partageant les mêmes montages de cache avec des sous-chemins pourraient causer une condition de course, conduisant à des fichiers du système hôte étant accessibles au conteneur de construction. Cela ne se produira que si un utilisateur essaie de construire un Dockerfile d'un projet malveillant.

Le problème a été corrigé dans BuildKit v0.12.5.

CVE-2024-23652 (Élevé)

Dans BuildKit <= v0.12.4, un frontend BuildKit malveillant ou un Dockerfile utilisant RUN --mount pourrait tromper la fonctionnalité qui supprime les fichiers vides créés pour les points de montage en supprimant un fichier à l'extérieur du conteneur du système hôte. Cela ne se produira que si un utilisateur utilise un Dockerfile malveillant.

Le problème a été corrigé dans BuildKit v0.12.5.

CVE-2024-23653 (Élevé)

En plus d'exécuter des conteneurs comme étapes de construction, BuildKit fournit également des API pour exécuter des conteneurs interactifs basés sur des images construites. Dans BuildKit <= v0.12.4, il est possible d'utiliser ces API pour demander à BuildKit d'exécuter un conteneur avec des privilèges élevés. Normalement, l'exécution de tels conteneurs n'est autorisée que si l'autorisation spéciale security.insecure est activée à la fois par la configuration buildkitd et autorisée par l'utilisateur initialisant la demande de construction.

Le problème a été corrigé dans BuildKit v0.12.5.

CVE-2024-23650 (Moyen)

Dans BuildKit <= v0.12.4, un client ou frontend BuildKit malveillant pourrait créer une demande qui pourrait conduire le démon BuildKit à planter avec une panique.

Le problème a été corrigé dans BuildKit v0.12.5.

CVE-2024-24557 (Moyen)

Dans Moby <= v25.0.1 et <= v24.0.8, le système de cache du constructeur classique est sujet à l'empoisonnement du cache si l'image est construite FROM scratch. De plus, les changements à certaines instructions (les plus importantes étant HEALTHCHECK et ONBUILD) ne causeraient pas d'échec de cache. Un attaquant avec la connaissance du Dockerfile que quelqu'un utilise pourrait empoisonner leur cache en leur faisant tirer une image spécialement conçue qui serait considérée comme un candidat de cache valide pour certaines étapes de construction.

Le problème a été corrigé dans Moby >= v25.0.2 et >= v24.0.9.

Comment les produits Docker sont-ils affectés ?

Docker Desktop

Docker Desktop v4.27.0 et antérieures sont affectées. Docker Desktop v4.27.1 a été publié le 1er février et inclut des correctifs pour les binaires runc, BuildKit et dockerd. En plus de mettre à jour vers cette nouvelle version, nous encourageons tous les utilisateurs Docker à utiliser diligemment les images Docker et Dockerfiles et à s'assurer que vous n'utilisez que du contenu de confiance dans vos constructions.

Comme toujours, vous devriez vérifier les exigences système de Docker Desktop pour votre système d'exploitation ( Windows, Linux, Mac) avant la mise à jour pour assurer une compatibilité complète.

Docker Build Cloud

Toute nouvelle instance de constructeur Docker Build Cloud sera provisionnée avec les dernières versions de Docker Engine et BuildKit et sera, par conséquent, non affectée par ces CVE. Des mises à jour ont également été déployées sur les constructeurs Docker Build Cloud existants.

Aucun autre produit Docker n'est affecté par ces vulnérabilités.

Liens d'avis

• Runc
  • CVE-2024-21626
• BuildKit
  • CVE-2024-23650
  • CVE-2024-23651
  • CVE-2024-23652
  • CVE-2024-23653
• Moby
  • CVE-2024-24557

Text4Shell CVE-2022-42889

Dernière mise à jour octobre 2022

CVE-2022-42889 a été découvert dans la bibliothèque populaire Apache Commons Text. Les versions de cette bibliothèque jusqu'à mais n'incluant pas la 1.10.0 sont affectées par cette vulnérabilité.

Nous vous encourageons fortement à mettre à jour vers la dernière version d'Apache Commons Text.

Scanner les images sur Docker Hub

Les analyses de sécurité Docker Hub déclenchées après 1200 UTC le 21 octobre 2021 identifient maintenant correctement le CVE Text4Shell. Les analyses avant cette date ne reflètent pas actuellement le statut de cette vulnérabilité. Par conséquent, nous recommandons que vous déclenchiez des analyses en poussant de nouvelles images vers Docker Hub pour voir le statut du CVE Text4Shell dans le rapport de vulnérabilité. Pour des instructions détaillées, voir Scanner les images sur Docker Hub.

Images Officielles Docker impactées par CVE-2022-42889

Un certain nombre d'Images Officielles Docker contiennent les versions vulnérables d'Apache Commons Text. La liste suivante répertorie les Images Officielles Docker qui peuvent contenir les versions vulnérables d'Apache Commons Text :

• bonita
• Couchbase
• Geonetwork
• neo4j
• sliverpeas
• solr
• xwiki

Nous avons mis à jour Apache Commons Text dans ces images vers la dernière version. Certaines de ces images peuvent ne pas être vulnérables pour d'autres raisons. Nous recommandons que vous examiniez également les directives publiées sur les sites web en amont.

Log4j 2 CVE-2021-44228

Dernière mise à jour décembre 2021

La vulnérabilité Log4j 2 CVE-2021-44228 dans Log4j 2, une bibliothèque de journalisation Java très commune, permet l'exécution de code à distance, souvent à partir d'un contexte qui est facilement disponible pour un attaquant. Par exemple, elle a été trouvée dans les serveurs Minecraft qui permettaient aux commandes d'être tapées dans les journaux de chat car celles-ci étaient ensuite envoyées au logger. Cela en fait une vulnérabilité très sérieuse, car la bibliothèque de journalisation est utilisée si largement et il peut être simple de l'exploiter. De nombreux mainteneurs open source travaillent dur avec des corrections et des mises à jour de l'écosystème logiciel.

Les versions vulnérables de Log4j 2 sont les versions 2.0 à la version 2.14.1 inclusivement. La première version corrigée est la 2.15.0. Nous vous encourageons fortement à mettre à jour vers la dernière version si vous le pouvez. Si vous utilisez une version antérieure à la 2.0, vous n'êtes également pas vulnérable.

Vous pourriez ne pas être vulnérable si vous utilisez ces versions, car votre configuration peut déjà atténuer cela, ou les choses que vous journalisez peuvent ne pas inclure d'entrée utilisateur. Cela peut être difficile à valider cependant sans comprendre tous les chemins de code qui peuvent journaliser en détail, et d'où ils peuvent obtenir des entrées. Donc vous voudrez probablement mettre à niveau tout le code utilisant des versions vulnérables.

CVE-2021-45046

Comme mise à jour de CVE-2021-44228, la correction faite dans la version 2.15.0 était incomplète. Des problèmes supplémentaires ont été identifiés et sont suivis avec CVE-2021-45046 et CVE-2021-45105. Pour une correction plus complète de cette vulnérabilité, nous recommandons que vous mettiez à jour vers la 2.17.0 où possible.

Scanner les images sur Docker Hub

Les analyses de sécurité Docker Hub déclenchées après 1700 UTC le 13 décembre 2021 identifient maintenant correctement les CVE Log4j 2. Les analyses avant cette date ne reflètent pas actuellement le statut de cette vulnérabilité. Par conséquent, nous recommandons que vous déclenchiez des analyses en poussant de nouvelles images vers Docker Hub pour voir le statut du CVE Log4j 2 dans le rapport de vulnérabilité. Pour des instructions détaillées, voir Scanner les images sur Docker Hub.

Images Officielles Docker impactées par le CVE Log4j 2

Dernière mise à jour décembre 2021

Un certain nombre d'Images Officielles Docker contiennent les versions vulnérables du CVE-2021-44228 Log4j 2. Le tableau suivant liste les Images Officielles Docker qui peuvent avoir contenu les versions vulnérables de Log4j 2. Nous avons mis à jour Log4j 2 dans ces images vers la dernière version. Certaines de ces images peuvent ne pas être vulnérables pour d'autres raisons. Nous recommandons que vous examiniez également les directives publiées sur les sites web en amont.

Note

Bien que les images xwiki puissent être détectées comme vulnérables par certains scanners, les auteurs croient que les images ne sont pas vulnérables par le CVE Log4j 2 car les jars API ne contiennent pas la vulnérabilité. L'image Nuxeo est dépréciée et ne sera pas mise à jour.