Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung & Design

Na endlich: Apple reagiert auf Shellshock und veröffentlicht Patch [Update]

    Na endlich: Apple reagiert auf Shellshock und veröffentlicht Patch [Update]

Shellshock Bash-Bug-Exploit. (Grafik: Instacode)

Endlich reagiert auch Apple auf die Sicherheitslücke in dem freien Unix-Shell Bash und veröffentlicht einen Patch. Der Shellshock getaufte Bug erlaubt die Ausführung von potenziell schadhaftem Code unter Linux, Unix und OS X.

Update vom 30. September 2014: Nachdem sich die großen Linux-Distributionen schon kurz nach Bekanntwerden des Bugs um die Sicherheitslücke gekümmert haben, hat jetzt auch Apple reagiert und bietet einen Patch an. OS-X-Nutzer sollten sich das Bash-Update unbedingt herunterladen.
Bash: Der Shellshock-Bug wird uns noch lange begleiten. (Grafik: Instacode)
Bash: Der Shellshock-Bug wird uns noch lange begleiten. (Grafik: Instacode)

Shellshock: Was ihr über die Sicherheitslücke in Bash wissen müsst

Der französische Entwickler Stephane Chazelas hat eine Sicherheitslücke in Bash entdeckt. Mit dem mittlerweile Shellshock getauften Bug lässt sich Schadcode aus der Ferne ausführen. Bash ist die Standard-Shell auf den meisten Unix-Betriebssystemen und wird bei fast allen Linux-Distributionen und BSD-Varianten eingesetzt. Auch das auf BSD basierende OS X von Apple ist betroffen.

Mittels Shellshock kann in Umgebungsvariablen Code eingefügt werden, der beim Start einer neuen Shell ungehindert ausgeführt wird. Da Bash auf Unix- und Unix-ähnlichen-Systemen in unzähligen Situationen genutzt wird, gibt es eine potenziell kaum überschaubare Anzahl an Angriffsmöglichkeiten. Auf Webservern rufen CGI-Scripts beispielsweise Bash auf. Schon jetzt findet sich im Netz Beispielcode, um über CGI-Scripts, die auf Bash zugreifen, Code auf einem betroffenen Server auszuführen.

Shellshock: Auch OS X ist von Bash-Bug betroffen. (Screenshot: OS X)
Shellshock: Auch OS X ist von Bash-Bug betroffen. (Screenshot: OS X)

Shellshock: Bin ich betroffen und was mache ich dagegen?

Um heraufzufinden, ob euer System betroffen ist, müsst ihr den folgenden Code in die Kommandozeile eingeben:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Ein betroffenes System wird diese Antwort ausgeben:

vulnerable

 this is a test

Einen offiziellen Patch bieten die Macher der folgenden Linux-Distributionen an:

Schlimmer als Heartbleed: Warum uns Shellshock noch über Jahre begleiten wird

Heartbleed war ein Disaster, betraf aber letztlich nur bestimmte OpenSSL-Versionen. Der Shellshock-Bug existiert in seiner jetzigen Form allem Anschein nach bereits seit einer sehr langen Zeit. Daher dürften unzählige Systeme auf der ganzen Welt davon betroffen sein. Wie der Sicherheitsexperte Robert Graham auf seinem Blog bemerkt, könnten vor allem die unzähligen Internet-of-Things-Geräte auf Linux-Basis anfällig für die Sicherheitslücke sein. Schon jetzt warnen Sicherheitsexperten davor, dass kriminelle einen Wurm schreiben könnten, der sich von einem ungeschützten System zum Nächsten bewegt.

Auch wenn es vielen Menschen nicht klar ist: Linux läuft mittlerweile auf unzähligen Geräten wie beispielsweise unseren Routern oder sogar unseren Flachbildfernsehern. Während Router zwar im Regelfall mit Firmware-Updates versorgt werden, dürften die meisten Nutzer diese oft nicht einspielen. Und Hersteller von Fernsehern oder anderen netzfähigen Geräten liefern in vielen Fällen nie sicherheitsrelevante Updates aus. Genau deswegen wird uns diese Sicherheitslücke vermutlich noch länger Probleme machen als Heartbleet – allein schon deshalb, weil es beinahe unmöglich ist, eine Liste aller betroffenen Systeme zu erstellen.

via www.theverge.com

Finde einen Job, den du liebst zum Thema iOS

25 Reaktionen
para_neujahr
para_neujahr

Ich kann die Panik die für normale User verbreitet wird nicht teilen. Von dem Bug sind die überwiegende Zahl der User von Macs nicht betroffen, da sie die entsprechenden Dienste nicht freigegeben haben.

Ich zitiere Heise.de dazu:
"Allerdings sieht das Unternehmen in ShellShock, mit dessen Hilfe Shell-Kommandos auf betroffenen Systemen von Unbefugten auch aus der Ferne ausgeführt werden können, augenscheinlich kein großes Problem. Die "große Mehrzahl" der OS-X-User sei nicht betroffen, weil es keine aus der Ferne nutzbaren Dienste gibt, die standardmäßig aktiviert seien. Nur wenn "Unix-Dienste für Fortgeschrittene" konfiguriert würden, bestehe eine Gefahr. Tatsächlich ist etwa SSH standardmäßig unter OS X abgedreht, kann aber mit einem Klick in den Systemeinstellungen aktiviert werden.

Ganz unkritisch ist die weiterhin offene Lücke aber nicht. So existiert seit Donnerstag ein Modul für das Penetrationstestprogramm Metasploit, mit dem sich mittels ShellShock und eine auf dem System vorhandene VMware-Fusion-Installation aus einer virtuellen Maschine heraus Schadcode mit Rootrechten ausführen lässt. Dazu muss ein Angreifer aber Zugriff auf die Maschine haben."

Antworten
Sven Eden
Sven Eden

Wie schön, dass ich Gentoo benutze:
=====
~ $ LC_ALL=C ; env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: Warnung: x: ignoring function definition attempt
bash: Fehler beim Importieren der Funktionsdefinition für `x'.
this is a test
=====

... tjaja...

Antworten
Andy Wenk
Andy Wenk

Lobenswert auf alle Bugs aufmerksam zu machen. Aber bitte keine Panik machen. Dieser Bug existiert offensichtlich seit langem. Es gibt nunmal keine Software die "Bugfrei" ist (sage ich als Software Entwickler). Es muss zwischen den Auswirkungen die der Bug mit sich bringt unterschieden werden. Und die Auswirkungen des "Bash Bug" sind ganz andere als sie bei Heartbleed waren.

Bitte diesen Artikel "aufmerksam" lesen:

"There's little need to rush and fix this bug. Your primary servers are probably not vulnerable to this bug."

"Thus, saying "as bad as Heartbleed" doesn't mean your website is going to get hacked tomorrow, but that a year from now we'll be reading about how hackers got in using the vulnerability to something interesting."

Also - Ruhe bewahren.

Antworten
Wegus
Wegus

ja auf golem.de ist es sehr gut erklärt:

http://www.golem.de/news/bash-luecke-die-hintergruende-zu-shellshock-1409-109463.html

In der Tat gibt es die Lücke bisher so ziemlich überall. Bis auf ein paar gefährlich konfigurierte CGI-Webserver und den einen oder anderen offen zugänglichen Repositoryserver gibt es aber kaum reelle Gefahren.

Trotzdem: bitte dringlichst patchen! Dauert bestimmt nicht lange bis die ersten verseuchten Shell-Skripts im Umlauf sind. Jetzt wo jedes Kiddie davon weiß.

Antworten
Andrea
Andrea

@ all,

Also für Ubuntu 14.10 kann ich in der Bash-Version 4.3.9 den Fehler nicht mehr bestätigen. Dort wirft meine Bash eine Fehlermeldung zurück, dass diese Umgebungsvariable nicht auffindbar sei und daher dieser Testbefehl ignoriert würde.

Hier mal der komplette Bash-Output bei mir in Ubuntu 14.10 mit Bash 4.3.9:

andrea@andrea-SATELLITE-C850-1LQ:~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: Warnung: x: ignoring function definition attempt
bash: Fehler beim Importieren der Funktionsdefinition für »x«.
this is a test
andrea@andrea-SATELLITE-C850-1LQ:~$

Von daher scheint die Version 4.3.9 in Ubuntu 14.10 bereits gefist zu sein und damit ist wohl Bash 4.3.9 bereist nicht mehr betroffen.

Antworten
Bachsau
Bachsau

Nee. Ist seit gestern Nacht sauber

Antworten
Router
Router

@isabela: Das heisst nicht das Du einen Virus hast, sondern das Deine Bash dafür anfällig ist und deswegen aktualisiert werden sollte.
Bei golem.de (und vielleicht auch heise.de) gibts ausführlichere Hinweise und wie man z.B. seine logfiles checken kann um zu sehen wie die damit Eindringen wollten.
Ob man fremden Seiten erlauben sollte, einen zu testen ist vielleicht problematisch: "Teste mal ob Du mein Iphone hacken/mein Auto klauen kannst." und daher sollte man es vielleicht doch besser selber machen bzw. sich (leider) umfangreicher mit dem Thema beschäftigen (müssen).

Antworten
Router
Router

golem.de erklärt es etwas ausführlicher (und heise.de vermutlich auch). Einen offizieller Fix gibts wohl noch nicht. Der erste Fix war u.U. unvollständig.

Die ganz kleinen Systeme benutzen oft andere Shells z.b. Busybox. Danke für die Ergänzung. Teilweise ist die bash aber verfügbar und manche cgi-scripte lassen sich vielleicht dazu bringen, bash aufzurufen.
Beispielsweise XBMC und VLC (oder ich glaube auch Firefox oder Chrome auf Tabletts zB zum bequemeren Debuggen am PC) lassen sich m.W. auch per http steuern wenn man das möchte. Wie anfällig deren Implementierungen sind und ob sie überhaupt ENV-Variable setzen, weiss ich nicht.
Da ENV-Variable aber vererbt werden ohne das man was machen muss, kann auch ein sauberes PHP/CGI/...-Programm/Script/Plugin/... das Problem an SubProzesse weitergeben wo dann die Lücke ausgenutzt wird.
Wie golem schreibt gilt sowas z.b. für curl, wget u.ä. Sowas könnte also z.b. auch in Mediaplayern passieren wenn man denen urls gibt, die sie abspielen sollen (z.B. Chromecast) und diese über Scripte geholt werden die aus Bequemlichkeit in bash geschrieben wurden. Das Risiko lauert also überall weil ENV durchgereicht wird und jedes Plugin oder Hilfs-Script o.ä. bash aufrufen könnte.
Fernseher werden etwa nach 15 Jahren ausgetauscht bzw. neu gekauft. Manche Settopboxen nutzen auch Linux. Usw. Das Problem könnte also länger bestehen.

Wenn man keine Updates geben will/kann, sollten zumindest die Sourcen frei zum ausbessern/verbessern sein. Wenn eine Autofirma pleite ist oder das Modell beendet wurde, kriegt man ja immer noch Ersatzteile und auch neue nachgebaute Teile von Drittherstellern oder dem originalen Hersteller wie z.B. Bosch usw. . Dasselbe Recht sollte für Hardware gelten.

Antworten
Isabella
Isabella

Also das kann ich mir nicht vorstellen:

Um heraufzufinden, ob euer System betroffen ist, müsst ihr den folgenden Code in die Kommandozeile eingeben:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Ein betroffenes System wird diese Antwort ausgeben:

vulnerable

this is a test

Denn dann hat den virus jeder...... Das gibt er ja bei allen aus, habt ihr auch einen richtigen Hinweis wie man das testen kann?

Danke.

Antworten
Bachsau
Bachsau

Nein tut es nicht. Auf gesicherten Systemen gibt es eine Fehlermeldung. DU bist ungeschützt, nicht jeder. Und es ist kein Virus.

Antworten
dj95
dj95

Also auf meinem Ubuntu 14.04.1 Notebook mit Kernel 3.16.3 gibt er, wenn ich das eingebe, nur eine Fehlermeldung und "this is a test" aus... Also gibt der das schon mal nicht bei allen aus. Und zum anderen heißt der Bug ja im Prinzip das man ein Remotescript in der Shell über ein CGI-Script starten kann, wenn ich mich nicht irre.

Antworten
Wegus
Wegus

Es ist ja ok, das jede Zeitung heute auf den Bug und die Patches dazu verweist!

Aber die reisserische Art steht einer Fachzeitung wie t3n irgendwie nicht so gut zu Gesicht!

Antworten
Lukas Klein
Lukas Klein

Um zu überprüfen, ob eure Server betroffen sind, habe ich eine kleine Website gebaut: http://shellshocktest.com

Antworten
Bachsau
Bachsau

Wie willst du das testen, wenn du nichts über die Seite weißt? Ich finde das nicht gut, sowas hier zu bewerben und Nutzer evtl. in falscher Sicherheit zu wägen. Nur weil die Startseite kein CGI ausführt, heißt das nicht, dass es auf der Seite nicht eventuell doch Angriffsmöglichkeiten gibt.

Antworten
nerd6
nerd6

Tolle Überschrift. Wollen wir nicht eine neue Einheit einführen, den Heartbleed?

Also dieser Bug ist eine glatte 4,7 auf der nach oben hin offenen Heartbleed-Skala.

Antworten
cephei
cephei

Dafür gibts die CVE Liste. Der bug wurde mit 10 bewertet.

Antworten
Router
Router

Bei GET-Aufrufen bei CGI werden die Argumente in Environment-Variablen abgelegt. Die CGI-Scripte (in C, PHP,...) rufen ggf. z.b. mit system("...") die Shell auf welche bei Linux oft bash ist.

MiFi-Router, WLAN-Extender, Fritzboxen, NAS-Geräte, Media-Player, Fernseher usw. haben oft einen Webserver eingebaut bzw. werden per HTTP gesteuert. Und teilweise werden dann USB-Sticks gemountet/unmountet oder /sbin/shutdown o.ä. Command-Line-Befehle benutzt wo das Problem ausgespielt werden könnte.

Präzise Details musst Du aber woanders suchen.

Interessant fände ich, wenn man darüber z.b. sein Android-Handy oder seinen Fernseher rooten kann.

Antworten
Bachsau
Bachsau

Okay, jetzt hab ich das Problem kappiert. Am besten verwurstet man alle ENVs sofort und löscht, was nicht gebraucht wird. Aber zum Glück ist der Fix ja schon raus.

Um sein Handy zu rooten müsste man darauf aber erstmal einen CGI-fähigen Server ausführen.

Antworten
cephei
cephei

Nope. Es muss nur Bash installiert sein. Aber soweit ich weiss laufen die meisten Android Phones ohne Bash.

Bachsau
Bachsau

Die FRITZ!en verwenden sowei ich weiß keine Bash.

Antworten
Bachsau
Bachsau

Mir ist der Einfallsvektor noch nicht klar: Wie kann man damit von außen Systeme angreiffen? Es müsste doch erst einmal gelingen eine Variable in den Kontext zu exportieren, aus welchem Später eine Bash gestartet wird. Schon wenn das möglich wär, ist es eine Sicherheitslücke. Wie greift man damit einen Fernseher an?

Das Thema Updates ist natürlich eine andere Sache. Vielleicht muss die Politik hier aktiv werden, und Hersteller unbegrenzt zu Sicherheitsupdates verpflichten.

Antworten
Zumo
Zumo

Danke, dass du diese Frage stellst, auch mir ist das Angriffsszenario unklar... evtl. kann hier jemand etwas Licht ins Dunkel bringen?!

Antworten
cephei
cephei

Uhm ja, die Software ist kostenlos und Updates gibts innert Stunden. Schneller als bei jedem Unternehmen. Bevor sich ein Politiker diesem Thema annimmt ist die Sache längst verjährt.

Antworten
Oink
Oink

Einfach nur Irre was nach und nach entdeckt wird...

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen