Dependency Confusion: wenn ein öffentliches Paket ein privates verdrängt

Worum es geht

Ein Installer macht aus einem abstrakten Namen (spam) eine konkrete Datei aus irgendeinem Repository. Die pip-Dokumentation hält fest, dass bei mehreren konfigurierten Paketquellen keine Priorität zwischen ihnen besteht: Alle werden geprüft, und die beste Versionsübereinstimmung wird ausgewählt. PEP 708 beschreibt die Folge: Jedes Repository ist sein eigener Namensraum, Installer flachen sie zu einem einzigen ab, und existiert derselbe Name in zwei Repositories unterschiedlicher Autoren, wird ein Dependency-Confusion-Angriff möglich. Das motivierende Beispiel ist PyTorchs torchtriton, das nur vom eigenen Index des Projekts stammen sollte, dessen Name auf PyPI aber unbeansprucht war und dort von einem Angreifer veröffentlicht wurde. Die pip-Dokumentation warnt, dass die Verwendung von --extra-index-url für Pakete, die nicht im Hauptrepository liegen, unsicher ist, und benennt den Angriff. Dieselbe Form existiert in anderen Ökosystemen überall dort, wo sich ein interner Name öffentlich registrieren lässt.

Warum es wichtig ist

Der Angriff braucht keinen Zugriff auf die eigenen Systeme: Ein Build-Agent, ein Entwicklerlaptop oder ein CI-Job mit einer nachlässigen Indexkonfiguration installiert das Paket des Angreifers, dessen Installations-Hooks mit den Zugangsdaten des Builds laufen. Interne Namen sickern über Manifeste, Fehlermeldungen und öffentliche Repositories nach aussen, Verschleierung ist also kein Schutz.

So wird es angewendet

• Namensräume an Registries binden. In npm einen Scope mit einer Registry verknüpfen (npm config set @myco:registry=https://...); die Dokumentation hält fest, dass ein Scope auf genau eine Registry zeigt und Installationen wie Veröffentlichungen für diesen Scope dorthin gehen. Interne Pakete nur unter einem solchen Scope veröffentlichen.
• In Python --extra-index-url für private Pakete vermeiden. Einen einzelnen --index-url verwenden, der auf einen privaten Index zeigt, der den öffentlichen proxyiert und pro Name entscheidet, welches Upstream erlaubt ist, sodass der Installer nur einen Namensraum sieht.
• Interne Namen dort, wo das Ökosystem es erlaubt, mit Platzhalterpaketen auf dem öffentlichen Index beanspruchen.
• Mit Hashes pinnen (pip install --require-hashes, Lockfiles mit Integritätsfeldern), damit ein ausgetauschtes Artefakt die Prüfung nicht besteht.
• Builds mit minimalen Zugangsdaten und eingeschränktem ausgehendem Netzwerk laufen lassen, damit ein bösartiger Installations-Hook wenig mitnehmen kann.
• Installer-Konfigurationen in CI-Images und Entwickler-Setup-Skripten prüfen; die gefährliche Zeile ist meist eine, die jemand hinzugefügt hat, damit ein privates Paket installiert.

Stolpersteine

PEP 708 schlug Repository-Metadaten («tracks» und «alternate locations») vor, damit Installer unsichere Mischungen automatisch erkennen könnten; es wurde nach drei Jahren im provisorischen Status abgelehnt, weil die nötigen Voraussetzungen nie erfüllt wurden, sodass Python-Nutzer den Schutz selbst konfigurieren müssen. Versionsreihenfolge ist kein Schutz: Der Angreifer wählt die höhere Version. Mirrors, die Namensräume zusammenführen, bringen das Problem zurück.