Shellshock (Sicherheitslücke)

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Vom Fedora Magazine verwendetes Logo für Shellshock

Shellshock ist eine Sicherheitslücke – oder eine Familie von Sicherheitslücken, CVE-Nummern CVE-2014-6271,[1] …-7169, -7186, -7187, -6277,[2] -6278[3] – in der Unix-Shell Bash. In der Bash kann der Wert einer Zeichenkettenvariablen eine Funktionsdefinition enthalten. Durch die Sicherheitslücke kann nach der Auswertung einer solchen Variablen ungeprüft Programmcode ausgeführt werden.[4] Die erste Entdeckung (CVE-2014-6271) wurde am 24. September 2014 öffentlich gemacht.[5] In der vom NIST verwendeten Bewertung des Schadenpotentials erhält sie eine Bewertung von 10, dem Maximum.[1] Am selben Tag wurde ein erster Patch veröffentlicht, jedoch fanden Sicherheitsexperten von Google Inc. und Red Hat (Tavis Ormandy, Michał Zalewski, Florian Weimer) bald ähnliche Lücken, die eigene CVE-Nummern erhielten und den ersten Patch „überlebten“.[6][2] Inzwischen (Stand 3. November 2014) gibt es offenbar keine Beanstandung der vorliegenden Patches mehr,[7][8] die letzte Fehlervariante wurde von NIST am 30. September 2014 veröffentlicht.[3]

Problematik

[Bearbeiten | Quelltext bearbeiten]

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

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 beliebigem Code genutzt werden.
  • Mit SIP (Session Initiation Protocol) arbeitende Proxys können für Shellshock anfällig sein.[11]
  • Die IBM Hardware Management Console, eine rudimentäre Linuxvariante für Administratoren von IBM-Systemen, erlaubt das „Ausbrechen“ aus der „restricted shell“, um die Bash aufzurufen, danach hat man volle Kontrolle über das System.[12][13][14]

Weltweit sollen hunderte Millionen von Computern betroffen sein.[15] Die Sicherheitslücke wird von Forschern für gravierender als der Heartbleed-Bug gehalten.[16] Shellshock wurde von Stéphane Chazelas entdeckt und existiert seit 1989 in Bash.[17][9]

Am 6. Oktober wurde verbreitet, Server von Yahoo, WinZip und Lycos seien von Shellshock betroffen gewesen. Jonathan Hall verschaffte sich Zugriff auf die Server von Winzip, auf denen er Schadsoftware fand, die eine Verbindung zu Servern von Yahoo und Lycos aufbaute. Tags darauf wurde dies relativiert, insbesondere hinsichtlich der Aussage, für die behauptete Angreifbarkeit sei Shellshock ursächlich gewesen.[18]

Prüfung auf Verwundbarkeit

[Bearbeiten | Quelltext bearbeiten]

Bash-Version

[Bearbeiten | Quelltext bearbeiten]

Die Verwundbarkeit der Shell (durch die erste Fehlervariante CVE-2014-6271) lässt sich durch die folgende Eingabe auf der Kommandozeile testen.[8] 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 (die zweite Fehlervariante) CVE-2014-7169 hat, testet die Folge 

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

Bei einer verwundbaren Shell sieht man einen Zeitstempel als Ausgabe: 

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

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

date
cat: echo: Datei oder Verzeichnis nicht gefunden

Server

[Bearbeiten | Quelltext bearbeiten]

Um zu prüfen, ob ein Server z. B. über CGI-Skripte bereits angegriffen wurde, sucht man Mustereinträge – etwa in Form der Zeichenkette „};“ – wie in folgendem Beispiel („0.0.0.0“ steht für eine IP-Adresse): 

0.0.0.0 - - [29/Sep/2014:09:12:11 +0300] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 2311 "-" "() { :;'''};''' /bin/ping -c 1 0.0.0.0"

Technischer Hintergrund

[Bearbeiten | Quelltext bearbeiten]

Bash ermöglicht es Variablen und Funktionen zu definieren, die in der jeweiligen Bash-Instanz bzw. innerhalb des aktuellen Bash-Skripts verwendet werden können. Außerdem kann eine Bash-Instanz, wenn sie eine andere Bash-Instanz „kreiert“ (als Kindprozess aufruft), letzterer sowohl Variablen als auch Funktionen „vererben“. Dazu muss dem Namen der Variablen oder Funktion etwa das Schlüsselwort export vorangestellt werden (oder env für environment beim Aufruf).

Das Exportieren von Variablen und Funktionen erfolgt über Umgebungsvariablen. Da Umgebungsvariablen nur einfache Schlüssel-Wert-Paare erfassen können (Schlüssel: Variablenname, Wert: Variablenwert), müssen Funktionen beim Exportieren als String (Zeichenkette) kodiert werden. Bash verwendet für Funktions-Definitionen spezielle Umgebungsvariablen. Deren Inhalt beginnt mit der Zeichenfolge „()“. Bash prüft nach dem Start jede vorhandene Umgebungsvariable nach Funktions-Definitionen. Für jede gefundene Funktions-Definition wird automatisch eine entsprechende Funktion in der aktuellen Bash-Instanz angelegt.

Der Bug 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 – selbst dann, wenn die entsprechende Funktion nie aufgerufen wird. Ein Angreifer muss nur Umgebungsvariablen setzen können, 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

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

Die erste Befehlszeile unter Prüfung auf Verwundbarkeit oben 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 startet den angefügten Befehl ungeprüft und gibt den Text shellshockverwundbar auf der Konsole aus.
Ein potentieller Angreifer kann auf gleiche Weise beliebige Befehle von Bash ausführen lassen.

Zeitliche Abfolge der Fehlervarianten

[Bearbeiten | Quelltext bearbeiten]
exakte Abfolge CVE-Kennzeichen Entdecker Ankündigung (2014) NIST-Veröffentlichung (2014) Bash-Patch-Kennzeichen
1. CVE-2014-6271 Stéphane Chazelas 12. September[19] 24. September[1] bash43-025[20]
2. CVE-2014-7169 Tavis Ormandy 24. September[21] 24. September[6] bash43-026[22]
3. CVE-2014-7186 Todd Sabin, Florian Weimer[23] 25. September[24]  28. September[25] bash43-027[26]
4. CVE-2014-7187 Florian Weimer 27. September[27]  28. September[28]
5. CVE-2014-6277 Michał Zalewski    27. September[2][27]  27. September[29]
6. CVE-2014-6278 Michał Zalewski 29. September[30] 30. September[3] 

Die Fehlervarianten beziehen sich auf unterschiedliche Patch-Versionen von Bash 4.3:

  • CVE-2014-6271 (12. bis 24. September) ist eine Anfälligkeit von Bash 4.3 in der Patch-Version bash43-024.
  • CVE-2014-7169 (24. September) ist eine Anfälligkeit von Bash 4.3 in der Patch-Version bash43-025 (und bash43-024).[6]
  • Die übrigen Varianten mit NIST-Veröffentlichung ab dem 27. September sind Anfälligkeiten von Bash 4.3 in der Patch-Version bash43-026 (und älter).

Die in der Tabelle angegebenen Patches des Maintainers Chet Ramey waren direkt und explizit als Patches der in der jeweiligen Zeile genannten Fehler gedacht.

Anhand der Entdeckernamen können die Anfälligkeiten in E-Mails/Postings/Artikeln identifiziert werden, die dem Eintrag in die National Vulnerability Database des NIST mit Zuteilung eines Kennzeichens vorhergingen.

Patches

[Bearbeiten | Quelltext bearbeiten]

Quellcode

[Bearbeiten | Quelltext bearbeiten]

Der Maintainer von Bash, Chet Ramey, verschickte zunächst eine Patchversion bash43-025 zu Bash-Version 4.3 CVE-2014-6271,[20] um Distributionen bis zum Zeitpunkt der Veröffentlichung der Lücke am 24. September zu versorgen. Zu CVE-2014-7169 folgte am selben Tag bash43-026.[22][27] Zu CVE-2014-7186 vom folgenden Tag postete Florian Weimer von Red Hat zunächst „privat“ einen Patch,[31] den Ramey als bash43-027 übernahm.[26][32][27] Damit war denen geholfen, die mit den übrigen Quellcodedateien eine neue ausführbare Binärdatei von Bash zu kompilieren in der Lage waren.

Linux

[Bearbeiten | Quelltext bearbeiten]

Von Freitag bis Sonntag nach der Veröffentlichung von bash43-027 erschienen Updates – neue Pakete, Anleitungen, Hinweise – für Linuxdistributionen wie Red Hat Enterprise Linux (kommerziell),[33] Fedora 21 (freies Red-Hat-Linux),[34] die Long-Term-Support-Versionen von Ubuntu[35] und für SUSE Linux Enterprise.[36]

Nutzer der regelmäßigen automatischen Aktualisierungsbenachrichtigung ihrer Distribution haben eine reparierte Bash mehr oder weniger automatisch erhalten. Andernfalls kann spezifisch das Bash-Paket aktualisiert werden.

Mac

[Bearbeiten | Quelltext bearbeiten]

OS X 10.7–10.10

[Bearbeiten | Quelltext bearbeiten]

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 öffentlichen Beta-Version 4 einen Tag später ebenfalls abgesichert und verhindert die unbefugte Ausführung von Schadcode.[37][38]

Ältere Versionen

[Bearbeiten | Quelltext bearbeiten]

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

IBM

[Bearbeiten | Quelltext bearbeiten]

IBM bietet einen Patch für seine Hardware Management Console an, der alle sechs im September 2014 entdeckten Lücken schließt.[13]

„Nachhaltigkeit“

[Bearbeiten | Quelltext bearbeiten]

Noch nach Veröffentlichung der auf bash43-027 beruhenden Updates wurden weitere Shellshock-Varianten entdeckt bzw. veröffentlicht, zuletzt CVE-2014-6278 am 29. bzw. 30. September durch Michał Zalewski von Google Inc.[40][3] Am 1. Oktober 2014 erklärte Zalewski jedoch (neben seinen Funden), dass Florian Weimers Patch vom 25. September, der in bash43-027 einging, auch die später gefundenen Lücken schließe.[7]

[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ a b c Vulnerability Summary for CVE-2014-6271. In: National Vulnerability Database. NIST, 31. Oktober 2014, abgerufen am 2. November 2014 (englisch).
  2. ↑ a b c Hanno Böck: Immer mehr Lücken in Bash. In: Golem – IT-News für Profis. 27. September 2014, abgerufen am 27. September 2014.
  3. ↑ a b c d Vulnerability Summary for CVE-2014-6278. In: National Vulnerability Database. NIST, 31. Oktober 2014, abgerufen am 2. November 2014 (englisch).
  4. ↑ Bash-Lücke – Die Hintergründe zu Shellshock. In: Golem – IT-News für Profis. 24. September 2014, abgerufen am 26. September 2014.
  5. ↑ Florian Weimer: oss-sec: Re: CVE-2014-6271: remote code execution through bash. In: Seclists.org. 24. September 2014, abgerufen am 1. November 2014.
  6. ↑ a b c Vulnerability Summary for CVE-2014-7169. In: National Vulnerability Database. NIST, 31. Oktober 2014, abgerufen am 2. November 2014 (englisch).
  7. ↑ a b Michał Zalewski: Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78). In: lcamtuf blog. 1. Oktober 2014, abgerufen am 31. Oktober 2014 (englisch).
  8. ↑ a b c Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169). Red Hat, 2. Oktober 2014, abgerufen am 1. November 2014 (englisch).
  9. ↑ a b Stéphane Chazelas, Chet Ramey: when was shellshock introduced. In: Gmane. 10. Oktober 2014, archiviert vom Original (nicht mehr online verfügbar) am 20. Dezember 2016; abgerufen am 1. November 2014.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/thread.gmane.org
  10. ↑ Hanno Böck: Sicherheitslücke Shellshock gefährdet Server. In: Zeit Online. 25. September 2014, abgerufen am 26. September 2014.
  11. ↑ Lefteris Zafiris: sipshock – A scanner for SIP proxies vulnerable to Shellshock. In: GitHub. Abgerufen am 29. September 2014 (englisch).
  12. ↑ shellshock.png – Brian Smith auf IBM.com, abgerufen am 3. November 2014 (englisch).
  13. ↑ a b Security Bulletin: Vulnerabilities in Bash affect DS8000 HMC (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278). IBM, 3. Oktober 2014, abgerufen am 1. November 2014 (englisch).
  14. ↑ Shellshock (software bug) in der englischsprachigen Wikipedia.
  15. ↑ Dave Lee: Shellshock: 'Deadly serious’ new vulnerability found. In: BBC. 25. September 2014, abgerufen am 26. September 2014 (englisch).
  16. ↑ 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).
  17. ↑ Florian Weimer: CVE-2014-6271: remote code execution through bash. In: Seclists.org. 24. September 2014, abgerufen am 26. September 2014 (englisch).
  18. ↑ Hanno Böck: Yahoo durch Shellshock angegriffen. In: Golem – IT-News für Profis. 7. Oktober 2014, abgerufen am 30. Oktober 2014.
  19. ↑ Nicole Perlroth: Security Experts Expect ‘Shellshock’ Software Bug in Bash to Be Significant. In: New York Times. 25. September 2014, abgerufen am 1. November 2014 (englisch).
  20. ↑ a b BASH PATCH REPORT. In: GNU.org. 12. September 2014, abgerufen am 2. November 2014 (englisch).
  21. ↑ Tavis Ormandy: The bash patch seems incomplete. Twitter, 24. September 2014, abgerufen am 1. November 2014 (englisch).
  22. ↑ a b BASH PATCH REPORT. In: GNU.org. 25. September 2014, abgerufen am 2. November 2014 (englisch).
  23. ↑ Florian Weimer: Non-upstream patches for bash. In: Seclists.org. 25. September 2014, abgerufen am 3. November 2014 (englisch).
  24. ↑ Florian Weimer: Re: CVE-2014-6271: remote code execution through bash. In: Openwall Project. 25. September 2014, abgerufen am 2. November 2014 (englisch).
  25. ↑ Vulnerability Summary for CVE-2014-7186. In: National Vulnerability Database. NIST, 31. Oktober 2014, abgerufen am 2. November 2014 (englisch).
  26. ↑ a b BASH PATCH REPORT. In: GNU.org. 25. September 2014, abgerufen am 2. November 2014 (englisch).
  27. ↑ a b c d Michał Zalewski: Bash bug: apply Florian’s patch now (CVE-2014-6277 and CVE-2014-6278). In: lcamtuf blog. 27. September 2014, abgerufen am 3. November 2014 (englisch).
  28. ↑ Vulnerability Summary for CVE-2014-7187. In: National Vulnerability Database. NIST, 31. Oktober 2014, abgerufen am 2. November 2014 (englisch).
  29. ↑ Vulnerability Summary for CVE-2014-6277. In: National Vulnerability Database. NIST, 31. Oktober 2014, abgerufen am 2. November 2014 (englisch).
  30. ↑ Hanno Böck: Immer mehr Lücken in Bash. In: Golem – IT-News für Profis. 29. September 2014, abgerufen am 3. November 2014. (Nachtrag)
  31. ↑ Florian Weimer: Re: CVE-2014-6271: remote code execution through bash. In: Openwall Project. 25. September 2014, abgerufen am 2. November 2014 (englisch).
  32. ↑ Sean Gallagher: New “Shellshock” patch rushed out to resolve gaps in first fix [Updated]. 26. September 2014, abgerufen am 2. November 2014 (englisch).
  33. ↑ Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169). Red Hat, 2. Oktober 2014, abgerufen am 2. November 2014 (englisch).
  34. ↑ Fedora 21 Update: bash-4.3.25-2.fc21. Fedora Project, 27. September 2014, abgerufen am 2. November 2014 (englisch).
  35. ↑ USN-2364-1: Bash vulnerabilities. Canonical Ltd., 27. September 2014, abgerufen am 2. November 2014 (englisch).
  36. ↑ SUSE Security Update: Security update for bash. OpenSUSE, 28. September 2014, abgerufen am 2. November 2014 (englisch).
  37. ↑ 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.“
  38. ↑ 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.“
  39. ↑ TenFourFox Development: Bashing bash one more time: updated universal 4.3.26^W4.3.27^W4.3.28 covering all known bash flaws. 5. Oktober 2014, abgerufen am 1. November 2014 (englisch): „Bashing bash one more time.“
  40. ↑ Juha Saarinen: Further flaws render Shellshock patch ineffective. In: itnews.com.au. 29. September 2014, abgerufen am 2. November 2014.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Shellshock_(Sicherheitslücke)&oldid=248236640“