Dipl.-Inform. Carsten Eilers

Leider ist das wohl nicht der Fall, wie "Kingcope" nun herausfand. Ein von ihm unter dem Namen Apache Killer auf der Mailingliste Full-Disclosure veröffentlichter Proof-of-Concept nutzt die Schwachstelle für DoS-Angriffe aus (Eintrag im ASF Bugzilla dazu). Es handelt sich zwar nicht um genau die gleiche Schwachstelle, eine gewisse Verwandtschaft besteht aber. Die Apache-Entwickler diskutieren das Problem auf der Entwickler-Mailingliste und haben mit einem Security Advisory auf die Schwachstelle und das veröffentlichte Tool reagiert.

Daten, viele Daten, zu viele Daten

Während Michal Zalewski den Byte-Range-Header nutzte, um dem Server zum Senden möglichst große Daten zu bringen, wird er von "Kingcope" genutzt, um dem Speicher des Servers zu (über)füllen. Wobei Michal Zalewskis Ansatz (zusätzlich) Protokollbedingt ist und alle Server betrifft, die RFC 2616 korrekt implementieren. Das Problem wird von der IETF zur Zeit diskutiert. Ggf. muss das Protokoll angepasst werden, um die mögliche Schwachstelle zu berücksichtigen.

Aber kommen wir zurück zum aktuellen Exploit. Über "Byte Ranges" ist es möglich, nur bestimmte Teile eines Dokuments zu laden, z.B. die Bytes 1.000 bis 2.000. Damit ist es z.B. möglich, abgebrochene Downloads fortzusetzen statt sie neu zu starten. Wenn der Browser die ersten 5.000 Bytes bereits geladen hat, muss er ja nur noch die Bytes ab 5.001 laden, um die Datei zu vervollständigen. Der Apache stolpert nun über mehrere ungeordnet angeforderte Byte Ranges und belegt beim Vorbereiten der auszuliefernden Daten den gesamten verfügbaren Speicher.

Den Apache-Entwicklern ist die aktuelle Schwachstelle nur teilweise anzukreiden: Der Apache-Server muss auf Anforderung mehrere sich überlappende Ranges ausliefern, um dem Standard zu entsprechen. Der Fehler der Entwickler liegt darin, dass er dabei sehr ungeschickt vorgeht und sehr viel Speicher belegt. Und dieser Teil der Schwachstelle soll nun behoben werden.

Workarounds

Es sind mehrere Workarounds bekannt. Auf der Mailingliste Full Disclosure wurden Rewrite-Regeln vorgeschlagen, die GET- und HEAD-Requests mit mehreren Ranges im RANGE-Header ausfiltern. Diese Regeln sind jedoch unvollständig, da sie nur den aktuellen Exploit berücksichtigen, der Angriff aber auch über RequestRange-Header erfolgen kann. Das Security Advisory der Apache-Entwickler enthält passende Regeln und führt weitere Workarounds auf. Z.B. ist es auch möglich, mit mod_headers die RANGE-Header komplett zu löschen:
RequestHeader unset Range
Darüber werden aber fast alle Clients stolpern, die Daten schrittweise laden wollen oder müssen.

Und wer denkt an die KinderVorfahren?

Ein Patch soll demnächst erscheinen. Aber was ist mit dem ebenfalls betroffenen, nicht mehr unterstützten Apache 1.3? Wird es dafür zumindest halb-offizielle Patches der jeweiligen Distributionen geben, oder gehen die leer aus? Und was ist mit all den seit einer halben Ewigkeit nicht mehr aktualisierten Apache-2.x-Servern im Web? Ob die ganzen veralteten Apache-Installationen jetzt wohl ersetzt bzw. aktualisiert werden? Ansonsten dürften sie bald ein gefundenes Fressen für die Skriptkiddies sein. Wer also noch so eine Antiquität mit Internetanschluss betreibt, sollte jetzt besser den Stecker ziehen. Zumindest den für den Internetanschluss.

Duck&Cover!

Laut Netcraft sind gut 65% aller Webserver Apaches, und bis der Patch alle erreicht hat, dürfte es eine Weile dauern. Jede Menge potentieller Opfer für die Skriptkiddies also. Wenn Sie einen Apache-Server betreiben, sollten Sie prüfen, ob er von der Schwachstelle betroffen ist (was i.A. der Fall sein wird), wenn möglich einen Workaround ergreifen und den Patch nach seiner Veröffentlichung so schnell wie möglich installieren. Beim Shared Hosting bleibt nur die Hoffnung, dass die Hoster angemessen reagieren.

Außer dem in Perl geschriebenem Apache Killer wurden für PHP mehrere Möglichkeiten entwickelt, einen Server auf seine Anfälligkeit zu testen: Für das Zend-Framework von Michael Kliewe, mit Hilfe von cURL von Fabian Beiner und eine reine PHP-Lösung von Norbert Bartels (alle via PHP Magazin gefunden). Der Nachteil aller Tests: Sie führen sehr wahrscheinlich zu einem DoS. Also überlegen Sie sich sehr gut, ob Sie ihren Server wirklich testen wollen oder sich einfach nach der Aussage der Apache-Entwickler im Security Advisory richten:
"Versions: Apache 1.3 all versions, Apache 2 all versions"
und
"The default Apache HTTPD installation is vulnerable."
Da bleibt kaum ein Apache übrig, der nicht betroffen ist.

Ach ja: Mit dem Patch wird die Schwachstelle natürlich nur teilweise geschlossen. Wenn irgendwann die Protokollspezifikation angepasst wurde, muss die Implementierung noch daran angepasst werden, um die Schwachstelle endgültig zu beheben.

Carsten Eilers