PHP2Shell-Patch ist der einzig zuverlässige Fix für PHP-Schwachstellen
PHP2Shell umfasst zwei kritische PHP-Schwachstellen vom Typ remote code execution (RCE), also Schwachstellen, durch die ein Angreifer von einem anderen Ort aus Befehle auf einem anfälligen Webserver ausführen könnte. PHP bewertet beide Schwachstellen mit 9,2 von 10 Punkten und plante die Veröffentlichung der Fixes für den 21. Oktober um 14:00 UTC. Zum Zeitpunkt der Berichterstattung waren diese Fixes noch nicht veröffentlicht, und PHP hatte weder die betroffenen Versionen noch die anfällige Komponente oder einen konfigurationsbasierten Workaround bekannt gegeben.
Aufgrund dieses Mangels an technischen Details können Administratoren derzeit nicht nachweisen, dass eine bestimmte Schutzeinstellung PHP2Shell blockiert. Cloudflare meldete frühe Exploit-Versuche und führte Notfall-Filterregeln ein, auch für seinen kostenlosen Tarif, bezeichnete diese Regeln jedoch lediglich als vorübergehenden Schutz, bis die Systeme gepatcht werden können. Es war keine erfolgreiche Kompromittierung bestätigt worden, für öffentlich kursierenden Exploit-Code war keine Funktionsfähigkeit nachgewiesen worden, und keine der beiden Schwachstellen war bei einer Überprüfung am 21. Oktober im Katalog der bekanntermaßen ausgenutzten Schwachstellen der US Cybersecurity and Infrastructure Security Agency aufgeführt. Unabhängig davon erklärte watchTowr, eine der Schwachstellen reproduziert, aber keine Angriffe festgestellt zu haben.
Die am häufigsten verbreitete vorgeschlagene Schutzmaßnahme ist session.upload_progress.enabled=0, wodurch PHPs Funktion Session Upload Progress deaktiviert wird. Diese Funktion ist standardmäßig aktiviert und zeichnet den Fortschritt eines Datei-Uploads auf, damit eine andere Anfrage ihn überprüfen kann. GMO Flatt Security vermutete zunächst, dass die Deaktivierung helfen könnte, warnte jedoch zugleich, keinen vollständigen Schutz bestätigen zu können. In einer Aktualisierung mit dem Zeitstempel 14:00 Uhr japanischer Zeit beziehungsweise 05:00 UTC stellte das Unternehmen klar, dass die Einstellung allein nicht ausreiche und Angreifer sie voraussichtlich umgehen könnten. Mitglieder des PHP-Projekts erklärten ebenfalls, dass Änderungen an INI-Konfigurationseinstellungen das Patchen oder ein Upgrade von PHP nicht ersetzen können.
Es gibt außerdem keine öffentliche Bestätigung dafür, dass sich eine der beiden Schwachstellen in Session Upload Progress befindet. GMO Flatt Security stützte seine Empfehlung auf die eigene Einschätzung dazu, was PHP2Shell betreffen könnte. Ein anonymes Code-Audit widersprach der Behauptung, dass diese Funktion die Schwachstelle enthalte, und erklärte, dass der kursierende proof-of-concept bei veröffentlichten PHP-Versionen nicht funktioniere. Upwind führte die Einstellung auf Grundlage der Analyse eines anderen Sicherheitsforschers weiterhin als sofortige Schutzmaßnahme auf, während watchTowr erklärte, dass es keinen bestätigten Workaround gebe. Der noch ausstehende Sicherheitshinweis von PHP und die Codeänderungen sind erforderlich, um diese Meinungsverschiedenheit zu klären.
Administratoren, die den Upload-Fortschritt bereits deaktiviert haben, müssen die Änderung nicht rückgängig machen, sollten sie jedoch nicht als Sicherheits-Fix betrachten. Das PHP-Handbuch empfiehlt bereits, die Funktion zu deaktivieren, wenn eine Anwendung keine Fortschrittsanzeigen für Uploads benötigt, da gespeicherte Datei- und Formularfeldnamen nicht validiert werden und PHP-Code enthalten können. Wird die Funktion auf einer Website deaktiviert, die sie benötigt, funktionieren deren Fortschrittsanzeigen für Uploads nicht mehr.
Die Einstellung muss außerdem in dem PHP-Prozess geändert werden, der die Website-Anfragen tatsächlich verarbeitet. Es handelt sich um eine INI_PERDIR-Option, die über php.ini, .htaccess oder .user.ini konfiguriert werden kann. Die Methode mit .user.ini gilt nur für CGI- und FastCGI-Deployments, nicht für das Apache-Modul. PHP prüft diese Datei standardmäßig alle 300 Sekunden, sodass es fünf Minuten dauern kann, bis eine Änderung aktiv wird. Websites, die das Apache-Modul verwenden, benötigen .htaccess oder eine Serverkonfiguration. Die Prüfung mit php -i in einer Kommandozeile bestätigt nicht den Wert, den PHP-FPM oder mod_php für Web-Traffic verwendet.
Administratoren, die zeitnah aktualisieren können, sollten vor der Veröffentlichung ihr Deployment-Verfahren, die Prüfungen nach dem Update, erforderliche Freigaben und einen gegebenenfalls notwendigen Neustart vorbereiten. Zu aktualisieren ist die PHP runtime, die Web-Anfragen verarbeitet, beispielsweise PHP-FPM, mod_php oder CGI, und nicht WordPress, Laravel oder eine andere darauf ausgeführte Anwendung. PHP stellt derzeit Fixes für vier unterstützte Versionszweige von 8.2 bis 8.5 bereit. Die genauen korrigierten Releases und die vollständige Spanne der betroffenen Versionen sollten zusammen mit dem Sicherheitshinweis veröffentlicht werden.
Websites, die nicht sofort gepatcht werden können, sollten ihre Exposition verringern. CERT-EU empfiehlt, eine Isolierung von Anwendungen mit Internetzugang von öffentlichen Netzwerken in Betracht zu ziehen, bis ein Fix verfügbar ist. Praktische Möglichkeiten sind, eine Website vorübergehend offline zu nehmen oder sie hinter einen authentifizierten Zugang, ein VPN oder eine allowlist zugelassener Clients zu stellen. Administratoren müssen außerdem verhindern, dass Besucher diese Kontrollen umgehen und den origin server direkt erreichen. GMO Flatt Security empfiehlt zusätzlich, die gespeicherte Datenmenge und die Serverberechtigungen zu reduzieren, gespeicherte Zugangsdaten und Cloud-Rollen zu entfernen und Logs für spätere Untersuchungen an einem sicheren Ort aufzubewahren.
Nicht unterstützte PHP-Versionszweige vor 8.2, darunter 8.1, 7.x und 5.x, erhalten direkt von PHP keine Fixes. Diese Systeme müssen aktualisiert, isoliert oder aus dem Internet entfernt werden. Eine Linux-Distribution oder ein Hostinganbieter kann jedoch einen backport bereitstellen, bei dem die Sicherheitskorrektur eingespielt wird, ohne auf eine neuere Hauptversion zu wechseln. CloudLinux erklärte, dass seine Pakete von der Veröffentlichung des Upstream-Release durch PHP abhängig seien und anschließend bereitgestellt würden.
Eine weitere vorgeschlagene Übergangslösung besteht darin, Anfragen mit einem multipart/form-data-Body bereits am Webserver abzulehnen, bevor PHP sie verarbeitet. Dies zielt auf das mutmaßlich an den Schwachstellen beteiligte Anfrageformat ab, ist jedoch weiterhin nicht bestätigt. Nur POST-Anfragen zu blockieren reicht nicht aus, da PHP 8.4 request_parse_body() eingeführt hat, womit multipart-Bodys verarbeitet werden können, die mit anderen Methoden gesendet wurden. Eine umfassendere Blockierung unterbricht Datei-Uploads und Formulare, die multipart-Daten verwenden, selbst wenn keine Datei angehängt ist.
Eine web application firewall kann bekannte schädliche Anfragemuster filtern, ist jedoch kein Ersatz für den PHP2Shell-Patch. Die Regeln von Cloudflare prüfen nur Anfragen, die über den Dienst geleitet werden, können einen weiterhin direkt erreichbaren origin server nicht schützen und könnten neue Angriffswege übersehen. Für Betreiber von WordPress-Websites, die ihre Hosting-Konfiguration überprüfen, bietet AEU Hosting vollständig abgesichertes Managed WordPress Hosting an.
Kunden von Managed Hosting und Shared Hosting sollten ihren Anbieter fragen, wann das korrigierte PHP-Paket installiert wird. Linux-Distributionen wie Debian und Ubuntu können eine alt wirkende PHP-Version beibehalten und die Korrektur per backport einspielen. Daher lässt sich anhand des sichtbaren Versionsstrings allein möglicherweise nicht feststellen, ob ein Server geschützt ist. Administratoren sollten die vollständige Paketversion mit dem Sicherheitshinweis der Distribution vergleichen oder das Changelog prüfen. Nach dem Update sollten sie über php.net oder die GitHub-Sicherheitshinweise von PHP das korrigierte Release für ihren Versionszweig bestätigen, prüfen, welche Versionen PHP als betroffen einstuft, und die Logs auf verdächtige Aktivitäten untersuchen, die vor dem Patchen stattgefunden haben.