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. Hmm das würde bedeuten, ein Paket würde ein gültiges Zertifikat benötigen um es als Original zu kennzeichnen.

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

  5. 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…

Continue the discussion at --> OXID forums

3 more replies

Participants