@dfncert@infosec.exchangeUpdate: 06.10.2014
Shellshock / GNU Bash / CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-7186, CVE-2014-7187, ...
Nachdem dieses Jahr bereits der Fehler in OpenSSL namens "Heartbleed" vielen Systemadministratoren Kopfzerbrechen und reichlich Arbeit beschert hat, kommt nun eine vermutlich noch schwerwiegendere Sicherheitslücke in der GNU-Bash-Shell ans Tageslicht. Aufgrund der hohen Verbreitung der GNU Bash und der Möglichkeit, beliebigen Programmcode aus der Ferne ohne Authentifizierung auszuführen, wurde die Sicherheitslücke CVE-2014-6271 entsprechend "Shellshock" getauft. Ein erster Patch zur Fehlerbehebung wurde nur kurze Zeit später als unzureichend erkannt, so dass eine weitere Identifizierung der verbliebenen Schwachstelle mit der National Vulnerability Database ID CVE-2014-7169 notwendig wurde. Für letztere Schwachstelle wurden von den meisten Linux-Distributionen bereits Patches bereitgestellt, die möglicherweise aber die Kompatibilität von bestehenden Shell-Skripten beeinträchtigen können. Nur wenige Tage später wurden weitere Probleme identifiziert, die unter den Bezeichnungen CVE-2014-6277, CVE-2014-6278, CVE-2014-7186, CVE-2014-7187 erfasst wurden und weitere Patches notwendig machen.
Die DFN-Anwender wurden von uns umgehend durch das Advisory DFN-CERT-2014-1258 über die Sicherheitslücken und die jeweils verfügbaren Sicherheitsupdates informiert.
Betroffene Systeme und Auswirkungen
Betroffen sind alle GNU-Bash-Versionen von der ersten Version von vor mehr als 20 Jahren bis zur aktuellen Version 4.3 Patch 025. Die GNU Bash ist weit verbreitet. Sie läuft auf Unix/Linux-Systemen, Mac OS und Windows. Auf vielen Unix/Linux-Systemen ist die GNU Bash die Standard-Shell. Vor allem Linux wird gerne als Plattform für Embedded-Systeme eingesetzt, so dass auch viele Appliances gefährdet sein dürften.
Ferner hat diese Sicherheitslücke weitreichende Auswirkungen auf Systeme, auf denen /bin/sh zu /bin/bash verlinkt ist. Dadurch wird andere Software, wie CGI-Skripte, Webapplikationen geschrieben in Sprachen wie PHP, Python, C++ oder Java; CUPS, (Open)SSH und SSH-"ForcedCommand"-Umgebungen, ..., welche Funktionen wie popen() oder system() benutzen, ebenfalls verwundbar für Angriffe über Umgebungvariablen, wie z.B. HTTP_*, durch welche im Fall von Serverprozessen eine Übernahme des kompletten Systems möglich wird.
Wie Heise unter der Überschrift "Bash-Lücke: ShellShock ist noch nicht ausgestanden" berichtet, wird diese Schwachstelle unter anderem bereits von Botnetzen ausgenutzt, um DDoS-Angriffe mittels einer "cgi-bin reverse shell" durchzuführen. Es ist zu erwarten, dass sich zahlreiche Hacker daran versuchen werden, noch weitere Fehler aufzuspüren.
Technische Details
Im Grunde besteht das Problem in einem wenig bekannten Feature, welches es Bash-Programmen erlaubt, bestimmte Funktionsdefinitionen in den Werten von Umgebungsvariablen von einer "Parent-Shell" zu einer "Child-Shell" zu exportieren, ähnlich wie dieses ebenfalls für normale Umgebungsvariablen möglich ist. Diese Funktionalität kann von einem entfernten Angreifer missbraucht werden, indem er beliebigen Programmcode hinter einer solchen Funktionsdefinition in einer Umgebungsvariablen einfügt. Beim Start der GNU Bash bis Version 4.3 bash43-025 wird dieser Programmcode ohne weitere Prüfungen ausgeführt.
Es konnte gezeigt werden, dass diese Sicherheitslücke das Ausführen beliebigen Programmcodes in der Bash über Privilegiengrenzen hinweg ermöglicht, z.B. ist dies möglich unter Verwendung des ForceCommand-Features in OpenSSH sshd, in mod_cgi- und in mod_cgid-Modulen im Apache-HTTP-Server, durch Skripte, die durch nicht spezifizierte DHCP-Clients gestartet werden, sowie in weiteren Situationen.
Dies liegt daran, dass Webserver, wie Apache-HTTP-Server, die Tendenz haben, beliebige Zeichenketten, welche von einem Client in der Umgebung übergeben werden, einfach an alle untergeordneten Binaries und Skripte weiterzugeben. D.h. wenn ein CGI- oder PHP-Skript auf einem Server aufgerufen wird, werden z.B die Umgebungsvariablen $HTTP_COOKIE und $HTTP_USER_AGENT höchstwahrscheinlich mit den Rohwerten des ursprünglichen Aufrufs initialisiert. Wenn diese Werte mit "() {" beginnen und von /bin/bash verarbeitet werden, kann es also relativ einfach dazu kommen, dass beliebige Befehle auf dem Webserver ausgeführt werden, indem diese im HTTP-Header durch beliebige Angreifer aus dem Internet übermittelt werden können.
Weitere Schwachstellen beruhen darauf, dass die verschiedenen Bash-Funktionsparser, welche aufgerufen werden, um Funktionsdefinitionen aus Variablen zu verarbeiten, nicht immer genügend robust sind, sondern die üblichen, aufgrund der Wiederverwendung alten Codes vielfältig auftretenden Fehler beim Parsen von C-Strings enthalten. Als derartige Schwachstellen wurden bereits CVE-2014-6277, CVE-2014-6278, CVE-2014-7186 und CVE-2014-7187 identifiziert und es werden vermutlich weitere hinzukommen.
Eine zweite Runde von Patches der verschiedenen Hersteller zielte deshalb darauf ab, die Bash der Gestalt zu härten, dass es für Angreifer grundsätzlich ausgeschlossen werden sollte, Umgebungsvariablen einzuschleusen, die als Funktionen geparst werden könnten, wodurch nicht nur CVE-2014-7169, sondern darüber hinaus die gesamte Klasse von Angriffen gegen den Bash-Parser effektiv verhindert werden sollte.
Hierfür wurde der Export von Funktionen derart verändert, dass dabei ein Prefix "BASH_FUNC_" und ein Suffix "()" verwendet wird. Ein solcher Patch sollte es Angreifern unmöglich machen, das Funktions-Parsing-Feature der Bash überhaupt auszunutzen. (Falls es einem Angreifer auf irgendeinem Wege möglich sein sollte, Umgebungsvariablen mit dem Namen „BASH_FUNC_x()“ einzuschleusen, könnte er ohnehin alle denkbaren Variablen einschleusen, wie z. B. PATH, PS1, LD_PRELOAD und andere.)
Weitere Informationen:
Maßnahmen für Betreiber
Wie sollen Betreiber von Serversystemen sich jetzt richtig verhalten? Wir empfehlen allen Betreibern von Webservern das folgende Vorgehen.
1) Prüfen auf Angreifbarkeit
Zunächst sollten Sie prüfen, ob Ihre Bash verwundbar ist. Dazu können Sie in einer Shell folgendes Kommando ausführen, um festzustellen, ob das systemweite GNU-Bash-Binary verwundbar gegenüber CVE-2014-6271 ist:
Wenn die Ausgabe des obigen Kommandos eine Zeile beinhaltet, welche das Wort "vulnerable" beinhaltet, handelt es sich um eine angreifbare Version der Bash. Der Patch, welcher Schwachstelle CVE-2014-6271 behebt, erlaubt keinen Code nach dem Ende der Bash-Funktion.
Die Bash-Versionen ohne diesen Fix (und ohne das Prefix "BASH_FUNC_" und das Suffix "()") erzeugen folgende Ausgabe:
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test
Eine andere Möglichkeit zu testen, ob Ihr System bereits auf diese Weise gehärtet und somit auch nicht mehr gegen CVE-2014-6277, CVE-2014-6278 sowie CVE-2014-7186, CVE-2014-7187 und CVE-2014-7169 verwundbar ist, besteht durch folgendes Kommando:
$ hello() { echo hello; } ; export -f hello ; env|grep hello
Folgende Ausgabe zeigt eine verwundbare Version der Bash an:
hello=() { echo hello
während folgende Ausgabe eine gehärtete Version der Bash anzeigt:
BASH_FUNC_hello()=() { echo hello
Um zu testen, ob die Bash gegenüber CVE-2014-7169 verwundbar ist, können Sie alternativ auch folgendes Kommando ausführen:
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014
Wenn das Datum wie oben ausgeben und die Datei /tmp/echo erzeugt wird, ist Ihr System verwundbar.
Wenn das Datum nicht ausgeben wird, ist Ihr System nicht verwundbar gegenüber CVE-2014-7169:
date
cat: /tmp/echo: No such file or directory
Weitere Informationen:
2) Beheben der Schwachstelle
Weitere Informationen z.B. unter:
Falls Sie von Ihrem Distributor noch keinen Patch erhalten konnten, bzw. für Ihre Distribution überhaupt keine Sicherheitsupdates zur Verfügung gestellt werden, können Sie alternativ folgende manuelle Vorgehensweise wählen:
Klonen Sie das aktuelle "git"-Repository von GNU Bash, welches die Patches bash43-025, bash43-026 (behebt den Yacc-Parsing-Fehler) und bash43-027 enthält:
git clone git://git.sv.gnu.org/bash.git
cd bash
./configure
make
Danach können Sie die Bash-Version mit folgendem Befehl feststellen:
$ ./bash --version
Die Ausgabe sollte "version 4.3.27" sein.
Im Folgenden sollten Sie testen, ob Ihr System wirklich nicht mehr verwundbar ist. Dazu führen Sie im GNU-Bash-Build-Verzeichnis folgenden Befehl aus:
$ env x='() { :;}; echo vulnerable' ./bash -c "echo test"
Wenn dieser Test erfolgreich war, können Sie die das existierende GNU-Bash-Binary austauschen. Dafür benötigen Sie die Option ‘-f’, weil die Datei in Verwendung ist:
$ sudo cp -f ./bash /bin/bash
Aktuell noch laufende Bash-Sessions müssen neu gestartet werden. Dieses kann mit “lsof” überprüft werden.
3) Weitere Maßnahmen
Zur Minimierung des Risikos wird ferner als "Best Practice" grundsätzlich empfohlen, starke ACLs zu implementieren, um den Netzwerkverkehr von und zur Managementschnittstelle zu kontrollieren.
Fazit und Ausblick
Was haben wir dazu gelernt? Historisch bedingt existieren noch heute - trotz aller inzwischen vorhandener Vielfalt an Betriebssystemen und Anwendungsimplementierungen - etliche, teilweise in ihrem Ursprung schon recht betagte Bibliotheken fort, welche aufgrund ihrer grundsätzlichen Funktionalität in fast allen Systemen enthalten sind, bzw. zum Teil sogar deren Basis darstellen. Wir alle vertrauen auf die Funktionalität und Sicherheit dieser Bibliotheken, sind sie doch aufgrund ihrer langjährigen Verwendung ausgereift und bewährt.
Ein Problem, welches sich unter anderem aus der langen Historie ergibt, besteht aber darin, dass manche Features, welche irgendwann einmal als nützlich eingebaut wurden, trotz der vielfältigen Verwendung als Ganzes, oft nurmehr einigen "Insidern" bekannt sind. Und leider erweisen sich die "Bad Guys" nur allzu häufig eher als "Insider" und äußerst erfindungsreich darin, Schwachstellen aufzuspüren, im Gegensatz zum zielorientierten Anwender, dem es vorrangig um die gewünschte Funktionalität geht.
Erschwerend kommt hinzu, dass es sich gerade bei derart zentralen Bibliotheken häufig um solche handelt, die unter Open Source eine lange Entwicklungsgeschichte haben, in die Input aus vielen verschiedenen Entwicklergruppen, Projekten und Unternehmen Eingang gefunden hat. An die verantwortlichen Projekte stellt dies hohe Herausforderungen hinsichtlich der funktionalen und sicherheitstechnischen Überprüfungen der verschiedenen Beiträge.
"Heartbleed" und aktuell "ShellShock" zeigen uns, dass wir uns keinesfalls auf optimistische Annahmen bezüglich "Altbewährtem" verlassen dürfen. Vielmehr müssen wir immer wieder aufs Neue überdenken, prüfen und testen, was wir von einem bestimmten System, einer Software, einer Bibliothek erwarten können, welche Features gewünscht und aus welchen eventuell unbemerkt über die Zeit ein Risiko erwachsen könnte.
Wie seinerzeit bereits bemerkt, bleibt uns wohl keine andere Wahl, als uns dem "Rüstungswettlauf" mit der "dunklen Seite der Macht" zu stellen. Dabei müssen wir stetig unser Bewusstsein für die möglichen Risiken schärfen, Informationen über Gefahren, präventiven und schadensbegrenzenden Abwehrmaßnahmen beachten, bewerten sowie zügig und effizient umsetzen. Um in diesem Wettlauf Schritt zu halten, hilft uns eine enge Vernetzung von Herstellern, CERTs und anderen Organisationen, national wie international, sowie Anwendern und Nutzern.
