Shellshock: Wie eine Webanfrage über Bash Befehle ausführte

Am 24. September 2014 wurde eine Sicherheitslücke in Bash bekannt, der Shell von Linux, Unix und macOS: dem Programm, das Befehle liest und ausführt. Über sie konnte eine einzige präparierte Webanfrage beliebige Befehle auf einem Webserver ausführen. Die Sensoren von Cisco registrierten noch am selben Tag Angriffe, und es brauchte sechs Patches in elf Tagen, um die Lücke und die danach gefundenen Schwachstellen zu schließen.

So funktionierte der Angriff

Programme geben den Programmen, die sie starten, Einstellungen in Umgebungsvariablen mit: kleinen Textstücken mit jeweils einem Namen. Bash nutzt sie für eine weitere Aufgabe: Die Shell kann eigene kleine Programme, sogenannte Funktionen, an die nächste Bash weitergeben, die sie startet. Dazu schreibt sie die Funktion in eine Variable, deren Text mit () { beginnt.

Jeder neue Bash-Prozess ging alle seine Variablen durch und machte aus jeder, die wie eine Funktion aussah, eine Funktion. Dazu schickte er den Text durch seinen normalen Befehlsleser, den Parser. Der Parser hielt jedoch nicht an der schließenden Klammer der Funktion an, sondern führte auch jeden Befehl aus, der danach stand.

Das wäre harmlos gewesen, wenn nur Bash selbst solche Variablen geschrieben hätte. Viele Programme kopieren jedoch Eingaben von außen in Variablen, bevor sie eine Shell starten. Webserver tun das für CGI-Skripte, kleine Programme, die ein Server startet, um eine Seite zu erzeugen: Der User-Agent-Header einer Anfrage, die Zeile, die normalerweise den Browser nennt, wird zur Variablen HTTP_USER_AGENT. DHCP-Clients, die Netzwerkeinstellungen abrufen, machen dasselbe mit Einstellungen, die das Netzwerk schickt, und ebenso OpenSSH, das Programm für Remote-Anmeldungen, bei Konten, die auf einen festen Befehl beschränkt sind.

Reichweite und Angriffe

Bash gehört bei Linux und macOS zum Grundbestand des Betriebssystems, schrieb US-CERT, das Computer-Notfallteam der US-Regierung, in seiner Warnung. Auf Linux allein laufen heute laut W3Techs 63,2 % aller Websites, deren Betriebssystem bekannt ist. Allerdings ließ sich nicht jeder dieser Server angreifen: Ein Angreifer brauchte einen Weg von außen bis zu Bash, etwa über ein CGI-Skript.

Keine unabhängige Studie hat gemessen, wie viele Systeme verwundbar waren oder angegriffen wurden. Alle Angriffszahlen stammen von Sicherheitsfirmen, und jede sieht nur ihre eigenen Kunden. Deshalb lassen sich die Zahlen nicht addieren:

• Cloudflare, das den Datenverkehr von Websites filtert, blockierte bis zum 30. September 2014 weit über 1,1 Millionen Shellshock-Angriffe. Anfangs zählte es 10 bis 15 Angriffe pro Sekunde.
• Incapsula, ein Firewall-Dienst von Imperva, wehrte in den vier Tagen nach der Bekanntgabe über 217.089 Angriffsversuche auf über 4.115 Websites ab. Die Angriffe kamen von mehr als 890 IP-Adressen.
• Die Sensoren von Cisco zeigten den Höhepunkt der Angriffe am 26. September 2014 und eine weitere Spitze zwei Tage später.

Die meisten dieser Angriffe waren Tests. In den Daten von Cloudflare waren etwa 83 % Erkundung: Anfragen, die nur prüfen, ob ein Server verwundbar ist. Etwa 8 % versuchten, den Server direkt zu übernehmen.

Sechs Patches in elf Tagen

Das Bash-Projekt veröffentlichte seinen ersten Patch noch am Tag der Bekanntgabe. Er war unvollständig. Am 25. September erhielt eine zweite Schwachstelle eine eigene Nummer, CVE-2014-7169, weil Bash nach bestimmten fehlerhaften Funktionsdefinitionen immer noch nachfolgenden Text ausführte. Danach fanden Forscher weitere Schwachstellen im Parser, und die Warnung von US-CERT wuchs bis zum 30. September auf sechs CVE-Nummern.

Der dauerhafte Fix war Patch 027. Seitdem gibt Bash Funktionen nur noch unter besonderen Variablennamen weiter (BASH_FUNC_name%%), sodass eine gewöhnliche Variable, etwa eine aus einer Webanfrage, nie als Code behandelt wird. Damit waren die späteren Parser-Fehler über Variablen nicht mehr erreichbar. Ältere Bash-Versionen erhielten entsprechende Patches, und die Linux-Distributionen lieferten sie als Updates aus. Red Hat etwa verfolgte die Meldung seit dem 15. September 2014 unter Embargo, also geheim, bis ein Fix bereitstand.

Die Warnung von US-CERT gab der Lücke die höchstmögliche Bewertung für die Auswirkungen, 10. Heute bewertet die NVD, die US-amerikanische National Vulnerability Database, die ursprüngliche Lücke mit 9,8 von 10 auf Version 3.1 der CVSS-Skala; auf der älteren Version 2 erreichen alle sechs Shellshock-CVEs den Wert 10. Die US-Cyberbehörde CISA nahm die ursprüngliche Lücke und die erste Umgehung am 28. Januar 2022 in ihre Liste ausgenutzter Schwachstellen auf, eine der späteren Parser-Lücken, CVE-2014-6278, am 2. Oktober 2025.