Confusion de dépendances : quand un paquet public masque un paquet privé

Ce que c'est

Un installateur transforme un nom abstrait (spam) en un fichier concret provenant d'un dépôt donné. La documentation de pip précise que lorsque plusieurs emplacements de paquets sont configurés, aucune priorité n'existe entre eux : tous sont vérifiés et la meilleure correspondance de version est retenue. La PEP 708 décrit la conséquence : chaque dépôt constitue son propre espace de noms, les installateurs les aplatissent en un seul, et lorsqu'un même nom existe dans deux dépôts appartenant à des auteurs différents, une attaque par confusion de dépendances devient possible. Son exemple fondateur est le torchtriton de PyTorch, censé ne provenir que de l'index propre au projet, dont le nom n'était pas revendiqué sur PyPI et qu'une personne malveillante y a publié. La documentation de pip avertit que l'utilisation de --extra-index-url pour des paquets absents du dépôt principal n'est pas sûre, et nomme explicitement cette attaque. La même configuration existe dans d'autres écosystèmes partout où un nom interne peut être enregistré publiquement.

Pourquoi c'est important

L'attaque ne nécessite aucun accès aux systèmes visés : un agent de build, un ordinateur portable de développement ou une tâche d'intégration continue dotée d'une configuration d'index permissive installe le paquet de la personne malveillante, dont les crochets d'installation s'exécutent avec les identifiants de la build. Les noms internes fuient par les manifestes, les messages d'erreur et les dépôts publics, si bien que l'obscurité n'est pas une défense.

Comment l'appliquer

• Lier les espaces de noms aux registres. Dans npm, associer une portée (scope) à un registre (npm config set @myco:registry=https://...) ; la documentation précise qu'une portée pointe vers exactement un seul registre et que les installations et publications pour cette portée y transitent. Ne publier les paquets internes que sous une telle portée.
• En Python, éviter --extra-index-url pour les paquets privés. Utiliser un unique --index-url pointant vers un index privé qui sert de proxy vers l'index public et décide, nom par nom, quel amont est autorisé, de sorte que l'installateur ne voit qu'un seul espace de noms.
• Revendiquer les noms internes sur l'index public avec des paquets d'espace réservé, là où l'écosystème le permet.
• Épingler par empreinte (hash) (pip install --require-hashes, fichiers de verrouillage avec champs d'intégrité) afin qu'un artefact substitué échoue à la vérification.
• Exécuter les builds avec des identifiants minimaux et un réseau sortant restreint, afin qu'un crochet d'installation malveillant ait peu de choses à récupérer.
• Auditer la configuration des installateurs dans les images d'intégration continue et les scripts de configuration des postes de développement ; la ligne dangereuse est généralement celle que quelqu'un a ajoutée pour faire fonctionner l'installation d'un paquet privé.

Pièges

La PEP 708 proposait des métadonnées de dépôt (« tracks » et « alternate locations ») pour que les installateurs puissent détecter automatiquement les mélanges dangereux ; elle a été rejetée après trois ans d'acceptation provisoire, les conditions requises n'ayant jamais été réunies, si bien que les utilisateurs de Python doivent configurer eux-mêmes leur protection. L'ordre des versions n'est pas une défense : la personne malveillante choisit la version supérieure. Les miroirs qui fusionnent les espaces de noms réintroduisent le problème.