t3n News Entwicklung

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

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

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

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

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

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

Newsletter

Bleibe immer up-to-date. Sichere dir deinen Wissensvorsprung!

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
25 Antworten
  1. von Oink am 25.09.2014 (11:27 Uhr)

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

    Antworten Teilen
  2. von Bachsau am 25.09.2014 (11:58 Uhr)

    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 Teilen
    • von Zumo am 25.09.2014 (12:02 Uhr)

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

      Antworten Teilen
    • von cephei am 26.09.2014 (04:35 Uhr)

      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 Teilen
  3. von Router am 25.09.2014 (12:15 Uhr)

    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 Teilen
    • von Bachsau am 25.09.2014 (12:27 Uhr)

      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 Teilen
      • von cephei am 26.09.2014 (04:42 Uhr)

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

        Teilen
    • von Bachsau am 25.09.2014 (12:28 Uhr)

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

      Antworten Teilen
  4. von nerd6 am 25.09.2014 (15:12 Uhr)

    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 Teilen
  5. von Lukas Klein am 25.09.2014 (15:35 Uhr)

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

    Antworten Teilen
    • von Bachsau am 25.09.2014 (20:00 Uhr)

      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 Teilen
  6. von Wegus am 25.09.2014 (16:13 Uhr)

    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 Teilen
  7. von Isabella am 25.09.2014 (19:31 Uhr)

    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 Teilen
    • von Bachsau am 25.09.2014 (20:02 Uhr)

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

      Antworten Teilen
    • von dj95 am 26.09.2014 (09:26 Uhr)

      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 Teilen
  8. von Router am 25.09.2014 (19:54 Uhr)

    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 Teilen
  9. von Router am 25.09.2014 (20:04 Uhr)

    @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 Teilen
  10. von Andrea am 25.09.2014 (23:48 Uhr)

    @ 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 Teilen
  11. von Wegus am 26.09.2014 (08:02 Uhr)

    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 Teilen
  12. von Andy Wenk am 26.09.2014 (08:40 Uhr)

    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 Teilen
  13. von Sven Eden am 26.09.2014 (09:57 Uhr)

    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 Teilen
  14. von para_neujahr am 30.09.2014 (13:00 Uhr)

    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 Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema Apple
OS X 10.12 „Fuji“: Diese Features können Mac-Nutzer erwarten
OS X 10.12 „Fuji“: Diese Features können Mac-Nutzer erwarten

Derzeit spricht vieles dafür, dass OS X ab der nächsten Version in MacOS umbenannt wird. Was sich mit dem Update auf Version 10.12 „Fuji“ sonst noch ändern wird, verraten wir euch in diesem Artikel. » weiterlesen

Tipps und Tricks für OS X: Produktivitäts-Boost für Anfänger und Mac-Ninjas
Tipps und Tricks für OS X: Produktivitäts-Boost für Anfänger und Mac-Ninjas

Egal ob Mac-Anfänger oder Power-User – Tipps und Tricks für OS X erleichtern den Arbeitsalltag immens. Wir haben für euch jede Menge Kniffe zusammen gestellt, unter denen garantiert noch der ein … » weiterlesen

Kritische Sicherheitslücke in OS X: Warum Apple jetzt schnell reagieren muss
Kritische Sicherheitslücke in OS X: Warum Apple jetzt schnell reagieren muss

Erst letzten Monat hat Stefan Esser eine Sicherheitslücke in der aktuellen OS-X-Version aufgedeckt, mit der sich Schadsoftware unbemerkt auf einem Mac einnisten kann. Jetzt ist die erste Malware auf … » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?