ShellShock: Nächste große Sicherheitslücke nach Heartbleed

28 Sep
28. September 2014

In den IT-Medien schwirrt zur Zeit ein Begriff zu einer zuletzt aufgedeckten Sicherheitslücke: ShellShock. Kurz gesagt ist ShellShock eine Sicherheitslücke in der BASH (Bourne again shell), in der Code durch einen Befehl ausgeführt wird. Im schlimmsten Fall kann durch die Sicherheitslücke das System übernommen werden. In diesem Artikel werde ich die Hintergründe dieser Sicherheitslücke einmal beleuchten.

Was ist die Bash?
Bei der Bash handelt es sich um eine so genannte Shell. Eine Shell ist im Grunde der Inhalt des Terminals, das man oft zum Installieren oder Konfigurieren des Systems nutzt. Neben der Bash gibt es noch andere, z.B. ZSH oder KSH, um ein paar Namen zu nennen.

Was ist die Sicherheitslücke?
Die Bash erlaubt es sogenannte Funktionen in Variablen zu definieren. Eine Variable ist gewöhnlich ein Platzhalter für einen oder mehrere Werte. Eine Funktion ist eine Konstruktion, die eine bestimmte Aufgabe ausführt, z.B. dem Benutzer einen Begrüßungstext auszugeben. Das Problem an dieser Funktionalität ist, dass der Inhalt, der in der Variable gespeicherten Funktion, nicht geprüft wird.

Um die Gefährlichkeit zu demonstrieren, könnte man bei ShellShock von einem GAU bzw. einem Worst-case-Szenario sprechen. ShellShock, auch unter CVE-2014-6271 und CVE-2014-7169 bekannt, wird auf einer 10-Punkte Skala mit 10 Punkten geführt und ist somit sehr gefährlich und erfordert Handlungsbedarf.

ShellShock wird von mancher Seite als schlimmer als Heartbleed bezeichnet. Heartbleed war, wenn man so will, ein reines Datenschutzproblem. ShellShock hingegen bietet ein Einfallstor, welches im schlimmsten Fall ermöglicht, dass Dritte den Server übernehmen können.

Bin ich betroffen?
Die Sicherheitslücke besteht seit 20 Jahren. In vielen Linux-Systemen wird die Bash vorinstalliert und als Standard festgelegt. Auch Mac OS X Nutzer müssen handeln, da auch hier Bash zum Einsatz kommt. Andere Systeme, wie BSD installieren diese zum Teil auch, aber sie wird nicht als Standard festgelegt.

Um zu testen ob die Lücke auf dem eigenen Gerät noch offen ist, kann in einem Terminal folgender Befehl ausgeführt werden:

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

Gibt das Terminal „gehackt“ aus, so ist das System von dem Problem betroffen. Wird stattdessen ein Fehler ausgegeben, heißt das nicht unbedingt, dass die Lücke geschlossen wurde. Es gab zwei Updates um die Sicherheitslücke zu schließen. Das erste funktionierte in manchen Fällen, aber nicht bei allen. Daher wurde ein zweites Update veröffentlicht. Um diese Fälle zu testen, kann dieser Befehl genutzt werden:

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

Wird auch hier der Text „gehackt“ ausgegeben, dann ist die installierte Version von Bash immer noch verletzlich.

Update: Inzwischen sind, wie ein Artikel von Golem gut zusammenfasst, weitere Lücken in der Bash bekannt geworden, die im Zusammenhang mit ShellShock stehen, jedoch als weniger gravierend anzusehen sind. Ein Script um auch diese Lücken zu überprüfen findet ihr im bashcheck Repository von hannob.

Wird die Sicherheitslücke ausgenutzt?
Ja, laut Heise häufen sich die Angriffe, welche die ShellShock-Lücke nutzen. Dies wird auch den Hintergrund haben, dass die Lücke leicht ausgenutzt werden kann und es so gut wie alle u.a. Server, die auf Linux basieren, betrifft.

Es gibt verschiedene Angriffsszenarien, wie ShellShock ausgenutzt werden kann. Ein Großteil der Angriffe läuft wohl über Webserver, welche so genannte CGI-Skripte nutzen. Mit diesen Skripten kann man Systembefehle ausführen. Wird nun über den Webserver Code eingeschleust und das Skript überprüft nicht ausreichend, so ist es denkbar, dass dieser Code ausgeführt wird. Neben den Angriff über einen Webserver ist es denkbar, dass die Lücke auch über andere Dienste laufen kann, die prinzipiell Code ausführen können. So kann die Lücke theoretisch sogar über den Druckserver CUPS ausgenutzt werden. Dieser wird aber selten für Angriffe missbraucht, da dieser nicht oft öffentlich erreichbar ist.

Wie kann ich das Problem beheben?
Wie bereits erwähnt, gab es mindestens zwei Updates für die Bash. Daher gilt, dass man alle Systeme, welche die Bash verwenden oder diese auch nur installiert haben, aktualisieren sollte.

Unter Debian, einer der im Server Bereich weitest verbreitetsten Linux-Distributionen, kann man ein Update mittels folgenden Kommandos ausführen. Auch Raspbian für den Raspberry Pi basiert auf Debian.

sudo apt-get update && sudo apt-get upgrade

Quellen: Golem, Heise

 

Hallo, ich bin Christoph, ein Programmierer und Mensch hinter 0fury.de. Seit einigen Jahren bin ich Linux Nutzer und seit einigen Monaten insbesondere ein Enthusiast von Arch Linux. Ab und zu werde ich Gastbeiträge auf diesem Blog schreiben – hauptsächlich über Dinge rund um (Arch) Linux – in denen ich euch die Linux-Welt etwas näher bringen möchte.

Dir hat der Artikel gefallen?
Teile ihn mit deinen Freunden!
3 Antworten
  1. phantomaniac says:

    Was ich mich immer Frage. Muss ich bei „unix“ wirklich keine reboots machen ?
    Also ich meine nach den Updates….

    und kann man den Befehl nicht noch um && sudo apt-get clean ergänzen.
    Warum auch immer, führ ich den immer extra noch dem update aus. 🙂 (Nehms mir zwar immer für das nächste Update vor, vergess es bis dahin aber immer)

    Antworten
    • Christoph Müller says:

      Also ich persönlich würde nach Updates immer empfehlen, neu zu starten. Wird z. B. ein Teil des Kernels aktualisiert, so wird er oft auch erst beim nächsten Neustart geladen. Es gibt sicher auch Updates, nach denen du nicht neu starten musst. Ob „reines“ Unix (also nicht Linux) sich da anders verhält, kann ich dir an dieser Stelle nicht sagen.
      apt-get clean leert deinen lokalen Paketcache. Das sollte man eigentlich nur dann tun, wenn dieser z. B. beschädigt und nicht mehr lesbar ist :D.

      Antworten
      • Chr. Knauer says:

        Nach einem „normalen“ Update, welches keine Kernel- oder Desktopkomponenten oder systemnahen Libs austauscht/updated, braucht i.d.R. auch kein Reboot durchgeführt werden. Allenfalls muß das eine oder andere laufende Programm neu gestartet werden, sofern es zur Laufzeit des Updates aktiv war (schön zu sehen, wenn auf dem Desktop Firefox lwährend des Updates läuft, meldet er sich zmit der Meldung“need zo resart“, wenn FF im Update enthalten war – zumindest bei Debian-basierten Distris)
        Ein apt-get clean kann auch sinnvoll sein, wenn der Plattenplatz mal knapp werden sollte 😉

        Antworten

Antworten

Kommentar verfassen

JanKarres.de © 2007-2017