DockerDash : lorsque les métadonnées Docker deviennent des instructions exécutables et que l'IV est exposée à l'injection de Meta-Context

Une vulnérabilité grave qui a affecté Ask Gordon, l'assistant de l'intelligence artificielle intégré dans Docker Desktop et le CLI de Docker. Les enquêteurs de sécurité ont qualifié l'échec de Coq Dash et a montré qu'avec une technique relativement simple, un attaquant pouvait convertir des métadonnées apparemment inoffensives en instructions exécutables qui finissaient par fonctionner dans l'environnement de la victime ou par extraire des informations sensibles.

L'échec a été décrit et analysé par l'équipe Noma Labs dans un rapport technique qui documente comment une étiquette malveillante dans les métadonnées d'une image Docker (par exemple, un champ LABEL dans le fichier Docker) peut être répartie à travers les couches de la pile jusqu'à ce qu'elle provoque une exécution de code ou une fuite de données. Docker a publié une correction incluse dans la version 4,50,0, ainsi la mise à jour de cette version ou plus est la première mesure que les gestionnaires et les développeurs devraient prendre.

La racine du problème n'était pas un échec traditionnel, mais un problème de confiance contextuelle entre l'assistant IA et les éléments qu'il expliquait. Demandez à Gordon de lire les métadonnées des images pour fournir des explications, des suggestions et des commandes. Dans le cas de DockerDash, ces métadonnées n'étaient pas traitées comme des données de catalogue mais comme des instructions que l'assistant pouvait déléguer à une couche intermédiaire appelée MCP Gateway (Modèle Context Protocol), qui sert de pont entre le modèle linguistique et les outils locaux. En l'absence d'une vérification rigoureuse des métadonnées simplement informatives et susceptibles d'être exécutées, un acteur malveillant pourrait insérer des "instructions" dans un LABEL et les faire exécuter plus tard.

L'attaque décrite par les chercheurs se déroule dans une chaîne: d'abord, un attaquant construit et publie une image Docker avec des champs LABEL modifiés pour inclure des instructions nuisibles; ensuite, lorsqu'un utilisateur consulte Ask Gordon sur cette image, l'assistant traite et renvoy le contenu à la passerelle MCP comme s'il s'agissait d'une requête légitime; enfin, la passerelle invoque des outils MCP qui exécutent les actions avec les privilèges de l'environnement Docker de l'utilisateur. Le résultat peut être de l'exécution à distance de commandes dans des environnements cloud ou CLI à l'extraction d'informations internes dans des installations de bureau.

En plus de la possibilité d'exécution, les chercheurs ont montré comment le même itinéraire pouvait être utilisé pour recueillir des détails sensibles de l'environnement: listes de conteneurs et configurations, itinéraires montés, outils installés et topologie réseau. Dans les environnements Docker Desktop, où Ask Gordon travaille avec des permissions de lecture uniquement théoriques, ces consultations peuvent révéler beaucoup de données utiles pour un attaquant dans les phases ultérieures de l'attaque.

Les auteurs de la conclusion ont inventé le terme Injection de métacontexte décrire ce genre d'abus : un bug classique n'est pas exploité en mémoire ou en débordement, mais la capacité d'insérer un contexte malveillant que le système interprète comme faisant partie de son raisonnement opérationnel. C'est une variante moderne des injections de commandes, adaptée aux architectures qui combinent des modèles de langage et des outils externes.

Docker et les responsables du protocole MCP ont déjà publié des corrections et des recommandations, mais au-delà du patch immédiat, l'incident laisse des leçons pertinentes. La première est que les entrées provenant de sources « fiables » - par exemple, les dépôts d'images ou les champs de métadonnées - doivent être traitées avec le même scepticisme que toute entrée utilisateur inconnue. La mise en oeuvre de validations strictes, de politiques minimales de permis et de contrôles de l'intégrité des métadonnées est essentielle.

Un autre enseignement est l'architecture : les ponts entre les modèles IA et les ressources locales (comme la passerelle MCP) nécessitent des mécanismes d'authentification et d'autorisation plus fins. Dans ce cas, l'absence de distinction entre les données d'information et les ordres exécutables a permis à la chaîne de traitement d'accepter et de diffuser des instructions malveillantes sans chaînes de sécurité supplémentaires. Limiter les outils qui peuvent être invoqués, exiger des confirmations explicites de l'utilisateur pour les actions sensibles et invocation d'audit sont des mesures qui réduisent la surface de l'attaque.

Si vous voulez entrer dans l'analyse technique, vous pouvez lire le rapport Noma Labs, qui détaille les itinéraires d'exploitation et les vecteurs de risque: Rapport DockerDash - Noma Labs. Il est également recommandé d'examiner la documentation de Docker sur Ask Gordon et les notes de la version qui corrigent le problème: Demandez à Gordon - Docker et Notes concernant la version 4.50.0. Afin de mieux comprendre les risques globaux d'injection pour les participants à l'IV, OWASP maintient des ressources utiles sur ce type d'attaque : OWASP - Feuille de chaleur injectable rapide.

Dans la pratique, avant d'utiliser une image ou des réponses automatisées, il convient d'appliquer plusieurs défenses : vérifier l'origine des images et préférer les signatures et le canal sûr, analyser les artefacts pour obtenir du contenu inhabituel dans les métadonnées, minimiser les privilèges d'exécution des outils MCP et exiger des contrôles supplémentaires lorsqu'une action implique des changements ou un accès à des données sensibles. Ces mesures n'éliminent pas complètement le risque, mais augmentent considérablement le coût pour un attaquant.

L'épisode de DockerDash présente également un risque émergent : celui de la chaîne d'approvisionnement de l'IA. Lorsque les modèles et les participants commencent à automatiser les décisions et à invoquer des capacités locales, les entrées apparemment bénignes deviennent vecteurs d'attaque si elles ne sont pas validées correctement. Traiter l'information contextuelle comme « confiante » sans validation est un raccourci dangereux nous devons éviter si nous voulons déployer des assistants IA dans des environnements productifs avec sécurité.

Si vous gérez les environnements Docker, la recommandation pratique et urgente est simple : elle met à jour la version parachevée et passe en revue les paramètres de Ask Gordon et MCP. À moyen terme, il propose des contrôles de confiance zéro (fiducie zéro) pour toutes les données qui alimentent les agents d'IV et élabore des politiques qui limitent la capacité de ces agents à mettre en œuvre automatiquement des actions. La technologie évolue rapidement et ces leçons nous aident à la maintenir utile sans compromettre l'infrastructure ou les données.