Sie müssen bash nicht explizit verwenden, damit dies ein Problem darstellt. Das eigentliche Problem besteht darin, dass Angreifer den Wert von Umgebungsvariablen mitbestimmen können. Nachdem die Umgebung festgelegt wurde, ist es nur eine Frage der Zeit, bis eine Shell (möglicherweise unbekannt) in einer Umgebung ausgeführt wird, für die sie nicht vorbereitet wurde.
Jedes Programm (bash, java, tcl, php, ...) hat diese Signatur:
int main (int argc, char ** argv, char ** arge);
Entwickler haben die Angewohnheit, argc und argv auf Sauberkeit zu überprüfen. Die meisten ignorieren arge und machen keinen Versuch, es zu validieren, bevor sie Subshells erzeugen (explizit oder implizit). Und in diesem Fall verteidigt sich bash nicht richtig gegen schlechte Eingaben. Um eine Anwendung miteinander zu verbinden, werden Unterprozesse erzeugt. Im Grunde passiert Folgendes:
// Wir haben die Binärdatei fest codiert und das Argument bereinigt, sodass wir davon ausgehen, dass // keine böswillige Eingabe erfolgen kann - sondern die aktuelle Umgebung wird // in implicitly.execl übergeben ("/ bin / bash", "bash", "-c", "/ opt / initTech / bin / dataScrape", cleanArg, NULL);
In Ihrem eigenen Code gibt es möglicherweise keine Verweise auf bash. Aber vielleicht starten Sie tcl und etwas tief im tcl-Code startet Bash für Sie. Es würde die Umgebungsvariablen erben, die derzeit festgelegt sind.
Im Fall der anfälligen Version von bash geschieht Folgendes:
int main (int argc, char ** argv, char ** arge) {// Hauptfunktion von bash .... parseEnvironment (arge); // !!!! Funktionsdefinitionen lesen und var definiert .... doArgv (argc, argv); ....}
Wobei parseEnvironment eine Reihe von Umgebungsvariablendefinitionen sieht, die es nicht unbedingt erkennt. Es wird jedoch erraten , dass einige dieser Umgebungsvariablen Funktionsdefinitionen sind:
INITTECH_HOME = / opt / initTechHTTP_COOKIE = () {:; }; / usr / bin / eject
Bash hat keine Ahnung, was ein HTTP_COOKIE ist. Aber es beginnt mit (), also bash vermutet , dass dies eine Funktionsdefinition ist. Außerdem können Sie nach der Funktionsdefinition sofort ausgeführten Code hinzufügen, da Sie möglicherweise einige Nebenwirkungen mit Ihrer Funktionsdefinition initialisieren müssen. Der Patch entfernt die Möglichkeit, nach der Funktionsdefinition Nebenwirkungen hinzuzufügen.
Aber die ganze Idee, dass eine Umgebungsvariable mit der vom Angreifer bereitgestellten Funktionsdefinition inaktiv sein kann, ist immer noch sehr beunruhigend!
recieve = '() {Echo, das Sie empfangen wollten lol; } '
Wenn der Angreifer veranlassen kann, dass dieser Variablenname einen von ihm angegebenen Wert erhält, und auch weiß, dass er warten kann, bis ein Bash-Unterprozess versucht, eine Funktion mit diesem Namen aufzurufen, dann wäre dies ein weiterer Angriffsvektor.
Dies ist nur die alte Ermahnung, Ihre Eingaben zu validieren . Da Shells möglicherweise als überraschendes Implementierungsdetail erzeugt werden, setzen Sie nie eine Umgebungsvariable auf einen Wert, der nicht streng validiert ist. Das bedeutet, dass jedes mögliche Programm, das diese Umgebungsvariable liest, mit dem Wert nichts Unerwartetes macht. wie es als Code ausführen.
Heute ist es Bash. Morgen ist es Java, Sh, Tcl oder Node. Sie alle nehmen einen Umgebungszeiger in ihre Hauptfunktion auf; und sie alle haben unterschiedliche Einschränkungen hinsichtlich der sicheren Handhabung (bis sie gepatcht sind).