Der Fehler sollte nicht unterschätzt werden. Zumindest wenn man mit einem Laptop unter wegs ist und sich in fremde Netze einklinkt oder wenn man einen Webserver betreibt, sollte man updaten. Die wichtigsten Distributionen haben bereits Updates herausgegeben. Wenn man sichergehen will, dass keine verwundbare Version der Bash mehr läuft, sollte man außerdem das System neu booten.
Ich kann mir nicht vorstellen, dass man diese Lücke sinnvoll ausnutzen kann. Wie sollte man durch einen Angriff eine Umgebungsvariable ändern?
Das einzige was mit einfällt ist, wenn jemand ein Shell Skript per cgi startet. Dann kann jemand in seinem Browser einfach () { ... als Parameter übergeben. Nur wird sowas ernsthaft eingesetzt?
Lässt sich sau einfach ausnützen bei CGI Servern. Ich hab unsere Server mit dem Tool getestet: shellshocker.sh Hatten keine Probleme. Aber einen einfachen Demo CGI Server konnte ich damit "erfolgreich" testen.
Bei git über ssh (wo man eigentlich keine Shell bekommen sollte sondern nur mit einen git Prozess am anderen Ende redet) soll es angeblich auch gehn (-> GitHub!).
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Sep 2014 um 04:39.
Von blubbermal am Do, 25. September 2014 um 15:32 #
Bin zwar kein Programmierer und wusste nicht mal das man in der Bash Shellfunktionen über Umgebungsvariablen einfügen kann.
Wer einen Webserver betreibt und per CGI auf die Bash zugreifen lässt, na ja, so wieso keine gute Idee... Per SSH kann man keine Shellfunktionen übergeben. Debian/Ubuntu sind wohl kaum betroffen, weil diese die Dash als Systemshell nutzen.
Ubuntu, Mageia, Gentoo, Suse sind schon mit Patches versorgt und auch steht es jedem frei, die C-Shell zu nutzen
Im LX-Terminal hatte das im Artikel erwähnte Skript mit der Ausgabe "vulnerable" angeschlagen. Nach dem Einspielen des Bash-Updates unterblieb diese Ausgabe.
Von irgendwer am So, 28. September 2014 um 19:07 #
Du verwendest ja sicherlich auch /bin/bash und nicht /bin/sh als Login-Shell.
Es verwenden alle Nutzer automatisch /bin/bash als login-Shell, wenn man dies nicht manuell umstellt (siehe /etc/passwd).
Für Scripte ohne shebang oder "#!/bin/sh" wird dash verwendet, für "#!/bin/bash" natürlich weiterhin bash. Es sind also nur Skripte angreifbar, die explizit die bash anfordern und darüber eine privilege escalation ermöglichen, also nicht mit den gleichen Nutzerrechten von einer interaktiven (lokalen) Shell aufgerufen werden.
Das mag sein. Es handelt sich hierbei aber um eine Wheezy-LXDE-Standardinstallation, die ich nachträglich nicht verändert habe.
Das Gleiche habe ich gerade mit einer Debian Squeeze-Gnome-Standardinstallation getestet, und zwar im Gnome-Terminal. Ergebnis: "vulnerable". Auch bei dieser Squeeze-Installation habe ich keine manuellen Änderungen an irgendwelchen Terminalprogrammen vorgenommen.
Was ich damit sagen möchte: Der Verweis darauf, dass Dash nicht betroffen sei, wiegt Debian-Nutzer wie mich, die keine Ahnung von Linux haben, unter Umständen in trügerischer Sicherheit. Von daher ist das, gemessen an der tatsächlichen Desktop-Realität, eine eher nicht so relevante Diskussion.
Von irgendwer am So, 28. September 2014 um 20:15 #
Eigentlich ist es umgekehrt: Die Diskussionen um die Lücke schrecken Desktop-Nutzer auf, die sowieso nicht betroffen sind.
Denn welchen (zusätzlichen) Angriffsweg bietet die Lücke? So real am Desktop keinen, wenn der Angreifer nicht eh schon irgendwie auf der Kiste drauf ist.
Gefährlich ist es für Maschinen, auf denen externe Angreifer Skriptaufrufe manipulieren können. Zum Beispiel das berühmte Apache-cgi, welches via GET/POST mit Env-Parametern gefüttert werden kann. Und besagtes cgi-Skript läuft unter Debian (im Gegensatz zur interaktiven shell) per default via dash, wenn es sich überhaupt um ein Shellscript und keine sonstige ausführbare Datei handelt.
Von blubbermal am Do, 25. September 2014 um 15:54 #
yum update und nun
~ $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: Warnung: x: ignoring function definition attempt bash: Fehler beim Importieren der Funktionsdefinition für `x'. this is a test
Bash scheint ein ziemlicher Grauß zu sein. Der Code geht immer noch:
env X='() { (a)=>\' sh -c "echo date"; cat echo
Hab's aber nicht geschafft auf basis diesen Codes meinen Demo CGI Server positiv zu testen. D.h. heißt aber nicht, dass das niemand anders auch nicht kann.
Nein, ich verwende Fedora und mit dem ersten Code *konnte* ich einen CGI Server exploiten. (Nicht das ich das tun will, ich habs nur getestet um zu sehn ob ich angreifbar bin - was ich leider gewesen währe, hätte ich einen Server über das Internet zugreifbar gemacht.) Ich hab früher mal KUbuntu verwendet, welches dash als /bin/sh verwendet. Da sind hinten und vorne viele Skripte die falscher weiße /bin/sh statt /bin/bash angeben auf die kryptischte Art abgestürzt (mit 100% CPU last und so). Also wegen solchen buggy Skripten ist das auch nicht das Wahre.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Sep 2014 um 15:38.
Der Fehler sollte nicht unterschätzt werden. Zumindest wenn man mit einem Laptop unter wegs ist und sich in fremde Netze einklinkt oder wenn man einen Webserver betreibt, sollte man updaten. Die wichtigsten Distributionen haben bereits Updates herausgegeben. Wenn man sichergehen will, dass keine verwundbare Version der Bash mehr läuft, sollte man außerdem das System neu booten.
Ich kann mir nicht vorstellen, dass man diese Lücke sinnvoll ausnutzen kann. Wie sollte man durch einen Angriff eine Umgebungsvariable ändern?
Das einzige was mit einfällt ist, wenn jemand ein Shell Skript per cgi startet. Dann kann jemand in seinem Browser einfach () { ... als Parameter übergeben. Nur wird sowas ernsthaft eingesetzt?
Lässt sich sau einfach ausnützen bei CGI Servern. Ich hab unsere Server mit dem Tool getestet: shellshocker.sh
Hatten keine Probleme. Aber einen einfachen Demo CGI Server konnte ich damit "erfolgreich" testen.
Bei git über ssh (wo man eigentlich keine Shell bekommen sollte sondern nur mit einen git Prozess am anderen Ende redet) soll es angeblich auch gehn (-> GitHub!).
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Sep 2014 um 04:39.Bin zwar kein Programmierer und wusste nicht mal das man in der Bash Shellfunktionen über Umgebungsvariablen einfügen kann.
Wer einen Webserver betreibt und per CGI auf die Bash zugreifen lässt, na ja, so wieso keine gute Idee...
Per SSH kann man keine Shellfunktionen übergeben.
Debian/Ubuntu sind wohl kaum betroffen, weil diese die Dash als Systemshell nutzen.
Ubuntu, Mageia, Gentoo, Suse sind schon mit Patches versorgt und auch steht es jedem frei, die C-Shell zu nutzen
Per SSH kann man keine Shellfunktionen übergeben. ... außer die in der Config definierten locale
Die Dash????
Meinste nicht, mir war so?
Habe gerade kein Deb* bei der Hand, führe doch mal ein ls -l /bin/sh aus.
Also das Testscript aus dem Artikel schlägt jedenfalls unter Ubuntu 12.04 an, trotz "dash".
Weit du überhaupt, was du tust?
Wenn du das System, welches die Dash benutzt auf Bash testest, was soll da für ein Ergebnis herauskommen?
Ich verwende LX-Terminal unter Debian Wheezy.
Im LX-Terminal hatte das im Artikel erwähnte Skript mit der Ausgabe "vulnerable" angeschlagen. Nach dem Einspielen des Bash-Updates unterblieb diese Ausgabe.
Du verwendest ja sicherlich auch /bin/bash und nicht /bin/sh als Login-Shell.
Es verwenden alle Nutzer automatisch /bin/bash als login-Shell, wenn man dies nicht manuell umstellt (siehe /etc/passwd).
Für Scripte ohne shebang oder "#!/bin/sh" wird dash verwendet, für "#!/bin/bash" natürlich weiterhin bash. Es sind also nur Skripte angreifbar, die explizit die bash anfordern und darüber eine privilege escalation ermöglichen, also nicht mit den gleichen Nutzerrechten von einer interaktiven (lokalen) Shell aufgerufen werden.
Das mag sein. Es handelt sich hierbei aber um eine Wheezy-LXDE-Standardinstallation, die ich nachträglich nicht verändert habe.
Das Gleiche habe ich gerade mit einer Debian Squeeze-Gnome-Standardinstallation getestet, und zwar im Gnome-Terminal. Ergebnis: "vulnerable". Auch bei dieser Squeeze-Installation habe ich keine manuellen Änderungen an irgendwelchen Terminalprogrammen vorgenommen.
Was ich damit sagen möchte: Der Verweis darauf, dass Dash nicht betroffen sei, wiegt Debian-Nutzer wie mich, die keine Ahnung von Linux haben, unter Umständen in trügerischer Sicherheit. Von daher ist das, gemessen an der tatsächlichen Desktop-Realität, eine eher nicht so relevante Diskussion.
Eigentlich ist es umgekehrt: Die Diskussionen um die Lücke schrecken Desktop-Nutzer auf, die sowieso nicht betroffen sind.
Denn welchen (zusätzlichen) Angriffsweg bietet die Lücke? So real am Desktop keinen, wenn der Angreifer nicht eh schon irgendwie auf der Kiste drauf ist.
Gefährlich ist es für Maschinen, auf denen externe Angreifer Skriptaufrufe manipulieren können. Zum Beispiel das berühmte Apache-cgi, welches via GET/POST mit Env-Parametern gefüttert werden kann. Und besagtes cgi-Skript läuft unter Debian (im Gegensatz zur interaktiven shell) per default via dash, wenn es sich überhaupt um ein Shellscript und keine sonstige ausführbare Datei handelt.
yum update und nun
~ $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: Warnung: x: ignoring function definition attempt
bash: Fehler beim Importieren der Funktionsdefinition für `x'.
this is a test
Bash scheint ein ziemlicher Grauß zu sein. Der Code geht immer noch:
env X='() { (a)=>\' sh -c "echo date"; cat echo
Hab's aber nicht geschafft auf basis diesen Codes meinen Demo CGI Server positiv zu testen. D.h. heißt aber nicht, dass das niemand anders auch nicht kann.
Siehe:
https://twitter.com/taviso/status/514887394294652929
http://blog.fefe.de/?ts=aadd0ab6
Vielleich hast Du Debian oder Ubuntu und die CGI ausführende Shell ist gar nicht die Bash?
Nein, ich verwende Fedora und mit dem ersten Code *konnte* ich einen CGI Server exploiten. (Nicht das ich das tun will, ich habs nur getestet um zu sehn ob ich angreifbar bin - was ich leider gewesen währe, hätte ich einen Server über das Internet zugreifbar gemacht.) Ich hab früher mal KUbuntu verwendet, welches dash als /bin/sh verwendet. Da sind hinten und vorne viele Skripte die falscher weiße /bin/sh statt /bin/bash angeben auf die kryptischte Art abgestürzt (mit 100% CPU last und so). Also wegen solchen buggy Skripten ist das auch nicht das Wahre.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Sep 2014 um 15:38.