PHP2Shell: Kursierender Workaround schützt nicht — PHP-Fix für zwei 9.2-Lücken kommt um 14:00 UTC

Bis zum Erscheinen des Fixes senken laut den vorliegenden Empfehlungen vor allem drei Dinge das Risiko: exponierte PHP-Systeme aus dem Internet zu nehmen oder hinter Zugangskontrollen zu stellen, die Reichweite eines kompromittierten Servers zu beschneiden und das Update so vorzubereiten, dass es unmittelbar nach Veröffentlichung eingespielt werden kann.

Angriffe sind bislang nicht gemeldet. PHP hat weder mitgeteilt, welche Versionen betroffen sind, noch welcher Teil von PHP involviert ist oder ob eine Konfigurationseinstellung das Risiko verändert; die vollständigen Details und die korrigierten Versionen sollen mit der Veröffentlichung kommen. Zum Zeitpunkt der Abfassung war die Veröffentlichung noch nicht erfolgt — außerhalb der Gruppe, die die Lücken gefunden hat, lässt sich also nicht prüfen, ob eine Schutzmaßnahme wirkt.

Die kursierende Einstellung ist kein Schutz

In sozialen Netzwerken und Security-Blogs verbreitet sich eine einzelne Zeile in der PHP-Konfiguration: session.upload_progress.enabled=0. Sie deaktiviert Session Upload Progress, eine standardmäßig aktive PHP-Funktion, die den Fortschritt eines Datei-Uploads festhält, damit ein anderer Request ihn abfragen kann.

Das Tokioter Sicherheitsunternehmen GMO Flatt Security hatte diese Einstellung früh am 21. Oktober vorgeschlagen und dabei erklärt, man könne nicht sicher sein, dass die Änderung die Lücken vollständig adressiere, halte sie aber mit einer gewissen Wahrscheinlichkeit für hilfreich. Noch am selben Tag ruderte die Firma zurück: In einer Aktualisierung mit Zeitstempel 14:00 Uhr japanischer Zeit (05:00 UTC) hieß es, die Einstellung allein sei kein vollständiger Fix, und es sei mit Angriffen zu rechnen, die sie umgehen. Administratoren sollten ihr Update vorbereiten, den Datenverkehr schon vor der Veröffentlichung auf Angriffsmuster beobachten und den Fix einspielen, sobald er vorliegt.

Deutlicher wurde Gina Peter Banyard, PHP-Core-Entwicklerin und von der PHP Foundation finanzierte Dokumentationsautorin. Auf den Hinweis, die Upload-Progress-Einstellung könne die Lücke schließen, antwortete sie: „Das Einzige, was ich sagen kann, ist, dass die einzige Gegenmaßnahme das Patchen bzw. Aktualisieren von PHP ist. Ich weiß leider zu viel.“

Gegen ein Vertrauen in die Einstellung sprechen zwei Punkte. GMO Flatt rechnet mit einem Umgehungsweg, hat aber nicht gesagt, welcher das ist. Und die Annahme, die Lücke stecke überhaupt in Session Upload Progress, ist eine Vermutung: PHP hat das nicht bestätigt, die Firma selbst schränkte ein, ihre Aussage gelte nur, soweit die eigene Forschung mit PHP2Shell übereinstimme, und ein unabhängiges Code-Audit argumentiert, der von anderen beschriebene konkrete Fehler existiere in veröffentlichtem PHP-Code gar nicht. Dieses Audit stammt von einem anonymen Konto, und erst der PHP-Quellcode wird die Frage entscheiden — ein weiterer Grund, die Einstellung nicht als Schutzschild zu behandeln.

Einhellig ist die Einschätzung nicht. Der Anbieter Upwind führt die Einstellung weiterhin als sofortige Gegenmaßnahme und gibt dabei die Analyse eines anderen Forschers weiter statt eigener Tests. watchTowr, das eine der beiden Lücken nachgestellt hat, erklärt, es gebe „derzeit keinen bestätigten Patch und keinen bestätigten Workaround“.

Wer die Einstellung bereits gesetzt hat

Niemand rät, die Änderung zurückzunehmen — sie soll lediglich nicht als Schutz gewertet werden. Das PHP-Handbuch empfiehlt ohnehin, die Funktion dort abzuschalten, wo eine Anwendung keine Upload-Fortschrittsanzeigen nutzt, weil die gespeicherten Datei- und Feldnamen „nicht validiert werden und PHP-Code enthalten können“. Wurde die Funktion versehentlich an einer Stelle deaktiviert, die sie braucht, besteht der einzige Nachteil darin, dass Fortschrittsbalken beim Upload nicht mehr funktionieren.

Zu prüfen ist, ob die Änderung tatsächlich in dem Prozess greift, der Web-Traffic bedient, und nicht nur auf der Kommandozeile. Die Einstellung ist INI_PERDIR, kann also in php.ini, .htaccess oder .user.ini gesetzt werden. Eine .user.ini wird nur von den CGI- und FastCGI-Varianten von PHP gelesen, nicht vom Apache-Modul, und PHP liest sie standardmäßig nur alle 300 Sekunden neu — eine Änderung dort kann also fünf Minuten brauchen. Unter dem Apache-Modul sind .htaccess oder die Serverkonfiguration zu nutzen. Der Wert sollte in PHP-FPM beziehungsweise mod_php kontrolliert werden, je nachdem, was die Seite ausliefert, nicht per php -i in der Shell.

Vorbereitung auf 14:00 UTC

GMO Flatt rät, jetzt die Update-Schritte und die anschließenden Kontrollen festzulegen, etwaige Konfigurationsänderungen zu proben und Personal sowie Freigaben für einen möglichen Notfall-Neustart bereitzustellen. Zu aktualisieren ist die Laufzeitumgebung, die Web-Requests bedient — PHP-FPM, mod_php oder CGI — nicht die darüberliegende Anwendung.

PHP liefert Fixes nur für seine vier unterstützten Zweige 8.2 bis 8.5. Welche genauen Versionen den Fix tragen und wie weit die Lücken zurückreichen, soll mit der Veröffentlichung bekanntgegeben werden.

Wenn sofortiges Patchen nicht möglich ist

CERT-EU rät Organisationen, in denen ein unmittelbares Update nicht möglich ist, „in Erwägung zu ziehen, ins Internet exponierte Anwendungen von öffentlichen Netzen zu isolieren, bis ein Fix eingespielt werden kann“. Banyard formulierte dasselbe aus Projektsicht: Einen Server für einen Tag abzuschalten, „könnte das Vernünftigste sein. Aber das ist weit davon entfernt, etwas zu sein, das man von den meisten Leuten verlangen kann.“ Unterhalb einer Abschaltung bleibt, die Erreichbarkeit einzuschränken: Seite hinter VPN, Allowlist-Clients oder authentifizierten Zugang am Rand stellen und prüfen, dass Datenverkehr den Ursprungsserver nicht an diesen Kontrollen vorbei erreicht.

Zusätzlich empfiehlt GMO Flatt, den möglichen Schaden einer Übernahme zu begrenzen: auf dem Server gespeicherte Daten reduzieren, seine Rechte beschneiden, hinterlegte Zugangsdaten einschließlich Cloud-Rollen entfernen sowie Protokollierung aktivieren und die Logs an einem sicheren Ort aufbewahren, um später untersuchen zu können.

Zweige älter als 8.2 — darunter 8.1, 7.x und 5.x — sind am Ende ihrer Lebensdauer und erhalten keine PHP-Fixes. Hier bleibt nur, zu aktualisieren, das System offline zu nehmen oder zu isolieren; eine Linux-Distribution oder ein Hosting-Anbieter kann einen Fix nach eigenem Zeitplan zurückportieren.

Eine Web Application Firewall ist in diesem Fall ein schwacher Notbehelf. Cloudflare hat am 21. Oktober Notfallregeln gegen „anomale Ausführung“ ergänzt, nennt im Changelog aber weder PHP noch diese Lücken; solche Regeln sehen nur Verkehr, der durch den Anbieter läuft, und können Varianten übersehen.

Wenn PHP von anderen betrieben wird

Ein Update von WordPress, Laravel oder einer anderen Anwendung aktualisiert nicht die darunterliegende PHP-Laufzeit; die stammt aus dem Serverpaket, vom Hoster oder aus dem Container-Image. Bei Managed- oder Shared-Hosting sollte man beim Anbieter nachfragen, wann ein korrigierter PHP-Build bereitsteht. Hoster bauen ihre Pakete erst, nachdem PHP den Fix ausgeliefert hat: CloudLinux etwa erklärt, die aktualisierten Pakete hingen von der Upstream-Veröffentlichung ab und würden bereitgestellt, sobald sie fertig seien.

Was nach der Veröffentlichung zu prüfen ist

Ausnutzung war bislang nicht gemeldet: Die FAQ von watchTowr führte am 21. Oktober keine auf, und in CISAs Katalog bekannter ausgenutzter Schwachstellen fehlten die Lücken beim letzten Abgleich. Ein kurzes Demonstrationsvideo wurde veröffentlicht und wieder entfernt; das genannte Audit kommt zu dem Schluss, dass der kursierende Proof-of-Concept-Code nicht funktioniert. Das ist eine Momentaufnahme, die sich ändern kann.

Mit Erscheinen des Fixes zu prüfen sind: die korrigierte Version des eigenen Zweigs, die von PHP als betroffen gelisteten Versionen, ob PHP eine Einstellung als Gegenmaßnahme bestätigt oder verwirft, und ob sich der Session-Code geändert hat — was zugleich den Streit darüber klärt, wo die Lücke sitzt. Die korrigierten Versionen und der Sicherheitshinweis erscheinen auf php.net sowie über die GitHub-Security-Advisories des Projekts, in denen PHP eigene Kennungen vergibt. Nach dem Update sollten die Logs auf Vorgänge vor dem Patchen durchgesehen werden.