Die Entwickler von Red Hat Linux sind auf eine schwerwiegende Sicherheitslücke in der Bash-Shell von Linux aufmerksam geworden, die angeblich eine noch größere Gefahr darstellen könnte als der vor einigen Monaten aufgetauchte sogenannte Heartbleed-Bug.

Wie die Entwickler in ihrem Sicherheits-Blog verlauten ließen, gibt es eine unauffällige aber höchst gefährliche Schwachstelle in der Bash-Shell, bei der es sich um eines der meistgenutzten Werkzeuge unter Linux handelt. Die Lücke wird als "Bash-Bug" oder "Shellshock" bezeichnet und erlaubt einem Angreifer im Grunde die Ausführung beliebigen Codes, sobald die Bash-Shell auch nur aufgerufen wird. Daraus ergibt sich dem Vernehmen nach eine breite Angriffsfläche für eine Vielzahl von Attacken.

Der Fehler besteht offenbar schon seit langer Zeit und ist vor allem mit Blick auf kommerziell genutzte Linux-Systeme problematisch. Neben Linux ist auch Mac OS X mit seiner Unix-Basis betroffen, denn auch hier ist die Bash-Shell mit an Bord. Red Hat und Fedora haben bereits Patches herausgegeben, die die Schwachstelle bei ihren Linux-Varianten beseitigen sollen.

Im Fall von Mac OS X gibt es zwar noch keinen offiziellen Patch gegen das Problem, doch erfahrene Anwender können den Fehler selbst beseitigen, indem Bash neu kompiliert wird. Eine entsprechende Anleitung wurde bei StackExchange veröffentlicht, sollte aber nur von Nutzern umgesetzt werden, die auch wissen was sie tun.

Der Sicherheitsexperte Robert Graham von Errata Security geht davon aus, dass der Bash-Bug "wahrscheinlich ein größeres Problem als Heartbleed" darstellt, wie er über Twitter verlauten ließ. In einem Blog-Eintrag erklärte er, dass ein Großteil der Linux-Software mit der Shell interagiert, so dass es praktisch unmöglich sein werde, jede Software zu katalogisieren, die dadurch verwundbar geworden ist. Ähnlicher Meinung sind auch diverse andere Sicherheitsexperten, die davon ausgehen, dass der Fehler noch jahrelang negative Auswirkungen haben wird.

Quelle: [url=http://winfuture.de/news,83778.html]'Schlimmer als Heartbleed': Große Gefahr durch neue Linux-Lücke - WinFuture.de[/url]

Inzwischen wird die Bash-Sicherheitslücke Shellshock zur Verbreitung von Malware ausgenutzt. Die erste Korrektur war offenbar unvollständig. Wir haben die wichtigsten Hintergründe zu Shellshock zusammengefasst.

Sie hatte zwar zunächst keinen eingängigen Namen und kein Logo, aber die jüngste Sicherheitslücke in der Kommandozeile Bash ist nach Ansicht vieler Fachleute ebenso dramatisch einzuschätzen wie der inzwischen berühmte Heartbleed-Bug. Inzwischen wird sie fast überall als Shellshock bezeichnet, ihre offizielle ID ist CVE-2014-6271, in der CVE-Datenbank des NIST wurde die Lücke mit der maximalen Gefährlichkeit von zehn Punkten eingestuft.

Kern des Problems ist eine Funktionalität von Bash, bei der in beliebigen Variablen direkt Funktionen definiert werden können. Dabei ist es egal, wie die Variable heißt. Der entdeckte Fehler führt dazu, dass hinter einer solchen Funktionsdefinition weiterer Code ungeprüft ausgeführt wird, auch dann, wenn die entsprechende Funktion überhaupt nicht aufgerufen wird.

Das führt weiterhin dazu, dass das Ausnutzen der Sicherheitslücke extrem einfach ist. Bei verwundbaren Webanwendungen würde hierfür ein simpler Aufruf von Curl oder Wget mit geeigneten Parametern ausreichen.

Selbst 20 Jahre alte Versionen betroffen
Der Fehler steckt schon seit über 20 Jahren im Bash-Code. Der momentane Hauptautor von Bash, Chet Ramey, hat Patches für diverse alte Bash-Versionen veröffentlicht, auf Nachfrage sogar für die uralte Version 2.05b. Bash wird unter den meisten Linux-Systemen und unter MacOS X als Standardshell verwendet. Die meisten BSD-Derivate nutzen andere Shells, die nicht betroffen sind. Doch auch dort ist Bash meist installiert, und es ist denkbar, dass einzelne Programme oder Skripte Bash nutzen. Debian nutzt Bash zwar als Standardshell für Nutzer, Skripte werden aber mit Dash ausgeführt, so dass Angriffe ebenfalls sehr unwahrscheinlich sind.

Die Möglichkeiten, diese Sicherheitslücke auszunutzen, sind vielfältig. Eine Analyse von RedHat listet bereits vier verschiedene Szenarien auf, in denen Shellshock zum Problem werden kann. Das größte Problem stellen CGI-Skripte auf Webservern dar. Dabei gibt es verschiedene Szenarien, in denen Bash aufgerufen werden kann. Zum einen gibt es CGI-Skripte, die direkt in Bash geschrieben sind. Zum anderen rufen verschiedene Programmiersprachen bei Systemaufrufen Bash auf.

Das zweite gefährliche Szenario sind SSH-Shells, die auf bestimmte Befehle beschränkt sind. Das nutzen vor allem Git- und CVS-Server, mittels Shellshock lassen sich derartige Begrenzungen aushebeln. Ein weiteres Szenario, das auch für Clientrechner zum Problem werden könnte: Manche DHCP-Clients rufen Bash auf und setzen dabei Variablen, die sich vom DHCP-Server kontrollieren lassen. Weiterhin kann auch der Druckerdaemon CUPS als Angriffsvektor dienen. Die Liste ist mit hoher Wahrscheinlichkeit unvollständig, es ist auf jeden Fall damit zu rechnen, dass weitere Angriffsmöglichkeiten entdeckt werden.

Ein Metasploit-Modul erlaubt bei VMWare Fusion unter Mac OS X das ausbrechen aus einer virtuellen Maschine. Die Webinterfaces der BIG-IP-Loadbalancer der Firma F5 sind offenbar ebenfalls verwundbar.

Nicht betroffen sind andere Shells. Vielfach waren Nutzer verwirrt, weil sie den in vielen Artikeln bereitgestellten Testcode ausführten und eine Meldung über eine Verwundbarkeit auch unter anderen Shells wie Dash, ZSH oder Busybox erhielten. Doch der Testcode selbst ruft Bash auf und löst erst dort die Sicherheitslücke aus. Es ist egal, aus welcher Shell man diesen aufruft.

Dass andere Shells nicht betroffen sind, dürfte viele Embedded-Geräte retten. Zwar kommt auf Routern und vielen anderen Geräten oft Linux zum Einsatz, hier werden aber meistens ressourcenschonendere Shells als Bash verwendet.

Doppelte Sicherheitslücke
Wenige Stunden nach den ersten Berichten über die Sicherheitslücke postete der Google-Entwickler Tavis Ormandy auf Twitter einen Beispielcode, der auch den Funktionsparser der korrigierten Bash-Version zu verwirren schien. Zwar gelang es Ormandy nicht, dies für eine Sicherheitslücke auszunutzen, trotzdem war offensichtlich, dass das Problem nur unvollständig behoben war. Inzwischen wurde auf der Mailingliste oss-security ein experimenteller Patch gepostet. Ein offizielles Bash-Update gibt es noch nicht, einige Linux-Distributionen liefern aber bereits Pakete mit dem experimentellen Patch aus. Diese erneute Lücke hat inzwischen die ID CVE-2014-7169 erhalten.

Das Vorhandensein der Möglichkeit, bei dem Funktionen direkt in Variablen definiert werden können, finden viele generell problematisch. Allerdings gibt es wohl zahlreiche Bash-Skripte, die die entsprechende Funktion nutzen. Würde man es komplett entfernen, würden wohl einige ältere Skripte nicht mehr funktionieren. Andreas Bogk hat einen Patch erstellt, der die komplette Funktionalität aus Bash entfernt.

Erste Malware aufgetaucht
Auf Github wurden heute Teile eines Logfiles veröffentlicht, die offensichtlich den Versuch eines Angriffs darstellen. Ein HTTP-Request setzte die Cookie-Variable, die Host-Variable und die Referrer-Variable auf einen Exploit-Code zur Ausnutzung von Shellshock. Der Code lädt per wget eine Datei von einem Server herunter und führt diese aus. Die Datei hat den Namen nginx, es handelt sich aber nur um eine Tarnung, mit dem Webserver nginx hat sie nichts zu tun. Es handelt sich dabei um eine Malware, die anschließend versucht, weitere Server mit Sicherheitslücken in Telnet oder Busybox zu finden. Bisher erkennen nur wenige Antiviren-Programme diese Malware. Der Server, der die Malware ausliefert, war zum Zeitpunkt dieses Artikels nach wie vor online.

Ein weiterer Angriff versucht offenbar ein Perlskript, welches als Shellbot.B bekannt ist, mit dem Dateinamen "jur" zu installieren.

In den Logfiles von Webservern findet man inzwischen verschiedene Versuche, die Lücke auszunutzen, die meisten sind aber nur Tests. Einen größeren Scan hat der Sicherheitsforscher Robert Graham durchgeführt. Beim ersten Scan fand Graham nur 3.000 verwundbare Hosts, doch das hing wohl mit einem Fehler in seinem Scanscript zusammen.

Serveradministratoren können ihre Logs nach derartigen Einträgen durchsuchen, typisch ist die Zeichenkette "};", die in fast allen Beispielcodes enthalten ist und sonst in Webserver-Logs üblicherweise nicht auftaucht. Ein typischer Logeintrag, der versucht, die Sicherheitslücke testweise auszunutzen, sieht beispielsweise so aus (die IP-Adressen von Host und Ziel wurden entfernt):

0.0.0.0 - - [25/Sep/2014:11:32:29 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 1689 "-" "() { :;}; /bin/ping -c 1 0.0.0.0"

Testen
Ob man von der ursprünglichen Sicherheitslücke betroffen ist, lässt sich mit einem einfachen Befehl testen:

test="() { echo Hello; }; echo gehackt" bash -c ""

Wird anschließend der String "gehackt" ausgegeben, ist man betroffen. Ein Beispiel, um zu testen, ob man nur den unvollständigen ersten Fix erhalten hat, ist folgender Bash-Code:

X='() { function a a>\' bash -c echo; [ -e echo ] && echo "gehackt"

Es gibt inzwischen auch verschiedene Tools, um über das Netz zu prüfen, ob eine Webseite betroffen ist. Diese sind allerdings meist nicht zuverlässig, da theoretisch jede einzelne Datei auf dem Server betroffen sein könnte und es zahlreiche verschiedene Variablen gibt, in denen man Code unterbringen kann. Das Testen von fremden Servern ist möglicherweise illegal, da man in dem Fall Code auf fremden Servern ausführt.

Das Internet brennt
Es ist wohl nur Zufall, dass fast zeitgleich zu Shellshock eine bösartige Lücke in der RSA-Verifizierung von Firefox und Chrome entdeckt und die Webseite von jQuery zweimal hintereinander gehackt wurde. Doch die Häufung der Ereignisse wirft gewiss ein bezeichnendes Bild auf den allgemeinen Zustand der IT-Sicherheit. Für weitere Spekulationen sorgte eine Ankündigung von Amazon, sämtliche EC2-Server zu rebooten. Manche vermuten, dass der Hintergrund eine weitere, noch nicht bekannte gravierende Sicherheitslücke ist - möglicherweise im Linux-Kernel.

Nachtrag vom 26. September 2014, 11:49 Uhr
Entwickler von Redhat haben inzwischen zwei weitere mögliche Sicherheitslücken im Funktionsparser von Bash gefunden. Es handelt sich dabei um Zugriffe auf falsche Speicherbereiche, die die IDs CVE-2014-7186 und CVE-2014-7187 erhalten haben. Wie gravierend diese neuen Lücken sind, und ob sie sich leicht ausnutzen lassen, ist im Moment schwer abschätzbar. Patches sind von Redhat auf der Mailingliste oss-security gepostet worden.

Quelle: Bash-Lücke: Die Hintergründe zu Shellshock - Golem.de

Nach der kritischen ShellShock-Lücke in der Bash sind weitere damit verwandte Lücken bekannt geworden. Details und Korrekturen zu einer von ihnen stehen noch aus; sie soll mit ziemlicher Sicherheit aus der Ferne ausnutzbar sein.

Die Unix-Shell Bash, die vielen Linux-Distributionen und Mac OS beiliegt, hat noch einige Probleme mehr, als am Freitag bekannt war. Sie wurden gefunden, nachdem die Entwickler vor einigen Tagen eine kritische Lücke aufgetan haben; durch sie führen Webserver unter gewissen Umständen Code aus, den sie über das Netz erhalten. Parallel zur Veröffentlichung dieser als "ShellShock" bekannten Lücke am Mittwoch haben die großen Linux-Distributoren aktualisierte Bash-Versionen herausgegeben, um das Problem zu beseitigen. Sicherheitsexperten fanden aber einen weiteren Ausnutzweg; diesen stopfen die Distributoren seit Donnerstagabend mit einer zweiten Welle von Bash-Updates.

Diesen beiden Lücken werden als CVE-2014-6271 und CVE-2014-7169 geführt. Auch die drei weiteren haben bereits CVE-Einträge, die derzeit allerdings keine Details enthalten.

Lücken drei und vier
Bei zwei davon handelt es sich um Off-by-One-Fehler im Parser-Code, wie der bei Google arbeitende Sicherheitsexperte Michal Zalewski in einem Blog-Eintrag erklärt. Der auch als "lcamtuf" bekannte Google-Mitarbeiter empfiehlt Distributoren, einen Patch von Red-Hat-Mitarbeiter Florian Weimer einzuspielen, der diese als CVE-2014-7186 und CVE-2014-7187 geführten Probleme beseitigt. Bei Red Hat Enterprise Linux (RHEL) steckt diese Änderung schon in den am Freitag veröffentlichten Bash-Updates. Auch Fedora behebt dieses beiden Fehler, obwohl die Freigabe-Mail es nicht ausweist. Ubuntu beseitigt diese beiden Lücken durch ein am Samstag erschienenes Update – bei einigen Canonical-Distributionen ist es bereits das vierte Bash-Sicherheitsupdate innerhalb von einer Woche.

Nummer 5
Möglicherweise folgt bald das fünfte, denn bei der Beschreibung der Hintergründe erklärt Zalewski, er habe noch einen weiteren Fehler gefunden. Er erklärt dazu, dieser als CVE-2014-6277 geführte Fehler sei mit ziemlicher Sicherheit aus der Ferne ausnutzbar; dabei spiele Angreifern in die Hände, dass die Bash häufig nicht für Address Space Layout Randomization (ASLR) compiliert sei. Abgesehen von einer Fehlermeldung nennt er keine weiteren Details, da er den Fehler vorerst nur mit dem Bash-Hauptentwickler und den wichtigsten Linux-Distributoren diskutiert. In dem Zusammenhang ruft Zalewski abermals mit deutlichen Worten dazu auf, die Patches von Florian Weimer einzuspielen.

Quelle: ShellShock, Teil 3: Noch drei Sicherheitsprobleme bei der Bash | heise online