Shellshock (Sicherheitslücke)

Vom Fedora Magazine verwendetes Logo für Shellshock

Shellshock ist eine Software-Sicherheitslücke (CVE-Nummern CVE-2014-6271, .. -7169, -7186, -7187, -6277[1]) in der Unix-Shell Bash. Die Bash ermöglicht es in Variablen Funktionen zu definieren. Durch die Sicherheitslücke kann nach der Auswertung solcher Variablen ungeprüft Programmcode ausgeführt werden.[2] Die Entdeckung wurde am 24. September 2014 öffentlich gemacht. In der vom NIST verwendeten Bewertung des Schadenpotentials erhält Shellshock eine Bewertung von 10, dem Maximum.[3] Am Tag der Veröffentlichung wurde bereits ein Patch veröffentlicht. Tavis Ormandy von Google konnte jedoch wenige Stunden später zeigen, dass auch gepatchte Bash-Shells noch ein Problem haben, allerdings fand Ormandy keine Möglichkeit, dies für einen Angriff auszunutzen.[4] Dieses zweite Problem hat vom NIST ebenfalls eine CVE-Nummer erhalten.[5] Kurz darauf wurden von Entwicklern der Linux-Distribution Redhat zwei weitere Speicherzugriffsfehler gefunden.[6] Der Erste ist ein fehlerhafter Array-Zugriff, der Zweite tritt bei verschachtelten Schleifen auf. Michaeł Zalewski entdeckte einen zusätzlichen Fehler, zu dem aber bisher keine Details veröffentlicht wurden.[1]

Problematik

Von der Sicherheitslücke sind Bash-Versionen zwischen 1.14 und 4.3 betroffen, die häufig unter GNU/LinuxMac OS X oder anderen Unix-basierten Betriebssystemen verwendet werden. Shellshock soll auch deswegen besonders problematisch sein, weil zahlreiche Webserver Bash verwenden, um CGI-Skripte auszuführen.[7]

Die Sicherheitslücke kann ausgenutzt werden, wenn Variablen gesetzt werden können, die dann von einer Bash mit höheren Rechten ausgewertet werden. Beispiele sind:[8]

  • Webserver: CGI-Skripte, die als Webserver Bash aufrufen, könnten beliebigen Code ausführen
  • Secure Shell: Nutzer, deren Rechte auf die Ausführung bestimmter Kommandos beschränkt sind, können diese Beschränkung umgehen
  • DHCP: Bei Verbindung zu einem bösartigen DHCP-Server kann ein Angreifer einen beliebigen Code auf dem DHCP-Client ausführen
  • Der Druckdienst CUPS könnte von rechtmäßigen Benutzern zur Ausführung von beliebigen Code genutzt werden
  • SIP(Session Initiation Protocol): siehe auch sipshock[9]

Weltweit sollen hunderte Millionen von Computern betroffen sein.[10] Die Sicherheitslücke wird von Forschern für gravierender als der Heartbleed-Bug gehalten.[11] Shellshock wurde von Stephane Chazelas entdeckt und existiert seit 1989 in Bash.[12][13]

Updates

Mac OS X

Versionen 10.7–10.10

Für Mac OS X hat Apple am 29. September 2014 einen Patch für OS X 10.9 Mavericks, OS X 10.8 Mountain Lion und OS X 10.7 Lion veröffentlicht, der die Sicherheitslücke schließt, OS X 10.10 Yosemite ist seit der öffentliche Beta-Version 4 einen Tag später ebenfalls abgesichert und verhindert die unbefugte Ausführung von Schadcode.[14][15]

Ältere Versionen

Ältere OS-X-Versionen werden von Apple nicht mehr gepatcht, die Bash-Datei kann auf älteren Systemen aber durch eine aktualisierte Version ausgetauscht werden.[16]

Linux

Von Florian Weimar, Entwickler bei Redhat, wurde ein Patch für die Bash-Lücke veröffentlicht.[17]

Prüfung auf Verwundbarkeit

Die Verwundbarkeit der Shell lässt sich durch die folgende Eingabe auf der Kommandozeile testen.[18] Bei einer verwundbaren Shell führt die Sequenz

$ env x='() { :;}; echo shellshockverwundbar' bash -c ""

zur Ausgabe von "shellshockverwundbar", während ein geschütztes System nichts oder Fehlermeldungen ausgibt.

Ob das System auch einen Patch für CVE-2014-7169 hat, testet die Folge

$ env X='() { (a)=>\' sh -c "echo date"; cat echo

Bei einer verwundbaren Shell sieht man folgende Ausgabe:

date
Fr 26. Sep 13:00:00 CEST 2014

Ist die Shell dagegen geschützt, erhält man diese Ausgabe:

date
cat: echo: No such file or directory

Technischer Hintergrund

Bash ermöglicht es Variablen und Funktionen zu definieren, die dann innerhalb der jeweiligen Bash-Instanz bzw. innerhalb des aktuellen Bash-Skripts verwendet werden können. Darüber hinaus ist es beim Aufrufen einer neuen Bash-Instanz möglich, sowohl Variablen als auch Funktionen aus der aktuellen Bash-Instanz in die neue Bash-Instanz zu vererben. Zu diesem Zweck muss die entsprechende Variable oder Funktion zuvor mit dem export-Schlüsselwort "exportiert" worden sein.

Technisch gesehen erfolgt das Exportieren von Variablen und Funktionen über Umgebungsvariablen. Da Umgebungsvariablen jedoch nur einfache Schlüssel/Wert Paare erfassen können, müssen Funktionen beim Exportieren als String (Zeichenkette) kodiert werden. Bash verwendet für Funktions-Definitionen spezielle Umgebungsvariablen, deren Inhalt mit der Zeichenfolge „()“ beginnt. Bash überprüft daher unmittelbar nach dem Start alle vorhandenen Umgebungsvariablen nach solchen Funktions-Definitionen. Für jede gefundene Funktions-Definition wird dann automatisch eine entsprechende Funktion in der aktuellen Bash-Instanz angelegt.

Der Bug, der zur sogenannten Shellshock Sicherheitslücke geführt hat, betrifft das Parsen der Funktions-Definitionen. Dadurch lässt sich der eigentlichen Funktions-Definition zusätzlicher Code anfügen, den Bash beim Parsen der entsprechenden Umgebungsvariable sofort und ungeprüft ausführt. Dies gilt selbst dann, wenn die entsprechende Funktion niemals aufgerufen wird. Ein Angreifer muss somit lediglich dazu in der Lage sein, Umgebungsvariablen zu setzen, um ausführbaren Code in die jeweilige Bash-Instanz einzuschleusen. Dies ist, unter anderem, bei CGI-Anwendungen gegeben, da hier die Aufrufparameter, welche vom Client kontrolliert werden, ebenfalls in Form von Umgebungsvariablen übergeben werden.

Beispiel: Exportieren einer Funktion in Bash

Folgende Befehls-Sequenz exportiert die Funktion „myfunc"“, was zum Anlegen einer entsprechenden Umgebungsvariable führt:

#Funktion definieren
myfunc () { echo "Hello world!"; }

#exportieren
export -f myfunc

#Umgebungsvariablen ausgeben
printenv

Ausgabe:

# [...]
myfunc=() {  echo "Hello world!"
}

Beispiel: Ausnutzen der „Shellshock“-Lücke

Folgende Befehlszeile startet eine neue Bash-Instanz, wobei mittels env-Befehl die Umgebungsvariable x auf den Wert () { :;}; echo shellshockverwundbar gesetzt wird. Auf die eigentliche Funktionsdefinition () { :;} folgt also zusätzlich der (harmlose) Befehl echo shellshockverwundbar. Eine verwundbare Bash-Version wird diesen angefügten Befehl ungeprüft ausführen und dementsprechend den Text "shellshockverwundbar" auf der Konsole ausgeben. Es ist zu beachten, dass in diesem Fall ein potentieller Angreifer auf die gleiche Weise beliebige Befehle an Bash übergeben kann.

Einzelnachweise

  1. a b Hanno Böck: Immer mehr Lücken in Bash. In: Golem - IT-News für Profis. 27. September 2014, abgerufen am 27. September 2014.
  2. Bash-Lücke – Die Hintergründe zu Shellshock. Golem – IT-News für Profis, 24. September 2014, abgerufen am 26. September 2014.
  3. Vulnerability Summary for CVE-2014-6271. In: National Vulnerability Database. Department of Homeland Security, 24. September 2014, abgerufen am 26. September 2014 (englisch).
  4. The bash patch seems incomplete. Twitter, , abgerufen am 26. September 2014.
  5. Vulnerability Summary for CVE-2014-7169. In: National Vulnerability Database. Department of Homeland Security, 24. September 2014, abgerufen am 26. September 2014 (englisch).
  6. Non-upstream patches for bash. 25. September 2014, abgerufen am 27. September 2014 (englisch).
  7. Hanno Böck: Sicherheitslücke Shellshock gefährdet Server. In: Zeit Online. 25. September 2014, abgerufen am 26. September 2014.
  8. Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169). Abgerufen am 27. September 2014.
  9. SIP proxies vulnerable to Shellshock. Abgerufen am 29. September 2014.
  10. Dave Lee: Shellshock: 'Deadly serious' new vulnerability found. In: BBC. 25. September 2014, abgerufen am 26. September 2014 (englisch).
  11. Tom Fox-Brewster: What is the Shellshock bug? Is it worse than Heartbleed? In: The Guardian. 25. September 2014, abgerufen am 26. September 2014 (englisch).
  12. Florian Weimer: CVE-2014-6271: remote code execution through bash. In: Seclists.org. 24. September 2014, abgerufen am 26. September 2014 (englisch).
  13. Bash-Lücke: ShellShock ist noch nicht ausgestanden. In: Heise Online. 25. September 2014, abgerufen am 26. September 2014.
  14. Juli Clover: Apple Releases OS X Bash Update to Fix 'Shellshock' Security Flaw in Mavericks, Mountain Lion, and Lion. In: MacRumors.com. 29. September 2014, abgerufen am 2. Oktober 2014 (englisch): „Apple today released OS X bash update 1.0 for OS X Mavericks to fix a vulnerability in the bash UNIX shell.“
  15. Eric Slivka: Apple Releases OS X Yosemite Golden Master Candidate to Developers [Update: Also Public Beta]. In: MacRumors.com. 30. September 2014, abgerufen am 2. Oktober 2014 (englisch): „Both the developer and public beta releases include the fix for the "Shellshock" bash security flaw. Apple released fixes for OS X Mavericks, Mountain Lion, and Lion yesterday.“
  16. Bashing bash one more time: updated universal 4.3.26^W4.3.27^W4.3.28 covering all known bash flaws. In: http://www.floodgap.com/software/tenfourfox/. 3. Oktober 2014, abgerufen am 3. Oktober 2014 (englisch): „Bashing bash one more time.“
  17. Stefan Beiersmann: Shellshock: Neuer Patch für Bash-Lücke in Linux und OS X veröffentlicht. In: ZDNet. 29. September 2014, abgerufen am 2. Oktober 2014.
  18. Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169). 26. September 2014, abgerufen am 26. September 2014.