Check nach Shellshock Bug

PhilippDominik

PhilippDominik

Aktives Mitglied
Thread Starter
Dabei seit
16.01.2012
Beiträge
123
Reaktionspunkte
8
Im Terminal. Wobei du beachten solltest, dass die Anführungszeichen am Schluss auch "normale" Anführungszeichen sind, keine Guillemets.
Also " - nicht »

Und ohne das Dollar-Zeichen zu Beginn.

Wirklich viel sagt das aber eh nicht aus. Das heisst nicht, dass der Computer von irgendwas befallen ist. Nur dass die Version von bash grundsätzlich das Sicherheitsproblem hat.
 
  • Gefällt mir
Reaktionen: rembremerdinger, Chimaira und PhilippDominik
Man muss das ganze im Terminal eingeben.
Und ja, es geht.

Fragt sich nur was das jetzt soll. Wenn ich Shell Code ausführen kann, brauche ich den Umweg über die Funktionsdefinition nicht.
 
  • Gefällt mir
Reaktionen: PhilippDominik
Aber trotzdem: wo bzw. wie gebe ich diese Zeilen ein?
 
Du öffnest das Programm Terminal:

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

Wenn der Teil "this is a test" auch ausgegeben wird bedeutet das, dass man nach einer Definition der Shell Funktion "x" noch beliebigen Shell Code ausf[hren kann.
Aber wenn ich das sowieso schon kann, brauche ich die Funktionsdefinition nicht.

Das "#" vorne soll das Shell Prompt sein.
 
  • Gefällt mir
Reaktionen: PhilippDominik
Also mein Test zeigt das erwartete Ergebnis...

Nutzername:~ User$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
Nutzername:~ User$
 
pmau schrieb:
Man muss das ganze im Terminal eingeben.
Und ja, es geht.

Fragt sich nur was das jetzt soll. Wenn ich Shell Code ausführen kann, brauche ich den Umweg über die Funktionsdefinition nicht.
Zum Vergrößern anklicken....

Es geht doch darum zu prüfen ob die Bash potentiell verwundbar ist. Eigentlich sollte der Code in der Variablenzuweisung nicht ausgeführt werden. Wird er aber. Das ist Pontentiell ein Problem. Und nur darum geht es.
Nicht alles was man nicht versteht ist unsinnig.

Atti
 
Haribofreak schrieb:
Also mein Test zeigt das erwartete Ergebnis...

Nutzername:~ User$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
Nutzername:~ User$
Zum Vergrößern anklicken....

Was ist daran "erwartet" ?
Mit dem Wissen um den Fehler ist es erwartet, aber vom reinen Code müsste das Ergebnis "this is a test" sein.


Atti
 
  • Gefällt mir
Reaktionen: Chimaira
Dieser Teil "echo vulnerable" ist nicht mehr Teil der Shell Funktion und dürfte nicht ausgegeben werden.

Aber irgendwie muss ich diese Zeile ja einbauen.
Und wenn ich das schon kann, kann ich auch "rm -rf blah" einbauen.

Dafür brauch ich dann das "env" nicht.
 
Ich hab das ganze über Spiegel-Online gelesen - dort hieß es:

Wenn nach Eingabe dieser Zeile "vulnerable" auf dem Bildschirm angezeigt wird, dann ist der Rechner von der Sicherheitslücke betroffen.
Wird die Warnmeldung "bash: error importing function definition for x" ausgegeben, dann ist die Lücke bereits gestopft.

Erwartet: Apple hat noch nicht darauf reagiert also zeigte mein Test genau das an, was vorhergesagt war - wenn ich das richtig verstanden habe ;-)
http://www.spiegel.de/netzwelt/web/...-bedroht-linux-rechner-und-macs-a-993688.html
 
pmau schrieb:
Dieser Teil "echo vulnerable" ist nicht mehr Teil der Shell Funktion und dürfte nicht ausgegeben werden.

Aber irgendwie muss ich diese Zeile ja einbauen.
Und wenn ich das schon kann, kann ich auch "rm -rf blah" einbauen.

Dafür brauch ich dann das "env" nicht.
Zum Vergrößern anklicken....

So einfach ist es leider nicht. Environment Variablen kannst du z.B. auch über einen Webserver (bzw. über Header in einem HTTP Request) weitergeben bei gewissen Servern. Und da ist das dann potenziell ein grosses Problem.

Siehe hier:
http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html

Edit: Das sollte den "normalen" OS X Desktop Benutzer aber natürlich nicht betreffen, das ist eher ein Problem das Server betreffen wird.
 
  • Gefällt mir
Reaktionen: PhilippDominik
1. braucht ihr das nicht testen, weil alle BASH-Versionen (bis gestern) dieses Problem haben. Da Apple noch gar kein Update heraus gebracht hat, haben alle alten und aktuellen Mac OS X Versionen das Problem.
2. Ist das nur ein Teil der Wahrheit. Selbst die gefixten BASH-Versionen sind nicht unverwundbar. Es gibt inzwischen eine 2. Variante davon.
3. Wenn Eurer Rechner keine Dienste im Internet anbietet, also direkt eine öffentliche IP hat, dann ist das eh vollkommen irrelevant.
 
pmau schrieb:
Dieser Teil "echo vulnerable" ist nicht mehr Teil der Shell Funktion und dürfte nicht ausgegeben werden.

Aber irgendwie muss ich diese Zeile ja einbauen.
Und wenn ich das schon kann, kann ich auch "rm -rf blah" einbauen.

Dafür brauch ich dann das "env" nicht.
Zum Vergrößern anklicken....

Nein, das ist nicht richtig. Der witz an dem Bug ist, das der Code erst beim Sourcen eines neuen Environment ausgeführt wird!

Kleines Experiment dazu:

Code: 
x='() { :;};  echo DATEN GESTOHLEN'
export x
bash -c "echo Harmlos"

Wenn man das mal macht, dann sieht man das Potential dieser Lücke. Eine vermeindlich harmlose Umgebungsvariable führt dazu das Code ausgeführt wird. Das ist z.B. bei Webservern kritisch, da über Umgebungsvariablen parameter an Scripte übergeben werden (zumindest ist das eine Variante).

Atti
 
...wenn bei mir also entsprechend "vulnerable" erscheint - das tut es - was mach ich dann? Bzw. wo muss ich besonders aufpassen? (Internet-Banking etc. ??)
 
Hi,

Ist für normale User ziemlich uninteressant.

Atti
 
Pingu schrieb:
2. Ist das nur ein Teil der Wahrheit. Selbst die gefixten BASH-Versionen sind nicht unverwundbar. Es gibt inzwischen eine 2. Variante davon.
Zum Vergrößern anklicken....
Wofür du aber zumindest partiellen Zugriff auf die command line benötigst, was die Sache schonmal drastisch entschärft.
zsh ist übrigens nicht betroffen.


Redhat nennt neben Webservern und SSH Verbindungen übrigens auch noch DHCP Services als potentielle Angriffsvektoren. Letzteres kann auch beim OSX und iPhone Normalnutzer hässlich werden.
 
Kaito schrieb:
Redhat nennt neben Webservern und SSH Verbindungen übrigens auch noch DHCP Services als potentielle Angriffsvektoren. Letzteres kann auch beim OSX und iPhone Normalnutzer hässlich werden.
Zum Vergrößern anklicken....
Gerade selber im Netzwerk getestet, also dem DHCP-Server die entsprechende Option untergeschoben, siehe: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
Auch mit anderen Option-Codes gespielt und Ergebnis, es ist kein Problem.

Es ist wohl nur ein Problem, wenn man auf den Clients entsprechende Hooks eingerichtet hat. Das hat kein Standard-Nutzer.
 
  • Gefällt mir
Reaktionen: rembremerdinger und PhilippDominik
sorry falsches forum
 
Pingu schrieb:
Gerade selber im Netzwerk getestet, also dem DHCP-Server die entsprechende Option untergeschoben, siehe: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
Auch mit anderen Option-Codes gespielt und Ergebnis, es ist kein Problem.

Es ist wohl nur ein Problem, wenn man auf den Clients entsprechende Hooks eingerichtet hat. Das hat kein Standard-Nutzer.
Zum Vergrößern anklicken....

Danke für den Test... Wielange haben die normalerweise um einen Patch nachzuliefern? Weil, nur weil ich nicht betroffen bin, habe ich trotzdem lust dies zu fixen ... :)
 
Wenn man nicht gerade einen Server betreibt, der permanent öffentlich zugänglich ist (web-server) dann sollte man erstmal Ruhe bewahren und warten, bis auch die neuen, resultierenden Lücken bzw. die im Zusammenhangstehenden mit gefixt werden.
Andernfalls müßte man schlußendlich nur wieder Patches für Patches installieren - scheinbar ist der Umfang noch nicht gänzlich erfasst...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten