Schatten der Vergangenheit

PEAR?

Im Jahr 1999, einige Monate vor der Veröffentlichung von PHP 4, begann Stig Sæther Bakken mit der Arbeit an PEAR, dem „PHP Extension and Abstraction Repository“, das später in „PHP Extension und Application Repository“ umbenannt wurde. PEAR sollte das „CPAN für PHP“ werden. CPAN ist das „Comprehensive Perl Archive Network“, ein Archiv von Softwarepaketen, die in der Programmiersprache Perl geschrieben sind.

Anfangs bezeichnete PEAR nur das Repository von PHP-Softwarepaketen, das unter pear.php.net gehostet war. Diese Pakete wurden damals noch mit der Versionskontrolle CVS auf cvs.php.net entwickelt. Aber PEAR war noch mehr als einige Softwarepakete, die auf der Infrastruktur des PHP-Projekts entwickelt und zusammen mit PHP distribuiert wurden. Zum einen wurden verschiedene Regeln festgelegt. Beispielsweise war keine Duplikation erlaubt. Das bedeutet, dass ein Paket nicht akzeptiert wurde, wenn es in PEAR bereits ein Paket gab, welches das gleiche Problem löste. Es gab jeweils eine Abstimmung, bevor neue Pakete in PEAR akzeptiert wurden. Einige bekannte PEAR-Pakete sind beispielsweise MDB2 und HTML_QuickForm. Die Entwicklung einiger bekannter Entwicklungswerkzeuge für PHP wie beispielweise PHPUnit, PHP_CodeSniffer oder phpDocumentor begann als PEAR-Paket.

PEAR entstand zu Zeiten von PHP 4. Damals unterstüzte PHP noch nicht wirklich die objektorientierte Programmierung. Das PEAR-Paket entstand daher primär, um Beschränkungen der Sprache zu umgehen und enthielt beispielsweise eine Emulation von Exceptions und Destruktoren. Die Verwendung dieser Emulationen wurde von allen PEAR-Paketen verlangt, daher waren alle PEAR-Pakete von diesem einen Kernpaket abhängig. Da jede Software, die ein PEAR-Paket nutze, eventuelle Fehler angemessen behandeln musste, hatte sie damit Kenntnis von bestimmten Implementierungsdetails der Exception-Emulation. Somit war PEAR viel mehr als nur eine Sammlung von Paketen: Es war eine Umgebung, derer sich eine Applikation bewusst sein musste.

Jahre später brauchte Greg Beaver eine Lösung zur Verteilung und Installation von phpDocumentor und begann daher mit der Entwickler des PEAR-Installers. Dieses Kommandozeilenwerkzeug konnte automatisch PEAR-Pakete herunterladen, installieren und aktualisieren. Seitdem bezog sich die Bezeichnung PEAR nicht mehr nur auf das Repository von PHP-Softwarepaketen, die auf pear.php.net gehostet waren, sondern auch auf den PEAR Installer, der an der Kommandzeile mit pear aufgerufen wurde und als Paketmanager die Schnittstelle zum Repository bildete. Pakete wurden jeweils global in einem Verzeichnis installiert, das Bestandteil des include_path von PHP sein musste. Dieser Ansatz hat verschiedene Nachteile gegenüber einer lokalen Installation von Abhängigkeiten direkt im Projekt. Beispielsweise mussten alle Projekte auf einem Entwicklungs- oder Produktivsystem jeweils die gleiche PEAR-Paketversion nutzen; es war und ist bei einer zentralen Installation nicht möglich, unterschiedliche Versionen nebeneinander zu benutzen.

In der Folge wurde der PEAR Installer so erweitert, dass er neben pear.php.net auch alternative Repositories für Pakete, die sogenannte Kanäle, unterstütze. So wurde es möglich, dass Entwickler ihre Software unter Benutzung des etablierten PEAR Installers verteilen konnten, aber dennoch nicht den Regeln des PEAR-Projektes folgen mussten. Anfangs legte allerdings kaum jemand einen eigenen Channel-Server an, da der Installationsprozess dafür ziemlich aufwändig war. Erst als Fabien Potencier Pirum veröffentlichte, ein alternatives Werkzeug, um einen solchen Server aufzusetzen, setzen sich die eigenen Channel-Server nach und nach durch.

Im Jahr 2001 suchte Nils Adermann nach einer Lösung, die Forensoftware phpBB zusammen mit Plugins zu installieren. Gemeinsam mit Jordi Boggiano begann er die Arbeit an Composer, einem Dependency Manager, der auf Projektebene arbeitet. Um 2014 herum dachten die Entwickler verschiedener populärer PEAR-Pakete zumindest darüber nach, die Distribution ihrer Software als PEAR-Pakete einzustellen. PEAR 2, das Projekt „Pyrus“, war ein Versuch, den Kern von PEAR für PHP 5.3 neu zu schreiben. Dieses Projekt war allerdings nicht erfolgreich. Wir können zwar nur spekulieren, aber sind uns ziemlich sicher, dass der Erfolg von Composer einer der Hauptgründe für das Scheitern war.

Dennoch war PEAR eine wesentliche treibende Kraft für die Professionalisierung von PHP, da es einen standardisierten Weg bot, Abhängigkeiten zu installieren und zu aktualisieren. Dafür schuldet die PHP-Community dem PEAR-Projekt eine Menge Respekt und Dankbarkeit.

Das Problem mit go-pear.phar

Warum schreiben wir nun in 2019 über PEAR? Weil etwas ziemlich Übles passiert ist:

Was ist geschehen?

Es gab einen Einbruch in den Server pear.php.net . Dabei wurde die Datei go-pear.phar , die auf https://pear.php.net/go-pear.phar gehostet war, durch eine veränderte Version ersetzt. Diese enthält Malware, welche beim Aufruf mittels Perl eine Reverse Shell öffnet. Dieser Einbruch ereignete sich irgendwann zwischen dem 20. Dezember 2018, an diesem Tag wurde die Datei zuletzt durch einen Maintainer aktualisiert, und dem 18. Januar 2019. Zu diesem Zeitpunkt wurden die PEAR-Maintainer von der Malware in Kenntnis gesetzt. Das Vorhandensein der Malware wurde verifziert und der Zwischenfall am 19. Januar 2019 durch die PEAR-Maintainer öffentlich gemacht.

Es ist wichtig darauf hinzuweisen, dass go-pear.phar nicht der PEAR-Installer selbst ist, sondern eine kleine PHP-Anwendung, die als PHP Archive (PHAR) distribuiert wird, und eine PEAR-Umgebung inklusive PEAR-Installer installiert. Das bedeutet, dass das Sicherheitsproblem alle Systeme betrifft, die zwischen dem 20. Dezember 2018 und dem 19. Januar 2019 https://pear.php.net/go-pear.phar verwendet haben, um eine neue PEAR-Umgebung aufzusetzen.

Bin ich betroffen?

Wer kein PEAR benutzt, wer PEAR über den Paketmanager des Betriebssystems oder PEAR manuell ohne go-pear.phar installiert hat, und wer kein go-pear.phar benutzt hat, das zwischen 20. Dezember 2018 und 19. Januar 2019 heruntergeladen wurde, ist nicht betroffen.

Wer im angegebenen Zeitraum go-pear.phar heruntergeladen und auf einem System ausgeführt hat, auf dem die Kommandos sh und perl verfügbar sind, muss sein System als kompromitiert betrachten und entsprechende Maßnahmen einleiten.

Falls unbekannt ist, ob im Unternehmen Automation existiert, beispielsweise als Teil der kontinuierlichen Integration oder eines Deployment-Prozesses, die ein frisch heruntergeladenes go-pear.phar verwendet, um eine saubere PEAR-Umgebung aufzusetzen, dann könnte es ein Problem geben. In diesem Fall kann man beispielsweise den Netzwerkverkehr nach Abrufen von pear.php.net durchsuchen, um solche Jobs zu finden.

Wer in seiner PHP-Umgebung überhaupt kein PEAR verwendet, der ist natürlich sicher.

Warum wurde PEAR angegriffen?

Programme, die Software installieren, dazu gehört ein Programm wie go-pear.phar , das Software installiert, die Software installiert, sind lohnende Ziele für Angriffe wie oben beschrieben. Anstelle mehrere Systeme angreifen zu müssen, muss man nur ein einziges System erfolgreich knacken, in diesem Fall pear.php.net , dort den Installer, in diesem Fall go-pear.phar , durch eine Version mit Malware ersetzen und kann direkt die vorhandene Infrastruktur zur Distrubtion von Software nutzen, um den Effekt des Angriffs zu multiplizieren. Am Ende hat man Kontrolle nicht nur über ein einzelnes System, sondern über jedes System, auf dem der veränderte Installer benutzt wurde.

Ein Angriff wie der auf go-pear.phar ist so nicht zum ersten Mal – und vermutlich auch nicht zum letzten Mal – passiert. In der Vergangenheit wurden Debian , Python oder JavaScript , um nur einige zu nennen, ebenfalls Opfer solcher Angriffe.

Hätte man den Angriff verhindern können?

Das grundlegende Problem ist, dass Benutzer durch Dokumentation dazu aufgefordert werden, durch Copy-and-paste Kommandos wie

direkt in ihrer Shell auszuführen. Das verhindert jegliche Verifikation von Authentizität oder Integrität der heruntergeladenen ausführbaren Datei, bevor sie ausgeführt wird. Benutzer, die so etwas tun, laden dazu sein, dass ihr System kompromittiert wird!

In der PEAR-Dokumentation wurde der Benutzer aufgefordert,

auszuführen. Das ist genauso schlimm, denn auch hier unterbleibt die Verifikation.

Hätte nun ein Benutzer die Datei vor der Ausführung verifizieren wollen, dann wäre er daran gescheitert, denn das PEAR-Projekt hat keine kryptographischen Signaturen publiziert. Das entspricht definitiv nicht heutigen Sicherheitsstandards.

Wenn man sich den PEAR Installer ansieht, dann fällt auf, dass sich das PEAR-Projekt zumindest prinzipiell dem Problem bewusst war: Das Kommando pear sign kann verwendet werden, um ein PEAR-Paket vor der Distribution mit einem GPG-Schlüssel zu unterschreiben. Soweit uns bekannt ist, hätte allerdings der PEAR Installer eine solche Signatur vor der Installation nicht überprüft.

Angriffe auf Computersysteme können nicht verhindert werden. Man kann lediglich Maßnahmen ergreifen, die Angriffe erschweren und daher weniger attraktiv machen. Was allerdings verhindert werden kann, ist, dass zwischen einem Angriff und den Gegenmaßnahmen eine längere Zeitspanne vergeht. Es genügt nicht, Intrusion Detection-Systeme und Monitoring zu haben, diese Systeme müssen, genauso wie ein Server selbst, laufend gewartet werden. Und falls eine Anomalie entdeckt wird, muss jemand darauf reagieren. Das bedeutet natürlich, dass Menschen Zeit aufwenden müssen. Gerade in Open Source-Projekten, bei denen die ganze Arbeit von Freiwilligen geleistet wird, ist dies oft ein Problem.

Warum ist pear.php.net noch immer offline?

Heute benutzen deutlich weniger Entwickler und Projekte PEAR-Pakete und den PEAR Installer als vor fünf Jahren, als Composer deutlich an Popularität gewann. Dieser Rückgang in den Nutzerzahlen des PEAR Installers und der pear.php.net -Infrastruktur motiviert natürlich immer weniger Freiwillige dazu, PEAR am Leben zu erhalten.

Als der Fund der go-pear.phar -Malware am 19. Januar 2019 verfiziert worden war, entschlossen sich die verbleibenden PEAR-Maintainer, pear.php.net offline zu nehmen. Zum Zeitpunkt, da dieser Text geschrieben wird, sind die Maintainer noch immer dabei, den Server neu aufzusetzen. Es gibt allerdings noch nicht einmal eine Schätzung, wann (oder möglicherweise: ob jemals) die PEAR-Infrastruktur wieder online sein wird. Das erinnert ein wenig an 2015, als der Server wegen defekter Festplatte offline war und es eine Weile dauerte, ihn wieder zum Laufen zu bekommen.

Übrigens: eine unerwartete Nebenwirkung des Ausfalls von pear.php.net ist die Tatsache, dass zum Zeitpunkt, als dieser Text geschrieben wurde, TravisCI ihre nächtlichen Builds von PHP 7.4 nicht mehr aktualisieren konnte, da das Buildskript versuchte, go-pear.phar herunterzuladen.

Ist PEAR noch relevant?

Ein Großteil der PEAR-Community ist längst weitergezogen und benutzt heute weder den PEAR-Installer noch irgendwelche PEAR-Pakete.

Ein Beispiel dafür ist pear.phpunit.de . Der Server, der vor langer Zeit die PHPUnit-Pakete distribuierte, ist bereits vor vier Jahren abgeschaltet worden. Dennoch werden von PEAR Installer-Clients noch heute stündlich Dutzende Requests an pear.phpunit.de gesendet. Ein Monat, bevor pear.phpunit.de abgeschaltet wurde, wurden PHPUnit 3.7.36 und PHPUnit 4.0.18 als PEAR-Pakete veröffentlicht. Diese Pakete waren jedoch keine funktionierenden Versionen von PHPUnit, sondern lediglich ein Skript, das eine Fehlermeldung ausgab. Man muss sich fragen, wie viele PEAR Installer-Clients da draußen „Zombies“ sind, die vor sich hin arbeiten, ohne dass überhaupt noch jemand davon weiß.

Obwohl die meisten PEAR-Pakete niemals für PHP 5, geschweige denn für PHP 7 aktualisiert wurden, werden aktuelle PHP-Releases noch immer mit PEAR ausgeliefert, und man muss bei der Übersetzung den Schalter --without-pear benutzen, um zu verhindern, dass eine PEAR-Umgebung mit installiert wird. Das könnte man so auslegen, als ob das PHP-Projekt PEAR als seinen offiziellen Paketmanager ansieht – das ist aber nicht der Fall.

Der einzige Grund, warum PHP noch immer standardmäßig PEAR installiert, ist, weil der PECL-Installer, den man mit pecl an der Kommandozeile aufruft, PEAR benötigt. Mit dem PECL-Installer kann man automatisch in C oder C++ geschriebene PHP-Erweiterungen von pecl.php.net im Quellcode herunterladen, übersetzen und installieren. Während Composer den PEAR-Installer ganz klar obsolet gemacht hat, scheint der PECL-Installer noch immer relevant zu sein, beispielsweise in Dockerfiles oder als Teil der PHP-Unterstützung in Homebrew auf macOS.

Fazit

Es gibt hier einige Lektionen zu lernen, und manche davon gelten auch für kommerzielle Softwareprojekte. Bruce Schneier hat einmal geschrieben: „Security ist ein Prozess, kein Produkt“. Diese Aussage ist sogar nicht nur auf Security beschränkt: Man muss damit aufhören, das Upgrade des PHP-Stacks als ein besonderes Projekt zu sehen, sondern dies zu einem Teil der normalen Operations machen.

Es gibt viel Software, die seit Jahren nicht mehr verändert wurde, und es ist wahrlich nicht ungewöhnlich, wenn Firmen gar nicht so genau wissen, welche Applikationen auf ihrer Infrastruktur eigentlich (noch) laufen. Anwendungen wurden irgendwann installiert, möglicherweise weil sie als schlüsselfertige Lösung von extern eingekauft worden waren, und wurden dann vergessen. Solche Applikationen werden nicht überwacht und niemand fühlt sich für sie verantwortlich. Möglicherweise sind die Server, auf denen diese Anwendungen laufen, schon vor Jahren Opfer eines Angriffs geworden, wie er hier beschrieben wurde! Dies zuzulassen ist unverantwortlich, und zwar nicht erst seit Einführung der DSGVO.

Es wäre kurzsichtig, die Schuld für den stattgefundenen Angriff allein dem PEAR-Projekt zuzuschieben. Zweifellos hätten die Maintainer Signaturen erstellen sollen, um die Verifikation von go-pear.phar zu ermöglichen. Vermutlich haben sie auch nicht genug auf die Server von pear.php.net geachtet, ansonsten hätten sie vielleicht schon früher festgestellt, dass diese kompromittiert worden waren. Dennoch ist jeder Benutzer, der eine Datei aus dem Internet herunterlädt und ohne weitere Prüfungen direkt ausführt, genauso verantwortlich.

Wenn das PEAR-Projekt nicht genügend Arbeitskräfte hat, um einen sicheren Betrieb von pear.php.net und der dazugehörigen Infrastruktur sicherzustellen, dann sollte man dies vielleicht akzeptieren und darüber nachdenken, ob und wie man das PEAR-Projekt beenden kann.