Shellshock Sicherheitlücke

So wie ich das lese, gibt es noch kein 100% Patch.

Davon abgesehen würde der Vorgang dann so laufen?

Code: 
apt-get update
apt-get install --only-upgrade bash
 
Last edited by a moderator:
Was ne Lösung....

Aber wird eh sein wie immer, am Ende zahlen die Admins dafür welche nach dem Prinzip *never change a running System* leben....

Für Aktive gibts ja Alternativen.

Gruß Sven
 
Es hat halt schon seinen Grund, dass keine andere Shell dieses Feature implementiert hat.
Und wenn man die entsprechende Diskussion auf oss-sec verfolgt, dann kann man nur hoffen, dass das Feature wieder entsorgt wird. Denn aktuell sind mindestens vier verschiedene Varianten des Sicherheitsloches bekannt und keine einzige vernünftige Lösung. Und die vollständige Tragweite dieses Problems kann auch Niemand überblicken, da auch jegliche indirekte Nutzungsmöglichkeit der Shell beispielsweise durch OpenSSH oder Scriptsprachen oder Versionskontrollsysteme oder sonstwas betroffen ist.
Das Feature ist quasi eine Remoteshell mit potentiellen root-Rechten.

Dagegen sind Heartbleed und Co schon fast harmlos.
 
Ich frage mich gerade, wofür man dieses "Feature" überhaut brauchen könnte? Gibt es dafür irgendeine sinnvolle Verwendung, die sich mir gerade nicht erschließt?


MfG Christian
 
Kann nicht lange dauern, bis es wieder Verschwörungstheorien gibt, nach welchen die NSA das Ganze hat "einbauen lassen". =)

Bei der OpenSSL-Lücke wurde ja meiner Erinnerung nach auch etwas implementiert, was so an dieser Stelle eigentlich nicht notwendig gewesen wäre.
 
Die Version 4.2+dfsg-0.1+deb7u3 für Debian soll wohl alles schließen. Habe das jetzt auf meine Debian Kiste gepackt

Mal ne Frage. Ist es notwendig den Server nach dem Update zu booten? Habe dazu jetzt unterschiedliche Meinungen gehört.
 
PHP-Friends said:
Kann nicht lange dauern, bis es wieder Verschwörungstheorien gibt, nach welchen die NSA das Ganze hat "einbauen lassen".
Click to expand...
Langweilig. Das war dieses Mal sicher das HNaA! Die müssen international auch einmal groß vorkommen :D

Wobei, dort rätselt man vielleicht noch immer, was "Bash" überhaupt ist. Sicher so ein Hacker-Tool… ;)


MfG Christian
 
Ein Feature, dass so schnell wie möglich entsorgt werden muss. Wer soll das alles Überblicken worauf es noch überall Auswirkungen haben könnte.
 
Ist das denn überhaupt für Debian und damit auch Ubuntu ein Problem? Schließlich wird dort ja die Dash benutzt und nicht die Bash.
 
Ja, in der Regel ist bash unter Debian trotzdem installiert und wird auch als Standard-Shell für die User eingetragen. Nur der Link /bin/sh zeigt seit Squeeze standardmäßig auf die dash, falls es nicht anders konfiguriert hat. Und wer die Lücke ausnutzen will, der wird direkt /bin/bash aufrufen - sie muß also nur installiert sein.
 
Und wer die Lücke ausnutzen will, der wird direkt /bin/bash aufrufen - sie muß also nur installiert sein.
Click to expand...
Warum sollte man Shellshock brauchen wenn man eh schon beliebige Befehle ausführen darf :confused:
Der Exploit ermöglicht das Ausführen von beliebigem Code, aber nicht privilege escalation. Wer bereits Shell-Zugriff hat braucht es also nicht mehr.
 
Ja, stimmt. Ich war wohl noch nicht ganz wach. Aber was trotzdem bleibt: Solange die bash installiert ist, kann sie potentiell von anderen Programmen verwendet werden und die Lücke ist ausnutzbar - kein Programm ist gezwungen, /bin/sh zu verwenden, sondern kann auch direkt die /bin/bash verwenden. Und damit ist die Lücke weiterhin potentiell ausnutzbar.
 
Man kann die bash auch deinstallieren und dann gucken was nicht mehr geht. Notfalls einen Symlink von /bin/sh nach /bin/bash wobei unter Debian /bin/sh ein Symlink nach /bin/dash ist. Auch bei dieser Methode muss man mit Nebeneffekten rechnen.

Man kann einfach nicht richtig abschätzen worüber sich das Feature noch ausnutzen lässt. Die Probleme fangen schon an, wenn z.B. irgendeine Software explizit die Bash nutzt. Schlimmer ist es noch, wenn die Software auch noch dieses Feature anderweitig nutzt (was ein schlechter Stil ist). Der Betreuer schrieb unter anderem auch, dass er noch sehen muss, wie er das Problem löst ohne dadurch irgendwelche Inkompatibilitäten auszulösen.

Meiner Meinung nach sollte der Entwickler auf diesen Quatsch überhaupt keine Rücksicht nehmen. Wer so programmiert, hat es nicht anders verdient seine Software im Nachhinein zu fixen.
 
Man darf bei diesem Thema nicht nur in der Kategorie "Server" denken. Es sind wohl auch viele Steuerungen von Industrieanlagen (SCADA) betroffen.
 
SCADA und änliche Systeme erhalten ohnehin nur im extremen Ausnahmefall Updates, weshalb man dort by design ausreichend Zeit zum Anpassen der Scripts hat.
 
Joe User said:
SCADA und änliche Systeme erhalten ohnehin nur im extremen Ausnahmefall Updates
Click to expand...

Wie denn auch, wenn man dann die Zertifizierung verliehrt. Warum meinst Du dass noch so viele unangefasste, aber zertifizierte Windows XP SP0 in Steuerungen (wenn nicht sogar Kraftwerke uws) verwendet werden ;)
 
You must log in or register to reply here.
Back
Top