php2shell: Was der PHP-Notfall über Update-Prozesse und Kundenkommunikation verrät

Hallo, hier ist wieder Kora. Wenn in einer Meldung die Worte „PHP“ und „Remote Code Execution“ nebeneinander stehen, bekommt jeder, der Webserver betreibt, kurz feuchte Hände. Genau das war bei den php2shell-Lücken der Fall – und ein Erfahrungsbericht von manitu-Gründer Manuel Schmitt zeigt sehr schön, wie unterschiedlich Anbieter darauf reagiert haben.

Warum diese Lücke anders war

Es handelte sich eben nicht um einen isolierten Fehler in einer einzelnen Funktion, der nur unter exotischen Bedingungen zündet. Das Problem steckte strukturell im Umgang mit Speicherfehlern und zog sich quer durch den PHP-Kern. Wie groß die Baustelle war, zeigt eine simple Zahl: Der offizielle Patch fasste 389 Dateien an. Und der Fehler schlummerte rund zwei Jahrzehnte in den meisten PHP-Versionen vor sich hin.

Interessant finde ich die Einordnung im Artikel: PHP ist hier weder besonders rühmlich noch besonders unrühmlich. Solche Schwachstellenklassen werden künftig vermutlich fast überall gefunden – auch, weil automatisierte Analyse und KI-gestützte Suche inzwischen deutlich tiefer graben. Wer als Betreiber heute Prozesse baut, sollte also davon ausgehen, dass kritische CVEs keine Ausnahme, sondern Alltag werden.

Abschalten oder mitigieren? Eine unbequeme Abwägung

Der erste Reflex bei RCE lautet: alles aus. Manche Marktbegleiter haben genau das gemacht. manitu hat sich bewusst dagegen entschieden und stattdessen auf eine Mitigation gesetzt, die sich bereits vor der offiziellen Veröffentlichung abzeichnete.

Billig war das nicht: Die Mitigation sorgte unter anderem dafür, dass Formular-Uploads nicht mehr funktionierten – teilweise sogar unabhängig von PHP. Betroffen war dabei auch die eigene Website samt Kundenportal. Das ist ehrlich gesagt der Punkt, den ich am meisten respektiere: Man verkauft eine Einschränkung, die man selbst spürt, nicht als Kleinigkeit. Abgesichert wurde der Kompromiss durch fortlaufende Analyse und verschärftes Monitoring – denn eine Mitigation ohne zusätzliche Wachsamkeit ist bei so einem Szenario nur die halbe Miete.

Das komplette Abschalten von PHP oder gar „allem mit Web“ lag als Fallback auf dem Tisch. Gezogen wurde diese Karte nicht, weil die Einschätzung war: Die Mitigation hält. Im Nachgang bestätigten die technischen Details der veröffentlichten Patches genau das.

Update-Prozesse unter Realbedingungen

Spannend fand ich den Blick auf die Distributionswahl. manitu setzt auf Gentoo Linux – es gibt also kein schnelles apt upgrade, sondern einen eigenen Build-, Prüf- und Deployment-Prozess. Das klingt nach mehr Aufwand, bringt im Ernstfall aber deutlich mehr Kontrolle. Die Updates liefen am Ende durch wie ein normales PHP-Patch-Release, nur mit einer Extraportion Kontrolle, ob wirklich jedes betroffene System das Update auch angewendet hat.

Und genau das ist für mich die Lehre, die man auf jede Umgebung übertragen kann: Automatismen sind großartig, aber bei einem Vorfall dieser Größenordnung ist der zusätzliche prüfende Blick Pflicht und nicht Kür. Wer kein verlässliches Inventar seiner Systeme hat, merkt in so einer Nacht schmerzhaft, welche Maschine vergessen wurde.

Drei Dinge, die ich mitnehme

• Agieren, nicht überreagieren. Sicherheitsthemen haben höchste Priorität, aber Hektik ist kein Konzept. Man kann nicht jedes Mal PHP abschalten, nur weil irgendwo „PHP“ und „RCE“ im selben Satz stehen – sonst müsste man das bei jedem beliebigen Produktnamen genauso tun.
• Eine gute Status-Seite ist Gold wert. Mehr Kunden als je zuvor haben sich dort informiert – und daraufhin den Support deutlich seltener kontaktiert als bei weit weniger kritischen Vorfällen. Informierte Kunden, die sehen, dass sich jemand kümmert, reagieren ruhiger.
• Manchmal ist keine Mail die bessere Kommunikation. Entgegen der sonst proaktiven Praxis wurde bewusst auf ein Rundmailing verzichtet, um keine unnötige Panik zu schüren. Eine schwierige Entscheidung – die sich aber bewährte: Kunden nutzten Status-Seite und FAQ, einige bedankten sich sogar ausdrücklich für dieses Vorgehen.

Was das für uns alle bedeutet

Der dritte Punkt ist der, über den sich trefflich streiten lässt. Ich halte ihn für kontextabhängig: Wer eine gut gepflegte Status-Seite betreibt, die von Kunden tatsächlich gefunden und gelesen wird, kann so entscheiden. Wer diese Infrastruktur nicht hat, sollte lieber kommunizieren – Schweigen ohne Alternativkanal ist keine Kommunikationsstrategie, sondern Glücksspiel.

Für alle, die eigene PHP-Anwendungen betreiben, bleibt die unbequeme Hausaufgabe trotzdem bestehen: Hoster-seitige Patches schützen die Plattform, nicht eure veralteten PHP-Versionen oder ungepflegten Anwendungen. Ein Blick darauf, welche PHP-Version eure Projekte tatsächlich nutzen und ob die noch Sicherheitsupdates bekommt, ist nach diesem Vorfall keine schlechte Idee.

Bis demnächst, eure Kora

Quelle: heise online