SHELLSHOCK: Schwere Sicherheitslücke in OS X - was tun?

Und wie kommt das auf den Server?

Es ist gar nicht so unüblich, dass Webanwendungen Shell-Scripts aufrufen, um bestimmte Aktionen durchzuführen. Sobald darüber (oder im Falle von CGI mittels Systemaufrufen, die wiederum bash verwenden) Umgebungsvariablen durchgereicht werden, kann die Falle zuschnappen.

Das Problem ist, dass diese Umgebungsvariablen unzureichend überprüft werden. Normalerweise kann man entweder einen Wert oder eine Funktion zuweisen, durch den Bug wird die Eingabe aber nicht ausreichend überprüft und so kann ein beliebiger Befehl "drangehängt" und mit den Rechten des betroffenen Programms ausgeführt werden.

Solange auf dem Mac keinerlei von außen erreichbare Dienste laufen, ist die Gefahr unter OS X relativ gering. Wobei es auch hier trotzdem Gefahren gibt: zum Beispiel, wenn ein installiertes Programm Daten von außen abruft und über ein Shellscript weiterverarbeitet.
Bei OS X Server ist die Situation noch gefährlicher: Hier sind zahlreiche Serverdienste bereits vorinstalliert und eventuell betroffen. Da es sich hier größtenteils um Closed-Source-Software handelt, ist eine genaue Bedrohungslage schwer abzuschätzen. Also mal abwarten, wann Apple den Patch nachreicht ;)
 
Bedeutet aber in beiden Fällen, dass bei der Qualitätssicherung des Webhosters/Softwareanbieters kriminelle Hacker arbeiten und / oder es kein 4-Augen-Prinzip gibt. Das wäre beides traurig...
 
Bei OS X Server ist die Situation noch gefährlicher: ... Da es sich hier größtenteils um Closed-Source-Software handelt, ...

Welche Closed-Source-Software soll das denn sein?

Bedeutet aber in beiden Fällen, dass bei der Qualitätssicherung des Webhosters/Softwareanbieters kriminelle Hacker arbeiten und / oder es kein 4-Augen-Prinzip gibt. Das wäre beides traurig...

Wie kommst du denn zu der Annahme, dass kriminelle Hacker dort arbeiten müssten?
 
Es ist aber schon so wie Falk sagte: Sowas hat man nicht standardmäßig drauf, man muss es sich installieren. Wie ich schon sagte: Der Hacker muss mich erstmal dazu bringen so ein Script bei mir zu installieren. Mamp und co mag von vielen installiert werden aber ich wage zu bezweifeln, dass der Orginalhersteller von Mamp einem so ein kritisches Script unterjubelt dass via Bash ein Programm startet welches dann böse Sachen macht. Es bleibt wie es ist: Es ist wie von hinten durchs Knie in die Brust das Auge ausschießen.
 
Welche Closed-Source-Software soll das denn sein?

https://www.apple.com/osx/server/features/

Zum Beispiel der Wiki-Server, VPN-Server, Messages-Server, ...
Alles Dienste, die sicher bei vielen Benutzern von außen erreichbar sind. Falls diese Dienste Umgebungsvariablen an Skripte herumreichen, sind sie betroffen. Ob das so ist, weiß wohl nur Apple.

[...] Mamp und co mag von vielen installiert werden aber ich wage zu bezweifeln, dass der Orginalhersteller von Mamp einem so ein kritisches Script unterjubelt dass via Bash ein Programm startet welches dann böse Sachen macht. Es bleibt wie es ist: Es ist wie von hinten durchs Knie in die Brust das Auge ausschießen.

Das Problem ist nicht der Webserver, sondern unvorsichtig programmierte Anwendungen, bei der Umgebungsvariablen ungeprüft übergeben werden. Wenn ein Script zum Beispiel für die Auswertung der Seitenbesucher u.a. den Useragent an ein Bash-Script zum Weiterverarbeiten übergibt, und dieser dummerweise vom Angreifer auf

Code:
() { :;}; echo "you are hacked"

gesetzt wurde, wird der Befehl "echo you are hacked" mit den Rechten des Webservers ausgeführt.
 
Ich fasse mal zusammen:

Lücke sehr Ernst und Systemübergreifend.

OttoNormalVerbraucher sind nicht Betroffen. Auch aufgrund der mittlerweile obligatorischen Firewall im Router.
Betroffene werden sich informieren, wie man die Lücke schließt. (Serverbetrieb bringt immer auch Pflichten mit sich)

Apple arbeitet an einer Lösung.

Bleibt mir als Nutzer nur zu hoffen, dass die unzähligen Webseiten auf denen ich mich mal registriert hatte aufpassen und nicht vor einspielen eines Sicherheitspatches "ausgeräumt" werden.
 
Gute Zusammenfasstung, tocotronaut ;)
Wobei wie gesagt auch "normale" Programme betroffen sein könnten, die nicht vertrauenswürdige Daten mittels Umgebungsvariablen zur Weiterverarbeitung übergeben. Stell dir zum Beispiel einen Twitter-Client vor, der ein Notification-Script mit der Umgebungsvariable TWEET aufruft, um eine tolle Meldung anzuzeigen. Normalerweise kein Problem, aber durch die Lücke könnte es so zur Ausführung von Schadcode kommen.
 
Nein, normale Programme sind hier eben nicht betroffen, nur explizit die bash und auf Macs leider auch sh, weil das auch eine bash ist (ja ich habe jetzt das *könnten* gelesen).

Der Fehler liegt darin, dass die bash das Environment fehlerhaft auswertet und leider ausführt, bevor sie selbst etwas ausführt.
Da man vorher nichts davon wusste*, kann man auch den cgi-Entwicklern hier keine Schuld geben oder sie gar kriminell nennen.
Nicht zu vergessen, muss nicht explizit die bash im cgi aufgerufen werden, es kann auch ein »Systemaufruf« einer völlig anderen Sprache wie Perl, Ruby etc. dazu führen die bash aufzurufen. Da muss man auch nur z.B. an Monitoranwendungen wie Munin usw. denken, die häufig auch solche Schnittstellen verwenden.

* Dass man es vorher nicht wusste, stimmt ja irgendwie auch nicht, denn der Fehler ist lange bekannt. :p

Das Problem ist nicht der Webserver, sondern unvorsichtig programmierte Anwendungen, bei der Umgebungsvariablen ungeprüft übergeben werden.

Frag' mal 'nen App-Entwickler, ob er »env« überhaupt kennt (und nicht nur argc/argv).
 
Nein, normale Programme sind hier eben nicht betroffen, nur explizit die bash und auf Macs leider auch sh, weil das auch eine bash ist (ja ich habe jetzt das *könnten* gelesen).

Ja eben ;) Es kommt natürlich darauf an ob das Programm mit sauberen Schnittstellen kommuniziert oder nur mit heißer Nadel zusammengestrickt wurde.

Der Fehler liegt darin, dass die bash das Environment fehlerhaft auswertet und leider ausführt, bevor sie selbst etwas ausführt.
Da man vorher nichts davon wusste*, kann man auch den cgi-Entwicklern hier keine Schuld geben oder sie gar kriminell nennen.
Nicht zu vergessen, muss nicht explizit die bash im cgi aufgerufen werden, es kann auch ein »Systemaufruf« einer völlig anderen Sprache wie Perl, Ruby etc. dazu führen die bash aufzurufen. Da muss man auch nur z.B. an Monitoranwendungen wie Munin usw. denken, die häufig auch solche Schnittstellen verwenden.

Da hast du vollkommen recht!

Frag' mal 'nen App-Entwickler, ob er »env/arge« überhaupt kennt (und nicht nur argc/argv).
Ja, bei den Apps kommts natürlich stark darauf an, was der Entwickler verwendet. Im Webumfeld wird zum Beispiel bei PHP-FCGI für den system-Befehl die Standardshell - und das ist bei OS X die Bash - aufgerufen.
 
...wird zum Beispiel bei PHP-FCGI für den system-Befehl...

Haha, das sind die wahren Spezialexperten, bei de.php.net/system kommt die Seite auf französisch. :faint:

@Kaito (#92)
Ja, in Chrome geht's hier auch.
 
Zuletzt bearbeitet:


gesetzt wurde, wird der Befehl "echo you are hacked" mit den Rechten des Webservers ausgeführt.

Aber dieser Befehl "echo you are hacked" ist ja recht witzlos. Was stünde da normaler weise? Mal ganz davon unabhängig, dass der Angreifer erstmal das Script gehackt haben müsste? Wir reden hier von einem Problem bei dem der Angreifer erstmal durch mindestens zwei Türen durchgangen sein muss…
 
Aber dieser Befehl "echo you are hacked" ist ja recht witzlos. Was stünde da normaler weise? Mal ganz davon unabhängig, dass der Angreifer erstmal das Script gehackt haben müsste? Wir reden hier von einem Problem bei dem der Angreifer erstmal durch mindestens zwei Türen durchgangen sein muss…

Da kann irgendwas stehen. Z.b. könntest du dir (als Hacker) irgendwelche Konfigurationsdateien mailen lassen die dir dann einen weiteren Angriff stark vereinfachen. Oder du kannst den Server einfach überlasten. Oder andere Systeme wiederum von diesem Server aus angreifen. Was auch immer...

Und nein, das Script muss eben nicht gehackt werden, das ist das Problem (obwohl ich nicht ganz sicher bin, was du damit meinst).
 
Das Problem ist in der Summe die Möglichkeit, unauthorisierte scripte ausführen zu lassen. Was nützt es wenn MEIN Rechner "sicher" ist (also keine ? möglichen Angrifspunkte bietet), aber die Gegenstellen die JEDER Rechner anläuft es nicht sind? Weiß ich welche Software z.B. bei MacUser die Server füttert oder eben angreifbar macht? Es ist schlicht nicht möglich alle kreativen Einfälle eines kriminellen Hackers im voraus zu erahnen, ergo muss die Fehlerstelle / Lücke geschlossen werden. Wir tauschen mittelerweile so viele Daten aus (Passwörter, logins, emails, Webabfragen, Suche und und und) das niemand hier einen Missbrauch gebrauchen oder ausschließen kann.

"Nichtkriminelle Hacker" (NSA, BND, GCHQ etc. über "Nicht" kann man diskutieren…) nutzen genau diese Art von Schwachstellen ebenfalls gezielt aus, weil sie schlicht JEDEN Angriffspunkt nutzen! Hat sich eine solche Möglichkeit erst einmal "herumgesprochen", steigen die ganzen Trittbrettfahrer auf, allerdings nicht ganz so "stilvoll" und leise - wie viele "nichtöffentliche" (besser nicht öffentlich bekannte) exploits mag es geben? Zumindest die bekannten sollten schleunigst geschlossen werden - Apple ist in der Pflicht, denn sie wollen schließlich genug Daten von den Usern haben!

Je länger die Lücke offen bleibt, desto mehr "Neugierige" werden mal sehen "was sich damit machen lässt" - das ist keine Panikmache, das läuft schließlich immer nach dem gleichen Muster ab... Wie schnell auch eine Firma wie Apple in den Haufen treten kann, sehen wir am sorgfältigen Testverfahren mit dem IOS 8 und IOS 8.01 auf den Markt kam ;)
 


Und nein, das Script muss eben nicht gehackt werden, das ist das Problem (obwohl ich nicht ganz sicher bin, was du damit meinst).

Und woe bekommt der Hacker dann das Script dazu seinen Code ( also den des Hackers) auch auszuführen wenn er das Script nicht entsprechend ändert?
 
Aber dieser Befehl "echo you are hacked" ist ja recht witzlos. Was stünde da normaler weise? Mal ganz davon unabhängig, dass der Angreifer erstmal das Script gehackt haben müsste? Wir reden hier von einem Problem bei dem der Angreifer erstmal durch mindestens zwei Türen durchgangen sein muss…

Weiter oben habe ich ja schon verlinkt, was z.B. auf Macs geladen wird.
Im gegenwärtigen Angriff wird versucht per wget/curl eine Datei in das /tmp Verzeichnis des Rechners zu laden und auszuführen.
Und nein, der Angreifer geht nirgends durch, entweder das System ist, so wie es ist, verwundbar oder nicht.
Es wird gerade blind geschossen, wenn kein Treffer, ab zum Nächsten.

Zu #97: Die bash führt es einfach aus. Genau das ist der Fehler.

Wir tauschen mittelerweile so viele Daten aus (Passwörter, logins, emails, Webabfragen, Suche und und und) das niemand hier einen Missbrauch gebrauchen oder ausschließen kann.

Ja, lieber meldet man sich überall mit demselben User/Passwort an, anstatt OAuth/OpenID zu benutzen, aber da heisst's dann immer gleich, böses Google/Facebook whatever...
 
Der Bug scheint nicht seit 25 Jahren durchgängig in der bash enthalten zu sein, zwischenzeitlich wurde er gefixt, hat sich dann aber wieder »eingeschlichen«. :p
Und ich habe mich schon gewundert warum meine alte BASH auf meinem CentOS das Problem nicht hat. Jetzt weiß ich wieder, warum ich altes abgehangenes laufen haben. :D

Du brauchst nur ein CGI Script auf dem Server in dem oben

#!/bin/bash

steht. Leider reicht das. Ich hatte das Vergnügen am Freitag.
Es dauert leider keine 2 Minuten um echt böse Exploits damit zu schreiben.

Ich dachte auch erst, dass das ganze übertrieben ist, aber ich habe es mir angeschaut.
Wow, Du kannst Googlen. Die Sache daran ist nur, eigentlich nutzt keiner mehr CGI, außer ein paar Nerds mit Perl & Co. Die sind aber wieder so Nerds, dass die ihre Systeme gleich gepatcht haben.

Selbst manche Perl, Ruby oder andere serverseitigen Komponenten benutzen FCGI und kleine Shell-Wrapper um sich zu starten.
Es ist nicht ungewöhnlich, das man so etwas findet:

Code:
#!/bin/sh
ROOT=`dirname $0`
exec ruby -I /var/ruby/1.8/gem_home/gems/fcgi-0.8.7/lib/ $ROOT/myfcgi.rb
Wie gesagt, Du kannst Googlen. Nur jeder, der Ruby nutzt und die Doku entsprechend gelesen hat, hat Ruby über eine der folgenden Arten laufen:
- keine Apache: dann läuft Ruby selber als Webserver mit dem Webrick.
- Apache, NGINX vorhanden: Ruby läuft als Webrick auf anderem Port, der von außen nicht erreichbar und der Webserver macht nur einen ReverseProxy.
- Apache: hat das Apache-Passenger-Modul laufen

Es ist gar nicht so unüblich, dass Webanwendungen Shell-Scripts aufrufen, um bestimmte Aktionen durchzuführen. Sobald darüber (oder im Falle von CGI mittels Systemaufrufen, die wiederum bash verwenden) Umgebungsvariablen durchgereicht werden, kann die Falle zuschnappen.
Das ist inzwischen schon sehr unüblich.
Bei OS X Server ist die Situation noch gefährlicher: Hier sind zahlreiche Serverdienste bereits vorinstalliert und eventuell betroffen. Da es sich hier größtenteils um Closed-Source-Software handelt, ist eine genaue Bedrohungslage schwer abzuschätzen. Also mal abwarten, wann Apple den Patch nachreicht ;)
Nö, die BSD-Environment, die im Mac OS X läuft ist sehr quelloffen. Deswegen nutzt Apple es und hat da gar nichts eigenes. Du kannst Dir die BASH auch selber mit GCC, LVM, Xcode zusammen kompilieren und erstezen.

Ja, bei den Apps kommts natürlich stark darauf an, was der Entwickler verwendet. Im Webumfeld wird zum Beispiel bei PHP-FCGI für den system-Befehl die Standardshell - und das ist bei OS X die Bash - aufgerufen.
Nur wenn PHP über CGI läuft. Das macht aber keiner mehr. Jeder nimmt das Apche-PHP-Modul und da ist es egal. Da besteht das Problem nicht.
 
Zurück
Oben Unten