Docker Hub corrige une faille critique permettant d'agir au nom d'un autre utilisateur : ce que l'on sait et comment réagir.

Une vulnérabilité critique vient d’être corrigée dans Docker Hub. Ce registre public sert à publier et à télécharger des images de conteneurs. Selon le titre de l’annonce, elle sommeillait depuis deux ans. Par ailleurs, elle permettait à un utilisateur d’agir à la place d’un autre. Cependant, Docker affirme n’avoir trouvé aucune trace d’exploitation.

Docker Hub : ce que permettait la faille

Le défaut offrait un pouvoir considérable. Ainsi, un utilisateur pouvait envoyer des images, les récupérer ou les supprimer au nom d’un autre compte. Autrement dit, la frontière entre deux identités n’était plus étanche.

Trois actions étaient donc possibles :

• pousser (push) une image sur le dépôt d’un autre utilisateur ;
• récupérer (pull) des images appartenant à autrui ;
• supprimer des images qui ne lui appartenaient pas.

Ces trois opérations couvrent l’essentiel de la vie d’un dépôt. Par conséquent, l’impact potentiel était élevé, même si aucun abus n’a été constaté.

Une faille cachée dans la conversion de compte

Docker a publié un avis de sécurité le 12 octobre. Il précise l’origine du problème. En effet, la faille se trouvait dans la fonctionnalité qui transforme un compte personnel en organisation.

Cette fonction sert aux utilisateurs dont l’activité grandit. Un compte individuel devient alors un espace partagé, avec plusieurs membres. Or, c’est précisément lors de ce changement de statut que le défaut apparaissait.

Le correctif a été déployé le 30 septembre. Il est donc antérieur de quelques jours à la publication de l’avis. Ainsi, Docker a résolu le problème côté service avant de communiquer publiquement.

Il faut toutefois rester prudent sur les détails. En effet, l’éditeur n’a pas fourni d’identifiant CVE dans les informations disponibles. De plus, les conditions exactes d’exploitation ne sont pas détaillées. Il est donc impossible d’en dire davantage sans extrapoler.

Pourquoi un accès sur Docker Hub est sensible

Un registre de conteneurs est un maillon central de la chaîne logicielle. D’abord, les équipes y téléchargent des images. Ensuite, elles les déploient en production. Ainsi, une image modifiée peut se propager très vite.

Prenons un scénario théorique. Un attaquant pourrait pousser une image sous l’identité d’un éditeur légitime. Il pourrait alors y glisser du code malveillant. Les systèmes qui téléchargent ensuite cette image exécuteraient ce code sans méfiance. C’est donc le principe d’une attaque par la chaîne d’approvisionnement.

La suppression pose un autre risque. Effacer des images peut perturber des déploiements entiers. En outre, la lecture d’images privées pourrait exposer du code propriétaire ou des secrets oubliés dans les couches.

Ces scénarios restent hypothétiques. Docker indique qu’aucune exploitation n’a été détectée. Néanmoins, la durée de vie présumée de la faille, deux ans, invite à rester vigilant. En effet, une absence de preuve ne vaut pas toujours une preuve d’absence.

Ce qu’il faut retenir

Le correctif est appliqué côté service. Les utilisateurs n’ont donc pas de mise à jour à installer. En revanche, quelques vérifications de bon sens s’imposent, surtout pour les comptes convertis en organisation.

• Auditez l’historique de vos dépôts : cherchez des publications, des suppressions ou des téléchargements que vous ne reconnaissez pas.
• Vérifiez les images critiques en production. Comparez leurs empreintes (digests) avec celles de vos builds d’origine.
• Épinglez vos images par digest plutôt que par simple étiquette. En effet, une étiquette peut être réécrite, pas une empreinte.
• Renouvelez les jetons d’accès et revoyez les permissions des membres de vos organisations.
• Signez vos images et contrôlez les signatures avant tout déploiement.
• Surveillez les notifications et les journaux d’activité de votre compte.

Cet épisode rappelle une règle simple. Même un service très répandu peut cacher une faille ancienne. C’est pourquoi la vérification de l’intégrité des images doit rester un réflexe, quelle que soit la confiance accordée au registre.

Enfin, il faudra suivre d’éventuelles précisions de Docker. Un identifiant CVE ou des détails techniques complémentaires pourraient être publiés. Ils permettraient ainsi de mieux mesurer l’étendue réelle du problème.

Source : Docker Fixes Critical Two-Year-Old Hub Flaw That Let One User Push Images as Another