Security Advisory: Preventing Dependency Confusion in PHP with Composer

Recently, Nils Adermann from Packagist team, published the article Preventing Dependency Confusion in PHP with Composer in their blog. First off: OXID eShop itself, with the standard installation, is apparently not affected by this vulnerability; rather this is a (strong) security advisory to all of thee module vendors who still use the archaic way of distributing their modules as zip archives or do not use the packagist system at all.

As you all might know, at least since OXID eShop v6.2.x, it is mandatory to install modules via composer. However, there are two different options possible, either automatic or manual installation as described here: https://docs.oxid-esales.com/developer/en/6.2/development/modules_components_themes/module/installation_setup/installation.html. Even if a manual installation is necessary (depending by vendor), composer will look up packagist if there is a newer version of the module available and might use this one.

Resolution

There is just a little thing to do for you as a module vendor (completely independent from OXID): get yourself a packagist account and save your vendorID before anybody else can do that in your name. Additionally, register your first module with packagist, which could only contain the required composer.json file and else be empty. We strongly urge you to do that today as you are responsible for the safety of your clients and their customers.

Thanks to Daniel at D³ Data Development for letting us know about the gravity of this security risk!



Replies

  1. 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!

  2. 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.

  3. Manchmal holt man sich für Developer Bequemlichkeit halt die Pest ins Haus…

  4. 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.

  5. Meiner Ansicht nach wird der vendor bei Packagist schon reserviert, niemand ausser dem “Ersten” kann dann noch Pakete mit dem betreffenden vendor in der composer.json anlegen.

Continue the discussion at --> OXID forums

3 more replies

Participants