Originally published at: Security Advisory: Prevent Dependency Confusion with Composer
Recently, packagist.org warned about possible attacks in their blog. We want to escalate this warning to OXID module vendors.
Ganz ehrlich, das ist ein Composer Problem, und dort sollte es auch gelöst werden. Sich die vendor ids auf x Quellen vorsorglich zu sichern kann ja nicht die Lösung sein.
Warum versucht Composer Daten von einer Quelle zu holen wenn eine lokale Installationsvariante präferiert wird? Dieses Problem sollte es schlicht nicht geben!
in composer v2 gibt es auch eine Lösung für eine fixe Paketquelle.
Nur geht das Thema etwas weiter: Die valide Quelle kann auch von einem x beliebigen GIT Server kommen, der öffentlich verfügbar ist. Kann nun composer darauf nicht zugreifen (timeout, abgelaufene credentials etc.) gibt es den fallback auf github. Also auch nicht x Quellen, sondern genau diese Quelle.
Und selbst wenn die Originalquelle in Form des o.g. GIT-Servern verfügbar ist: Wenn der Angreifer mit einem eigenen Github Account eine höhere Versionsnummer ausliefert, wird composer diese präferieren.
Dieser Ablauf entspricht dem Grundgedanken einer Paketmanagers: Pakete können verteilt im Netz verfügbar sein und nicht jede Quelle wird immer auf dem aktuellsten Stand sein. Somit gewinnt die Quelle die (scheinbar) die aktuellste Version ausliefert.
1 Like
Hmm das würde bedeuten, ein Paket würde ein gültiges Zertifikat benötigen um es als Original zu kennzeichnen.
Manchmal holt man sich für Developer Bequemlichkeit halt die Pest ins Haus…
Diese Aussage kann ich nicht nachvollziehen. Composer hat aus meiner Sicht den Aufwand erhöht und zu keiner Art von Bequemlichkeit geführt. Könntest Du dies bitte näher ausführen? Würde es gerne verstehen.
Für das Versionshandling von Modulen bringt Composer aus meiner Sicht durchaus Vorteile.
Wobei natürlich der obige Punkt einer der Nachteile ist. Deshalb wichtig, Modulupdates bzw. Composer Updates vorab zu prüfen was man sich dort lädt…
Mit Composer v2 wird die Quelle canonical gesetzt. D.h., es wird für jedes Paketupdate nur noch die Quelle verwendet, die zur Installation verwendet wurde. Damit sollte diese Injection-Gefahr deutlich gemildert sein.
In v1 gibt es aber eben diesen Fallback auf packagist.org. Den kann man zwar in der composer.json deaktivieren (Repositories - Composer). Der ist aber spätestens dann unhandlich, wenn man Packages nur dort findet. Im OXID-Umfeld würde das heißen, geschätzt 30 weitere Quellen manuell angeben zu müssen. Der arme Praktikant.
Somit gibt es zwar eine mögliche Schwachstelle, die aber eindeutig adressiert, einfach zu fixen und zukünftig eigentlich nicht mehr vorhanden ist. That’s life.
1 Like
aber ist es dann wirklich endgültig gefixt?
Man müsste seinen Vendor eigentlich global reservieren können und nicht pro Package Repository.
Sonst könnte Firma X, deren Packagist in vielen Shops hinterlegt ist, bei sich ein “oxid-esales/paypal-module” Package mit einer höheren Version als original oxid-esales/paypal-module anlegen und schon haben wir das Problem wieder.
Es muss jetzt auch nicht die Firma X selbst diese böse Absicht haben, es könnte auch ein Hacker sein, der die Packagist Installation der Firma X dafür missbraucht.
