Ist meine Bash anfällig?
Dieser einfache Befehl ist ein ausreichender Test, um festzustellen, ob Ihre Version von Bash anfällig ist:
x = '() {:; }; echo VULNERABLE 'bash -c:
Es muss kein zusätzlicher Text gedruckt werden, um anzuzeigen, dass der Befehl tatsächlich ausgeführt wurde, da gepatchte Versionen von bash eine Warnung melden, wenn eine Variable gestartet wird Die Umgebung enthält Exploit-Code für die gepatchte Sicherheitsanfälligkeit.
Auf einem anfälligen System:
$ x = '() {:;}; echo VULNERABLE 'bash -c: VULNERABLE
Auf einem gepatchten System:
$ x =' () {:;}; echo VULNERABLE 'bash -c: bash: Warnung: x: Ignorieren der Funktionsdefinition trybash: Fehler beim Importieren der Funktionsdefinition für `x'
Für eine detaillierte Erklärung dessen, was dies tut und tut Nicht testen und warum, siehe "Andere Funktionsanalysefehler" weiter unten.
Ist mein System anfällig?
Wenn Ihre Bash nicht anfällig ist, ist Ihr System nicht anfällig Nicht anfällig.
Wenn Ihre Bash anfällig ist, ist Ihr System insofern anfällig, als es Bash entlang von Angriffsvektoren wie CGI-Skripten, DHCP-Clients und eingeschränkten SSH-Konten verwendet. Überprüfen Sie, ob / bin / sh bash oder eine andere Shell ist. Die Sicherheitsanfälligkeit liegt in einer Bash-spezifischen Funktion, und andere Shells wie dash und ksh sind nicht betroffen. Sie können die Standard-Shell testen, indem Sie denselben Test wie oben mit sh anstelle von bash ausführen:
x = '() {: ;}; echo VULNERABLE 'sh -c:
- Wenn Sie eine Fehlermeldung sehen, hat Ihr System einen gepatchten Bash und ist nicht anfällig.
- Wenn Sie Siehe
VULNERABLE , dann ist die Standard-Shell Ihres Systems bash und alle Angriffsvektoren sind ein Problem. - Wenn Sie keine Ausgabe sehen, ist die Standard-Shell Ihres Systems nicht bash und nur Teile Ihres Systems, die Bash verwenden, sind anfällig. Suchen Sie nach:
- Skripten, die von bash (beginnend mit
#! / Bin / bash , nicht #! / Bin / sh ) von CGI oder von a ausgeführt werden DHCP-Client.
- Eingeschränkte SSH-Konten, deren Shell bash ist.
Funktionsweise dieses Tests
Der Befehl bash -c: mit dem wörtlichen Text () {:;}; echo VULNERABLE wird als Wert der Umgebungsvariablen x festgelegt.
Der integrierte Code : wird ausgeführt keine Aktion; Es wird hier verwendet, wenn ein nicht leerer Befehl erforderlich ist.
bash -c: erstellt eine Instanz von bash, die : ausführt Code> und wird beendet.
Auch dies reicht aus, um die Sicherheitsanfälligkeit auszulösen. Obwohl bash aufgerufen wird, um nur einen Befehl auszuführen (und dieser Befehl ist ein No-Op), liest es dennoch seine Umgebung und interpretiert jede Variable, deren Inhalt mit () { beginnt, als Funktion (at Zumindest diejenigen, deren Namen gültige Funktionsnamen sind) und führen sie aus, damit die Funktion definiert wird.
Die Absicht hinter diesem Verhalten von bash besteht darin, nur eine Funktionsdefinition auszuführen, die eine Funktion zur Verwendung zur Verfügung stellt, dies jedoch nicht tut Führen Sie den darin enthaltenen Code nicht aus.
() {:;} ist die Definition für eine Funktion, die beim Aufruf keine Aktion ausführt. Nach { ist ein Leerzeichen erforderlich, damit { als separates Token analysiert wird. Vor } ist ein ; oder newline erforderlich, damit er als korrekte Syntax akzeptiert wird.
Siehe 3.3 Shell-Funktionen im Bash-Referenzhandbuch finden Sie weitere Informationen zur Syntax zum Definieren von Shell-Funktionen in bash. Beachten Sie jedoch, dass die von bash als gültige exportierte Shell-Funktion verwendete (und erkannte) Syntax restriktiver ist, deren Definition ausgeführt werden sollte:
- Sie muss mit der genauen Zeichenfolge
() {beginnen mit genau einem Leerzeichen zwischen ) und {.
- Während bei Shell-Funktionen gelegentlich die zusammengesetzte Anweisung in
() anstelle von {} eingeschlossen ist, werden sie dennoch in die Syntax {} exportiert . Variablen, deren Inhalt mit () ( anstelle von () { beginnt, testen die Sicherheitsanfälligkeit nicht oder lösen sie auf andere Weise aus. ol>
bash sollte die Ausführung von Code nach dem Schließen von } beenden. Dies ist jedoch (sofern nicht gepatcht) nicht der Fall! Dies ist das falsche Verhalten, das CVE ausmacht -2014-6271 ("Shellshock").
; beendet die Anweisung, die die Funktion definiert, sodass nachfolgender Text als separater Befehl gelesen und ausgeführt werden kann. Und der Text nach ; muss keine andere Funktionsdefinition sein - er kann alles sein.
In diesem Test lautet der Befehl nach ; echo VULNERABLE . Das führende Leerzeichen vor echo führt nichts aus und ist nur zur besseren Lesbarkeit vorhanden Der Befehl code> echo schreibt Text in die Standardausgabe. Das vollständige Verhalten von echo ist eigentlich etwas kompliziert, aber das ist hier unwichtig: echo VULNERABLE ist einfach . Es wird der Text VULNERABLE angezeigt.
Da echo VULNERABLE nur ausgeführt wird, wenn bash nicht gepatcht ist und Code nach Funktionsdefinitionen in Umgebungsvariablen ausgeführt wird, dies (und viele andere ähnliche Tests) ist ein effektiver Test, ob die installierte bash für CVE-2014-6271 anfällig ist oder nicht.
Fehler beim Parsen anderer Funktionen (und warum dieser Test und solche, die ihn mögen, nicht nach ihnen suchen)
Der zum Zeitpunkt dieser Veröffentlichung veröffentlichte Patch und die oben beschriebenen und erläuterten Befehle zur Überprüfung der Sicherheitsanfälligkeit gelten für den sehr schwerwiegenden Fehler CVE-2014-6271. Weder dieser Patch noch die oben beschriebenen Befehle zum Überprüfen der Sicherheitsanfälligkeit gelten für den zugehörigen Fehler CVE-2014-7169 (und es sollte auch nicht angenommen werden, dass sie für andere Fehler gelten, die möglicherweise noch nicht entdeckt oder offengelegt wurden).
Der Fehler CVE-2014-6271 ist auf eine Kombination von zwei Problemen zurückzuführen:
- bash akzeptiert Funktionsdefinitionen in beliebigen Umgebungsvariablen und
- Währenddessen führt bash weiterhin Code aus, der nach der schließenden Klammer (
} ) einer Funktionsdefinition vorhanden ist. ol> Zum jetzigen Zeitpunkt der vorhandene Fix für CVE-2014-6271, der veröffentlicht wurde (und von vielen nachgeschalteten Anbietern eingeführt wurde), dh der Fix, den Sie durch Aktualisieren Ihres Systems oder durch Anwenden des vorhandenen Patches erhalten würden manuell - ist eine Korrektur für 2 2 .
Aber bei anderen Fehlern im Bash-Code 1 ist möglicherweise eine Quelle für viele zusätzliche Analysefehler. Und wir wissen , dass mindestens ein weiterer solcher Fehler vorliegt - insbesondere CVE-2014-7169.
Der in dieser Antwort dargestellte Befehl prüft, ob oder nicht, eine installierte Bash wird mit dem vorhandenen (dh ersten offiziellen) Fix für CVE-2014-6271 gepatcht. Es testet die Anfälligkeit für diesen bestimmten Parsing-Fehler: "GNU Bash through 4.3 verarbeitet nachfolgende Funktionszeichenfolgen in den Werten von Umgebungsvariablen [...]"
Dieser spezifische Fehler ist extrem schwerwiegend - und der verfügbare Patch behebt das Problem - während CVE-2014-7169 weniger schwerwiegend zu sein scheint, aber definitiv immer noch Anlass zur Sorge gibt.
Wie Stéphane Chazelas ( Entdecker des Shellshock-Fehlers) kürzlich in einer Antwort auf erklärt hat, wann der Shellshock (CVE) war -2014-6271) Fehler eingeführt, und was ist der Patch, der ihn vollständig behebt? unter Unix.SE:
Es gibt einen Patch, der dies verhindert bash von der Interpretation anderer Elemente als der darin enthaltenen Funktionsdefinition ( https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html), und das wurde in allen Sicherheitsupdates der verschiedenen Linux-Distributionen angewendet.
Bash interpretiert den Code dort jedoch immer noch und jeder Fehler im Interpreter könnte ausgenutzt werden. Ein solcher Fehler wurde bereits gefunden (CVE-2014-7169), obwohl seine Auswirkungen viel geringer sind. In Kürze wird es also einen weiteren Patch geben.
Aber wenn der Exploit so aussieht ...
Einige Leute haben hier und anderswo gefragt, warum x = '() {:;}; echo VULNERABLE 'bash -c: Drucken VULNERABLE (oder ähnlich) sollte als alarmierend angesehen werden. Und ich habe kürzlich das Missverständnis gesehen, dass Shellshock keine ernsthafte Sicherheitslücke sein darf, da Sie bereits über einen interaktiven Shell-Zugriff verfügen müssen, um diesen bestimmten Befehl einzugeben und die Eingabetaste zu drücken.
Obwohl einige der Gefühle, die ich gehört habe - dass wir nicht in Panik geraten sollten, dass Desktop-Benutzer hinter NAT-Routern ihr Leben nicht auf Eis legen sollten, um Bash aus Quellcode zu erstellen - ganz richtig und verwirrend sind Die Sicherheitsanfälligkeit selbst mit der Fähigkeit, sie durch Ausführen eines bestimmten Befehls zu testen (wie der hier vorgestellte Befehl) ist ein schwerwiegender Fehler.
Der in diesem Beitrag angegebene Befehl ist eine Antwort auf die Frage: "Gibt es einen kurzen Befehl zum Testen, ob mein Server gegen den Shellshock-Bash-Fehler sicher ist?" Es ist keine Antwort auf "Wie sieht Shellshock aus, wenn es von einem echten Angreifer gegen mich eingesetzt wird?" und es ist keine Antwort auf die Frage "Was muss jemand tun, um diesen Fehler erfolgreich auszunutzen?" (Und es ist auch keine Antwort auf "Ist Gibt es einen einfachen Befehl, um aus allen technischen und sozialen Faktoren abzuleiten, wenn ich persönlich einem hohen Risiko ausgesetzt bin? ")
Dieser Befehl ist ein Test, um festzustellen, ob bash geschriebenen Code auf eine bestimmte Weise ausführt. in beliebigen Umgebungsvariablen. Die Shellshock-Sicherheitsanfälligkeit ist nicht x = '() {:;}; echo VULNERABLE 'bash -c: . Stattdessen ist dieser Befehl (und andere, die ihn mögen) eine Diagnose , um festzustellen, ob einer von Shellshock betroffen ist.
- Shellshock hat weitreichende Konsequenzen, obwohl das Risiko für Desktop-Benutzer, die keine remote zugänglichen Netzwerkserver ausführen, mit ziemlicher Sicherheit geringer ist. (Wie viel weniger ist etwas, von dem ich glaube, dass wir es derzeit nicht wissen.)
- Im Gegensatz dazu ist der Befehl
x = ' () {:;}; echo VULNERABLE 'bash -c: ist völlig belanglos, außer insoweit, als es zum Testen auf Shellshock (speziell für CVE-2014-6271) nützlich ist.
Für diejenigen, die es sind Interessanterweise finden Sie hier einige Ressourcen mit Informationen darüber, warum dieser Fehler als schwerwiegend eingestuft wird und warum Umgebungsvariablen, insbesondere auf Netzwerkservern, möglicherweise nicht vertrauenswürdige Daten enthalten, die den Fehler ausnutzen und Schaden anrichten können:
Angriffsszenarien der neuen Bash-Sicherheitsanfälligkeit CVE-2014-6271 Beispiel für eine Bash-Sicherheitsanfälligkeit Kasperd's antworte auf Was bedeutet env x = '() {:;}; Befehl 'bash do und warum ist es unsicher? Wie schwer ist der neue Bash-Exploit (Shellshock)? Um die konzeptionelle Unterscheidung hier weiter zu veranschaulichen, betrachten Sie zwei Hypothesen:
-
Stellen Sie sich vor, anstatt x = '() {:;} vorzuschlagen; echo VULNERABLE 'bash -c: als Test, ich hatte bash --version als Test vorgeschlagen. (Dies wäre eigentlich nicht besonders geeignet, da Betriebssystemanbieter Sicherheitspatches häufig auf ältere Softwareversionen zurückportieren. Die Versionsinformationen, die ein Programm Ihnen gibt, können auf einigen Systemen den Eindruck erwecken, dass das Programm anfällig wäre, wenn es tatsächlich vorhanden wäre gepatcht.)
Wenn Tests durch Ausführen von bash --version vorgeschlagen würden, würde niemand sagen: "Aber Angreifer können nicht an meinem Computer sitzen und bash eingeben --version , also muss es mir gut gehen! " Dies ist die Unterscheidung zwischen einem Test und dem Problem, auf das getestet wird.
-
Stellen Sie sich vor, ein Hinweis würde darauf hinweisen, dass Ihr Auto möglicherweise ein Sicherheitsproblem hat, z. B. einen Airbagfehler oder ein Platzen bei einer Kollision in Flammen aufgegangen, und diese Fabrikdemonstrationen waren gestreamt worden. Niemand würde sagen: "Aber ich würde niemals versehentlich mein Auto 900 Meilen zur Fabrik fahren oder schleppen und es mit einer teuren Crash-Puppe beladen und gegen eine Betonwand knallen lassen. Also muss es mir gut gehen!" Dies ist die Unterscheidung zwischen einem Test und dem Problem, auf das getestet wird.
ol>