Un problème vieux de 10 ans impliquant Docker Engine et le plug-in d’autorisation AuthZ réapparaît pour permettre aux attaquants d’obtenir un accès au niveau racine aux systèmes hôtes.
Les chercheurs mettent en garde contre une nouvelle vulnérabilité qui permet aux attaquants de contourner les plug-ins d’autorisation dans Docker Engine et d’obtenir un accès au niveau racine aux systèmes hôtes. La faille a la même cause profonde qu’une autre vulnérabilité de contournement d’autorisation corrigée en 2024, mais le problème sous-jacent est connu depuis 2016.
Suivie comme CVE-2026-34040, la nouvelle vulnérabilité est notée 8,8 (élevé) sur l’échelle CVSS et a été corrigée dans Docker Engine 29.3.1 et Docker Desktop 4.66.1. Si les mises à jour ne peuvent pas être déployées immédiatement, les requêtes malveillantes peuvent éventuellement être filtrées en limitant la taille des requêtes à 512 Ko.
« L’API Docker est accessible via le réseau (TCP/TLS) dans la plupart des déploiements d’entreprise, des systèmes CI/CD et des plateformes de gestion », ont déclaré des chercheurs de la société de sécurité Cyera dans un rapport. « Il s’agit d’une requête HTTP unique sans conditions de concurrence ni dépendance temporelle. Si un attaquant (ou un agent IA) a un accès à l’API Docker restreint par un plugin AuthZ, il peut le contourner. «
L’écart AuthZ vieux de 10 ans
Le moteur Docker ne dispose pas d’autorisation basée sur les rôles par défaut, ce qui signifie que tout utilisateur pouvant accéder à l’API Docker peut exécuter toutes les commandes Docker. Pour appliquer des contrôles plus granulaires, les entreprises s’appuient sur divers plug-ins Docker AuthZ tiers et personnalisés, une fonctionnalité qui existe dans Docker Engine depuis 2016.
En 2018, les chercheurs ont réalisé que les attaquants pouvaient contourner toutes les restrictions imposées par les plug-ins AuthZ en envoyant des requêtes avec Content-Length défini sur 0 au démon Docker, qui les transmettrait ensuite aux plugins AuthZ en supprimant les corps des requêtes. Les plug-ins approuveraient automatiquement ces requêtes en pensant qu’elles ne contenaient aucune commande, mais le Docker Engine exécuterait alors les commandes dans le corps de la requête qui avait été supprimé.
Le problème a été résolu dans Docker Engine v18.09.1 publié en janvier 2019, mais le correctif n’a pas été inclus dans les versions ultérieures de Docker Engine à partir de 19.03, provoquant une régression et une nouvelle vulnérabilité suivie comme CVE-2024-41110. La faille a finalement été corrigée en juillet 2024 dans les versions 23.0.14, 26.1.4 et 27.1.0.
Personne n’a vérifié les demandes surdimensionnées
Alors que le contournement d’autorisation précédent était déclenché lorsque la requête Content-Length était définie sur 0, personne ne vérifiait à l’époque ce qui se passerait dans la même fonction si la requête dépassait une certaine taille.
« Lorsque le corps d’une requête API dépasse 1 Mo, le middleware de Docker supprime silencieusement le corps avant que votre plugin d’autorisation ne le voie », ont découvert les chercheurs de Cyera. « Le plugin, ne voyant rien à inspecter, approuve la demande. Le démon Docker traite ensuite le corps complet et crée le conteneur demandé, accordant potentiellement un accès complet au système de fichiers hôte. »
Il s’agit essentiellement de la même classe de bogues avec la même cause première, mais en utilisant un remplissage de requête de 1 Mo au lieu d’une longueur nulle. Étant donné que le plug-in AuthZ ne peut pas inspecter et bloquer la demande, cela signifie que les attaquants auraient accès à toutes les commandes du Docker Engine, y compris la possibilité de créer des conteneurs privilégiés avec un accès root.
Habituellement, les vulnérabilités Docker les plus graves sont celles qui permettent aux attaquants de s’échapper de l’intérieur des conteneurs, mais cette faille se produit avant même la création du conteneur, de sorte qu’aucun outil de surveillance intégré au conteneur ne détectera la tentative d’exploitation. Les administrateurs peuvent toutefois acheminer les requêtes API via un proxy inverse qui bloque par exemple toutes les requêtes de plus de 512 Ko, à titre d’atténuation temporaire.
Les interfaces API Docker exposées sont constamment ciblées par les botnets et les attaquants pour détourner les instances et les serveurs cloud, d’autant plus que Docker est utilisé dans plus de 90 % des environnements d’entreprise dans le monde.
Les chercheurs de Cyera recommandent de rechercher dans les journaux des démons des signes d’exploitation potentielle en utilisant journalctl -u docker | grep “Request body is larger than”. Ils conseillent également d’examiner quels systèmes automatisés ont accès à l’API Docker et de donner la priorité aux hôtes ayant accès aux informations d’identification de production ou aux données réglementées pour une application immédiate des correctifs.
