Wie wurde die Shellshock Bash-Sicherheitslücke entdeckt?

Question

Um ein paar zu beruhigen: Ich habe den Fehler nicht durch das Beobachten von Exploits gefunden und habe keinen Grund zu der Annahme, dass er vor seiner Bekanntgabe ausgenutzt wurde (obwohl ich das natürlich nicht ausschließen kann). Ich habe ihn bashauch nicht gefunden, als ich mir den Code angesehen habe.

Ich kann nicht sagen, dass ich mich genau an meine damaligen Gedanken erinnere.

Das kam mehr oder weniger von einigen Überlegungen zu einigen Verhaltensweisen einiger Software, die ich findegefährlich(das Verhalten, nicht die Software). Die Art von Verhalten, die Sie denken lässt:das klingt nicht nach einer guten Idee.

In diesem Fall habe ich über die allgemeine Konfiguration von SSH nachgedacht, die es erlaubt, Umgebungsvariablen unbereinigt vom Client zu übergeben, sofern ihr Name mit beginnt LC_. Die Idee dahinter ist, dass Benutzer weiterhin ihre eigene Sprache verwenden können, wenn sie sshsich mit anderen Maschinen verbinden. Eine gute Idee, bis man darüber nachdenkt, wie komplex die Lokalisierungshandhabung ist, insbesondere wenn UTF-8 in die Gleichung einbezogen wird (und wenn man sieht, wie schlecht viele Anwendungen damit umgehen).

Bereits im Juli 2014 hatte ich über eine Schwachstelle in der Lokalisierungsbehandlung von glibc berichtet, die in Kombination mit dieser sshd Konfigurationzwei anderegefährliches Verhaltender bashSchale ermöglichte (authentifizierten) Angreifern, sich in Git-Server einzuhacken, vorausgesetzt, sie konnten dort Dateien hochladen und bashwurde als Login-Shell des Git-Unix-Benutzers verwendet (CVE-2014-0475).

Ich dachte, es wäre wahrscheinlich keine gute Idee, es bashals Login-Shell für Benutzer zu verwenden, die Dienste über SSH anbieten, da es sich um eine ziemlich komplexe Shell handelt (wobei man nur eine sehr einfache Befehlszeile analysieren muss) und die meisten Fehlkonstruktionen von KSH geerbt hat. Da ich bereits einige Probleme bei der bashVerwendung in diesem Kontext (zum Interpretieren von SSH-Befehlen ForceCommand) festgestellt hatte, fragte ich mich, ob es möglicherweise noch mehr gibt.

AcceptEnv LC_*erlaubt jede Variable, deren Name mit beginnt LC_, und ich hatte die vage Erinnerung, dassbash Exportierte Funktionen(Agefährlichwenn auch zu einem Zeitpunkt nützliches Feature) verwendeten Umgebungsvariablen mit einem Namen wie diesem myfunction()und fragte sich, ob es da nicht etwas Interessantes zu sehen gab.

Ich war kurz davor, es mit der Begründung abzulehnen, dass das Schlimmste, was man tun könnte, die Neudefinition eines Befehls namens wäre, LC_something was kein wirkliches Problem sein könnte, da es sich dabei nicht um existierende Befehlsnamen handelt, aber dann begann ich mich zu fragen, wiebash importiertdiese Umgebungsvariablen.

Was wäre, wenn die Variablen LC_foo;echo test; f()beispielsweise aufgerufen würden? Also beschloss ich, mir das genauer anzusehen.

A:

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

zeigte sich, dass meine Erinnerung falsch war, da die Variablen nicht aufgerufen wurden, myfunction()sondern myfunction(und es ist die Wertdas mit beginnt ()).

Und ein kurzer Test:

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

bestätigte meinen Verdacht, dass der Variablenname nicht bereinigt wurde und der Code ausgewertet wurdebeim Start.

Schlimmer, viel schlimmer, dieWertwurde auch nicht bereinigt:

$ env 'foo=() { :;}; echo test' bash -c :
test

Das bedeutete, dassbeliebigUmgebungsvariable könnte ein Vektor sein.

Da wurde mir das Ausmaß des Problems bewusst, ich bestätigte, dass es auch über HTTP ( HTTP_xxx/ QUERYSTRING... Umgebungsvariablen), andere Methoden wie E-Mail-Verarbeitungsdienste und später DHCP (und wahrscheinlich eine lange Liste) ausnutzbar war, und meldete es (vorsichtig).

Answer 1