Am 21. Oktober hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen. Beide erlauben es, Code ohne jede Anmeldung auszuführen — es braucht kein Konto, kein Passwort und keine Lücke in der Website selbst. Es genügt, dass PHP die Anfrage bearbeitet.
Behoben sind sie in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Bewertung liegt bei 9.2 von 10. In den ersten Meldungen stand eine 10.0; das war zu hoch angesetzt.
Das PHP-Projekt schreibt dazu einen Satz, der selten so deutlich ausfällt: Nur das Update löst das Problem. Die kursierenden Gegenmassnahmen verringern das Risiko, machen eine Installation aber nicht sicher.
Also einspielen. Das wollten wir auch.
Was unsere Server meldeten
Auf unseren beiden Produktionsservern haben wir am Abend nach der Meldung geprüft, was zu tun ist. Die Antwort lautete: nichts.
Keine Aktualisierung verfügbar. Keine Warnung. Die Liste der anstehenden Pakete war leer.
Das war falsch. Die Pakete lagen seit dem Vormittag bereit — 8.2.35 um 07:37 Uhr, 8.3.36 um 08:04, 8.4.27 um 08:34, 8.5.12 um 09:16. Unsere Server kannten sie bloss nicht.
Der Fehler, den niemand liest
Die Ursache war eine Zeile, die beim Aktualisieren der Paketlisten mitläuft und wie Rauschen aussieht: eine Warnung, dass eine Signatur nicht geprüft werden konnte.
Jedes Paket aus einer vertrauenswürdigen Quelle ist digital unterschrieben. Der Server prüft die Unterschrift, bevor er etwas installiert — das ist richtig so, denn sonst liesse sich ein Paket unterwegs austauschen. Dafür hält er eine Liste der zugelassenen Schlüssel. In dieser Liste fehlten zwei von sechs.
Die Folge war nicht, dass ein Update fehlschlug. Die Folge war schlimmer: Der Abruf brach an den betroffenen Quellen ab — und liess dabei auch die funktionierenden Listen auf ihrem alten Stand stehen. Dieser Stand war der 25. September.
Vier Wochen lang hat uns der Server also nicht gesagt «hier fehlt ein Update». Er hat gesagt: alles in Ordnung. Auf dem zweiten Server wurden nach der Reparatur 107 zurückgehaltene PHP-Pakete sichtbar.
Warum das gefährlicher ist als ein offenes Update
Ein bekanntes, nicht eingespieltes Update ist ein Posten auf einer Liste. Es ist unangenehm, aber es ist sichtbar, und irgendwann arbeitet es jemand ab.
Ein stiller Fehler in der Paketquelle hat keine Liste. Er erzeugt keine Meldung, keinen Eintrag, keinen roten Punkt — nur Ruhe. Und Ruhe liest sich wie Sicherheit.
Wir haben das im September schon einmal beschrieben, damals eine Stufe weiter vorne: Ein eingespieltes Update ist noch kein aktives Update, solange der Dienst nicht neu gestartet wurde. Diesmal lag es eine Stufe davor. Das Update war nicht einmal angeboten.
Und hier gehört die unbequeme Hälfte dazu: Aufgefallen ist das nur, weil es diesmal einen konkreten Anlass gab. Ohne die Meldung vom 21. Oktober hätten wir die Zahlen nicht gegeneinander gehalten, und der Fehler hätte weiter still gelegen. Das ist kein Zufallsfund, auf den man sich einrichten kann — das ist eine Lücke in unserer eigenen Überwachung.
Was zu prüfen ist, wenn Sie selbst einen Server betreiben
Vergleichen Sie die laufende Version mit der Zielversion des Herstellers, nicht mit dem, was der Paketmanager anbietet. Eine leere Liste anstehender Updates ist kein Beweis für Aktualität. Sie kann auch bedeuten, dass die Liste veraltet ist.
Schauen Sie sich das Datum der Paketlisten an. Liegt es Wochen zurück, obwohl täglich aktualisiert wird, stimmt etwas nicht.
Lesen Sie die Warnungen beim Aktualisieren. Signaturfehler stehen dort im Klartext. Sie sehen nur nicht nach einem Notfall aus.
Und prüfen Sie am Ende die Version, die der Webserver tatsächlich benutzt — nicht die auf der Kommandozeile. Das sind oft zwei verschiedene.
Was bei uns offen bleibt
Beide Server stehen jetzt auf den korrigierten Versionen, alle Dienste laufen, alle Zweige antworten. Vollständig ist die Lage damit nicht.
Für PHP 7.4, 8.0 und 8.1 liefert das PHP-Projekt keine regulären Updates mehr, sondern nur minimale Nachbesserungen im Quellcode. Ob daraus ein einspielbares Paket wird, entscheidet der Anbieter der jeweiligen Distribution — und das fällt je nach Fassung unterschiedlich aus. Für unsere Server ist bis jetzt keines erschienen. Die siebzehn Websites, die dort noch auf diesen Versionen laufen, sind damit nicht versorgt, und für jede einzelne heisst die Antwort: umziehen auf eine unterstützte Version.
Auf einem Server, den wir mitbetreuen, läuft ein Betriebssystem, dessen Unterstützung seit Jahren beendet ist. Dort gibt es gar keinen Weg zu einem Update. Das ist keine Konfigurationsfrage mehr, sondern eine Entscheidung, die vorher getroffen wurde — und die jetzt fällig wird.
Ob die Lücken tatsächlich schon ausgenutzt werden, lässt sich zurzeit nicht sauber sagen. Einzelne Sicherheitsanbieter melden Versuche, andere halten verlässliche Belege für ausstehend. Für die Dringlichkeit macht das wenig Unterschied: Bei einer Lücke, die ohne Anmeldung funktioniert, ist der Abstand zwischen Veröffentlichung und erstem Scan erfahrungsgemäss kurz.
Wenn Sie Ihre Website bei uns haben, ist das erledigt. Falls Sie nicht wissen, welche PHP-Version Ihre Website benutzt oder wer dort nachsieht, fragen Sie das besser diese Woche als nächsten Monat.