1. Liebe Forumsgemeinde,

    aufgrund der Bestimmungen, die sich aus der DSGVO ergeben, müssten umfangreiche Anpassungen am Forum vorgenommen werden, die sich für uns nicht wirtschaftlich abbilden lassen. Daher haben wir uns entschlossen, das Forum in seiner aktuellen Form zu archivieren und online bereit zu stellen, jedoch keine Neuanmeldungen oder neuen Kommentare mehr zuzulassen. So ist sichergestellt, dass das gesammelte Wissen nicht verloren geht, und wir die Seite dennoch DSGVO-konform zur Verfügung stellen können.
    Dies wird in den nächsten Tagen umgesetzt.

    Ich danke allen, die sich in den letzten Jahren für Hilfesuchende und auch für das Forum selbst engagiert haben. Ich bin weiterhin für euch erreichbar unter tti(bei)pcwelt.de.
    Dismiss Notice

Shellshock (BashBug) ...

Discussion in 'Ihre Meinung zu Artikeln auf pcwelt.de' started by Thor Branke, Sep 26, 2014.

Thread Status:
Not open for further replies.
  1. Thor Branke

    Thor Branke CD-R 80

    ... scheint hier niemanden zu beeindrucken. Wie bedrohlich ist dieser Angriffsvektor im Alltag wirklich? Oder steht Ihr noch unter Schock? ;) :)
     
  2. kalweit

    kalweit Hüter der Glaskugel

    Weil nicht sein kann, was nicht sein darf... Wobei man aber sagen muss, dass es für einen Angriff von extern ein zusätzliches Trittbrett braucht. Leider sind die Trittbretter vielfältig und es kann selbst vorsichtige User problemlos treffen. Damit wird wohl DER Linuxmythos zu Grabe getragen.

    Das Trittbrett finde ich z.B. sehr interessant: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ - damit lassen sich Rechner angreifen, die direkt gar nicht angreifbar wären. Das hebelt auch noch gleich die viel gelobte Rechtestruktur von Linux komplett aus.
     
    Last edited: Sep 26, 2014
  3. rkaerner

    rkaerner ROM

    Schwachfug. Jedes Betrübssystem auf diesem Planeten ist von Schwachstellen betroffen. Im Gegensatz zu Systemen auf Basis von closed source wird in der unixoiden Welt (mit Ausnahme von MacOS) jedenfalls kein "security through obscurity" betrieben.

    Du willst mir DEN Linuxmythos mal zeigen. Linux ist deutlich schwerer zu attackieren, weil eben ein vernünftiges Rechtemanagement vorhanden ist, dass sich nicht durch einen Schieberegler konfigurieren lässt. Niemand wird jemals behaupten, dass ein auf Linux basiertes System absolut sicher ist. Es stellt sich die grundsätzliche Frage nach dem Aufwand. Und der dürfte bei dem von Dir offensichtlich bevorzugten System deutlich geringer sein.

    *LOL* Ne, is kla. Dir ist schon bewusst, dass Du für entsprechende Änderungen physischen Zugriff auf den betreffenden Rechner haben musst, oder? Und mal unter uns: wenn ich physischen Zugriff auf ein Gerät habe (egal, mit welchem OS das ausgestattet ist), dann gehört das entsprechende Gerät mir. Da brauche ich dann ein solches Trittbrett gar nicht.

    Sprich also mal ein wenig weniger FUD.
     
    Last edited: Sep 27, 2014
  4. X.MAN

    X.MAN Moderator

    Du widersprichst dich in Sachen Betriebssystem selbst. :dumm:

     
  5. kalweit

    kalweit Hüter der Glaskugel

    Dir ist offensichtlich nicht klar, dass dort nur das Funktionsprinzip beschrieben wird. Der DHCP Server befindet sich üblicher Weise nicht auf deinen Arbeitsrechner, sondern an ganz anderer Stelle. Jetzt kombiniere exemplarisch die letzte Sicherheitslücke im FritzOS mit der Bashlücke und du hast ohne Abwehrmöglichkeit ein gesamtes Netz von extern übernommen.

    Das hilft dir gar nichts, wenn Systemprozesse angegriffen werden, die bereits mit den entsprechenden Rechten laufen. Beispiele gab es auch unter Linux in der Vergangenheit einige.

    Ich bevorzuge keine Systeme, sondern nutze die, welche die jeweils gestellte Aufgabe am besten erfüllen. Die Frage nach dem Aufwand ist wenig zielführend. Jede technische Angriffsmethode lässt sich automatisieren.
     
  6. root

    root Megabyte

    Den Bug konnte ich relativ einfach nachvollziehen, nachdem ich auf dem privaten Server die Bash installiert habe und cgi-Skripte davon ausführen ließ. Warum man überhaupt Shellfunktionen an Unterprozesse exportieren können muss, erschließt sich mir nicht. Der Nutzen scheint doch eher gering zu sein, zumal die Funktionalität inkompatibel zu anderen Shells ist.
    Nein, es reicht aus, sich im selben Netzwerk zu befinden und darauf zu warten, dass der Client eine DHCP-Anfrage verschickt.
     
  7. rkaerner

    rkaerner ROM

    Du kriegst eine eins im Fach "wie reisse ich einen zusammenhängenden Beitrag so auseinander, dass der Sinn dennoch nicht verloren geht und kriege trotzdem nicht mit, dass da kein Widerspruch ist.
     
  8. rkaerner

    rkaerner ROM

    Bei mir läuft dhcpcd nicht mit root-Rechten. Warum sollte er das auch? Ein Kommando, das administrative Rechte verlangt, wird entsprechend scheitern.

    Die Frage nach dem Aufwand ist aber die, die darüber entscheidet, ob ein Angriff lohnenswert ist oder nicht. Sicher, sie entscheidet nicht darüber, ob ein Angriff durchgeführt wird. Die Automatisierung von Angriffen und deren tatsächlicher Nutzen sind Dinge, die ich jeden Tag beobachten darf. Es gilt weiterhin: Ein Angriff, der rechnerisch mehr kostet, als er einbringt, ist weniger wahrscheinlch als ein Angriff, den ich mit geringstem Aufwand beim maximalem Ertrag durchführen kann.

    Ich finde es sehr gut, dass da Inkompatibilitäten bestehen.

    Müsste der Satz nicht lauten: "Es reicht aus, sich im selben Netzwerk zu befinden und Herr über (den|einen) dhcp-Server zu sein"? Und wäre damit dann nicht die von mir erwähnte physische Präsenz notwendig, zumindest für den Zeitraum, den es braucht, Zugriff auf einen bestehenden dhcpd zu nehmen oder einen eigenen dhcpd zu integrieren?

    Ich sehe jedenfalls nicht, dass $script-kiddie hier irgendwas mal eben so übernimmt. Und ich sehe hier ganz ehrlich auch nicht einen einzigen Server um mich herum, der ein auf unix basierendes OS hat und dann auch noch seine IP-Adresse per dhcp bezieht.
    Um mich mal dem Anfangsbeitrag zu widmen: Vielleicht ist das der Grund, dass es auf eine solche Meldung so wenig Resonanz gibt. Vielleicht ist aber auch nur der Grund, dass die Leute, die das können, an der Beseitigung der Lücke arbeiten, statt wegen eines Fehlers gleich ein ganzes System niederschreiben zu wollen.

    Ganz unbenommen davon ist es gut und richtig, über solche Fehler zu berichten. Und es ist gut und richtig, solche Fehler so schnell wie möglich zu korrigieren und nicht nur einmal im Monat.
     
  9. kalweit

    kalweit Hüter der Glaskugel

    Genau das nicht. Es kommt halt darauf an, was dieser DHCP Server ist und ob er angreifbar ist. In den letzten Jahren gab es ja mehr als eine Routerlücke, die den unautorisierten Fernzugriff erlaubte. Es gibt auch Geschichten, von auf dem Versandweg manipulierter Hardware. Was da tatsächlich dran ist, mag ich nicht beurteilen. Fakt ist, man kann Sicherheitslücken nicht mehr isoliert betrachten und spätestens seit bekannt ist, dass gewisse Institutionen selbst Supercomputer betreiben, um von Tante Trude Passwörter zu knacken, kann man den Kosten-/Nutzen Aspekt zur Risikobewertung vergessen.
     
  10. kazhar

    kazhar Viertel Gigabyte

    der shell-bug ist doch ein witz.

    ich muss also erstmal einen webserver haben, der scripte ausführt, diese scripte müssen fehlerhaft sein und irgendwelche aufgaben an die shell delegieren. dann kann jemand einen fehler in bash ausnutzen. . .

    toll, unter windows würde irgendwann in 1 jahr ein "empfohlenes" update anrauschen.
     
  11. root

    root Megabyte

    Es genügt, dass ein beliebiges Bash-Script per CGI vom Webserver ausgeführt wird, welches nicht einmal fehlerhaft sein muss. Dabei reicht es aus, eine entsprechende Anfrage an das Script zu schicken, um den Bug auszunutzen.
    Ein Webserver ist dabei nur einer von mehreren möglichen Angriffsvektoren, wie der von kalweit verlinkte Artikel zeigt.
     
  12. kalweit

    kalweit Hüter der Glaskugel

    Nein. Es reicht ein beliebiges Programm, welches Kommandos an die Shell übergibt. Wenn bei dir bash zufällig die Standardshell ist oder das Programm/Skript explizit diese "fordert", ist dein System anfällig für die Lücke. Was man letztlich damit anstellen kann, ergibt sich aus dem Rechtekontext von bash. Die diskutierten - wie der Weg über einen DHCP-Server - Szenarien beschäftigen sich ergänzend damit, wie man die Lücke ohne aktives Zutun des Nutzers ausnutzen und wie man sich ggf. sogar root-Rechte aneignen könnte. Unter welchen Umständen das funktioniert, ist ja gerade das, was man aktuell versucht herauszufinden. Dabei ist letztlich eine Lücke im DHCP-Client mit nach oben gespült worden.

    Kann man mit einem Windowspatch die Bashlücke schließen oder welchen Bezug hat das? Mir erschließt sich der Vergleich mit anderen Betriebssystemen nicht, wenn es um eine konkrete Sicherheitslücke geht.
     
Thread Status:
Not open for further replies.

Share This Page