OPTIONSBLEED: Apache-Webserver blutet
Beim Apache-Webserver lassen sich in bestimmten Konfigurationen Speicherfragmente durch einen Angreifer auslesen. Besonders kritisch ist diese Lücke in Shared-Hosting-Umgebungen.
Ein Fehler im Apache-Webserver bei der Verarbeitung der "OPTIONS"-Methode führt zu einer kritischen Sicherheitslücke. Der Optionsbleed-Bug sorgt dafür, dass Apache unter bestimmten Umständen im Antwortheader auf eine entsprechende Anfrage zufällige Speicherfragmente verschickt.
Diese können Passwörter, Teile von Konfigurationsdateien, Codefragmente und vieles mehr enthalten. Die Lücke hat damit viel Ähnlichkeit mit anderen "Bleed"-Lücken wie Heartbleed oder Cloudbleed.
Das HTTP-Protokoll unterstützt verschiedene Methoden, um mit Webservern zu interagieren. Im normalen Weballtag werden meist nur zwei Methoden genutzt: GET und POST. Mit GET-Anfragen ruft man gewöhnliche Webseiten ab, mit POST-Anfragen kann man Daten an einen Webserver schicken, beispielsweise Formulareingaben. Doch HTTP unterstützt noch einige andere Methoden.
Options fragt nach unterstützten Methoden
Die OPTIONS-Methode macht etwas sehr Simples: Sie fragt beim Webserver nach, welche Methoden dieser unterstützt. Bei Webservern, die diese Methode unterstützen, wird als Antwort ein Header namens "Allow" geschickt, der eine Liste der unterstützten Methoden enthält.
Der Autor dieses Textes entdeckte vor einigen Wochen eine Reihe von Servern, die auf entsprechende OPTIONS-Anfragen mit offensichtlich defekten Allow-Headern antworteten. Teilweise wurden die Methoden mehrfach wiederholt, teilweise wurden Binärdaten mitgeschickt, teilweise waren Bruchstücke von HTML-Code oder aus Konfigurationsdateien zu sehen.
Doch woher diese seltsamen Header kamen, war zunächst unklar. Einige der Server schickten zwar einen "Server"-Header, der Auskunft über die verwendete Software gibt, aber solche Header können trügerisch sein: In vielen Setups dient eine Software als Proxy vor einem anderen Server.
Die Suche nach dem Bug gestaltet sich schwierig
Versuche, die Betreiber der entsprechenden Server zu erreichen, führten nicht weiter. Die meisten Serverbetreiber antworteten nicht oder waren nicht bereit, Details über ihr Setup mitzuteilen. Doch ein genauerer Blick auf die defekten Header gab einen Hinweis: Teilweise enthielten sie Bruchstücke von Konfigurationsoptionen, die nur in Apache genutzt werden. Es schien daher zumindest sehr plausibel, dass es sich um einen Bug in Apaches Webserver handelt.
Nach einigen Mails an das Apache-Security-Team konnte das Rätsel gelöst werden: Es handelte sich um einen Use-After-Free-Bug beim Zusammenstellen der Liste von unterstützten Methoden. Der Fehler tritt allerdings nur in einer eher ungewöhnlichen Konstellation auf.
Unbekannte Methoden verursachen Fehler
Mittels der Limit-Direktive kann in htaccess-Dateien der Zugriff auf bestimmte HTTP-Methoden beschränkt werden. Hier kam es zu dem Fehler: Versucht man, mittels htaccess den Zugriff auf eine Methode zu beschränken, die der Server noch nicht kennt, wird der entsprechende String für den Allow-Header neu zusammengesetzt. Dabei werden jedoch Strings verwendet, die bereits freigegeben wurden. Daher kommt es zu einer Memory Corruption - und der String kann alles Mögliche enthalten. Eine htaccess-Datei, die den Fehler auslöst, könnte also so aussehen:
<Limit FOOBAR>
</Limit>
Trotz dieser eher ungewöhnlichen Konstellation sind zahlreiche Server zu finden, die von dieser Lücke betroffen sind. Etwa 500 Server aus der Alexa-Top-1-Million-Liste schicken entsprechende korrupte Header. Ein Grund dafür dürfte sein, dass der Bug über Nutzergrenzen hinweg auftreten kann. Wenn auf einem Server mit mehreren Nutzern und Hosts in einem virtuellen Host die entsprechende htaccess-Option gesetzt ist, führt das auch dazu, dass andere Hosts entsprechend korrupte Header verschicken.
Gefahr für Webhoster
In Shared-Hosting-Umgebungen ist es üblich, dass sich Dutzende oder Hunderte von Webseiten einen Apache-Server teilen. Ein einziger Kunde, der eine entsprechende htaccess-Option gesetzt hat, reicht aus, um alle Webseiten auf demselben Server zu gefährden.
Ein besonderes Risiko: Ein Angreifer, der über diese Lücke Bescheid weiß, kann selbst bei einem Hostingprovider eine entsprechende htaccess-Datei hochladen und somit den Fehler auslösen. Durch entsprechende OPTIONS-Anfragen kann er anschließend Speicherfragmente von anderen Hosts, die ihm nicht gehören, auslesen.
Ein Patch für die Lücke ist bereits im Subversion-Repository von Apache vorhanden. Künftig werden in der htaccess definierte Methoden nicht mehr in den Allow-String aufgenommen. Über die distros-Mailingliste wurden die Sicherheitsteams von Linux- und BSD-Distributionen über die entsprechende Lücke vorab informiert. Aktualisierte Pakete für alle gängigen Distributionen sollten im Lauf des Tages bereitstehen. Von Apache selbst gibt es bislang noch kein Update.
Quelle:
