Frage:
Gibt es einen kurzen Befehl zum Testen, ob mein Server gegen den Shellshock-Bash-Fehler sicher ist?
kqw
2014-09-25 16:24:08 UTC
view on stackexchange narkive permalink

Ich habe apt-get update durchgeführt. apt-get upgrade -y auf allen Systemen, die ich verwende. Ich bin mir nicht sicher, ob meine /etc/apt/sources.list auf all diesen Systemen gut genug ist. Ich möchte jedes System schnell noch einmal überprüfen, idealerweise mit einem einzeiligen Shell-Befehl.

Gibt es einen solchen einzeiligen Shell-Befehl und wenn ja, was ist das?

Beachten Sie, dass es sich bei dieser Frage hauptsächlich um CVE-2014-6271 handelt.

bash --version Der Bug bewirkt Versionen von bash bis einschließlich 4.3
@raz Das Überprüfen der Bash-Version ist nutzlos (außer dass Versionen nach 4.3, die noch nicht existieren, nicht betroffen sind). Die meisten Systeme beheben das Loch, indem sie nur das Loch patchen (normalerweise durch Anwenden des normalen Aktualisierungsprozesses ihrer Distribution) und nicht durch Aktualisieren auf eine völlig neue Version von Bash (die wiederum noch nicht existiert).
@Gilles `bash --version` meldet eine Versionsnummer wie` 4.3.25` (dies ist der Patch, der die anfängliche, wenn auch nicht die vollständige Shell Shock-Sicherheitsanfälligkeit behebt). Es gibt keinen Grund zu der Annahme, dass eine Version auf Patch-Ebene das Problem weniger vollständig beheben kann als eine zukünftige Version 4.4.
@chepner ... genau deshalb ist die Überprüfung der Versionsnummer nutzlos. Bei den meisten Distributionen ändert das Upgrade, das das Loch behebt, die Versionsnummer nicht. Die anfällige Version und die feste Version haben dieselbe Versionsnummer. Sie können damit nicht feststellen, ob die Sicherheitsanfälligkeit vorliegt.
Ich wäre ein wenig verärgert, wenn meine Distribution den Code patchen würde, ohne die Versionsnummer * überhaupt * zu erhöhen.
@chepner: warum? Es gibt einen Unterschied zwischen der vom Programm gemeldeten Version und der Paketversion. Nun, es kann sein, sagen wir es so.
Ja, aber das Paket kann anhand der Revisionsstufen eine Abweichung vom Upstream anzeigen. Wenn der Paketmanager beschließt, eine Version von `bash` 4.3.25 zusammen mit eigenen Patches zu versenden, sollte die Paketversion ungefähr 4.3.25-1.0, 4.3.25-1.1 usw. sein, * nicht * 4.3.26, 4.3.27 oder schlechter, 4.3.25, 4.3.25 mit * keiner * Versionsänderung. Das Ändern der Paketversion ist eine Sache; Das Versionsschema des Upstreams (zumindest eines vernünftigen Upstreams) ist ein weiteres. Der ganze * Punkt * einer Versionsnummer soll Änderungen im zugrunde liegenden Code anzeigen.
Sechs antworten:
#1
+124
Eliah Kagan
2014-09-25 18:43:04 UTC
view on stackexchange narkive permalink

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:

    1. Sie muss mit der genauen Zeichenfolge () {beginnen mit genau einem Leerzeichen zwischen ) und {.
    2. 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.
    3. 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:

    1. bash akzeptiert Funktionsdefinitionen in beliebigen Umgebungsvariablen und
    2. Währenddessen führt bash weiterhin Code aus, der nach der schließenden Klammer (} ) einer Funktionsdefinition vorhanden ist.
    3. 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:

    1. 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.

    2. 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.

    3. ol>
    Hmm, aber wenn ich bash ausführen kann, kann ich dann nicht schon beliebige Befehle auf einem System ausführen? Wie ist das eine Schwachstelle?
    @Ajedi32 `x = '() {:;}; echo VULNERABLE 'bash -c: `ist ein Test, um festzustellen, ob Ihre Bash gepatcht ist. Der Grund, warum CVE-2014-6271 überhaupt vulgär ist, besteht darin, dass es jedem die Möglichkeit gibt, beliebige Befehle auszuführen, der den Wert einer Umgebungsvariablen festlegen kann (unter Bedingungen, unter denen eine Bash dann mit dieser Variablen ausgeführt wird). Umgebungsvariablen werden häufig verwendet, um nicht bereinigte, vom Benutzer bereitgestellte Daten zwischen Prozessen zu übertragen. Beispiel: * Dies kann häufig über HTTP ausgenutzt werden. * Siehe http://seclists.org/oss-sec/2014/q3/650 unter "Bisher wurden HTTP-Anforderungen an CGI-Skripte als Hauptangriffsvektor identifiziert."
    @Ajedi32 `/ bin / sh -c` wird häufig zum Starten von untergeordneten Prozessen verwendet. Wenn die Umgebung von einem Angreifer gesteuert werden kann, liegt ein Problem vor. Der häufigste Fall ist ein Webserver, der die Umgebung als eine Form von [IPC] verwendet (http://en.wikipedia.org/wiki/Inter-process_communication) Ausführen eines CGI-Skripts.
    @mr.spuratic Ihr Beispiel ist `/ bin / sh -c`, was nicht` bash` ist, sondern nur der grundlegende Vanille-Shell-Prozess. Ich bekomme hier also immer noch nicht das wahre Risiko. Zugegeben, dies ist alles unbeabsichtigte Verwendung. Wenn der Benutzer jedoch keine erhöhten Berechtigungen erhalten kann, die über den übergeordneten Prozess hinausgehen, besteht das Risiko, was genau?
    Wenn bash nicht die Standard-Shell ist, wäre es dann nicht einfacher, den folgenden Oneliner zu verwenden: bash -c "env x = '() {:;}; echo verwundbar' bash -c echo dies ist ein Test"?
    @JakeGould Das Schlimmste an dieser Sicherheitsanfälligkeit ist, dass Sie zum Ausnutzen überhaupt kein Konto benötigen. Selbst wenn (zum Beispiel) Ihr Webserver unter einem streng eingeschränkten Benutzerkonto ausgeführt wird, wäre es für einen Angreifer sehr schlecht, beliebige Befehle als dieser eingeschränkte Benutzer ausführen zu können und Ihren Webserver (und mehr) vollständig zu steuern. Siehe [die Erklärung hier] (http://seclists.org/oss-sec/2014/q3/650). Die bequemsten Möglichkeiten, eine Sicherheitsanfälligkeit zu testen, haben nicht immer dieselbe Form wie die verheerendsten Möglichkeiten, sie in freier Wildbahn auszunutzen.
    @JakeGould Es ist wahr, "sh" ist nur manchmal "bash". Dies kann das Risiko / den Schaden etwas mindern. Aber selbst wenn nicht das System sh, wird bash häufig für Skripte verwendet, sodass eine beliebige Codeausführung immer noch möglich ist. Befehle nach einer Funktionsdefinition in einer Umgebungsvariablen werden ausgeführt, wenn ein Bash-Skript ausgeführt wird (da das Ausführen eines Bash-Skripts, insbesondere von einer Shell oder einem anderen Prozess, der kein Bash ist, das Ausführen der ausführbaren Bash-Datei zur Interpretation umfasst). Der Grad des Risikos für Desktop-Benutzer ist unbekannt, aber böswillige Daten (z. B. speziell gestaltete Dateien), die per Bash verarbeitet werden, sind immer noch ein Risiko.
    @somelooser28533 Der Aufrufer muss nicht auf "env x =" () {:;}; echo verwundbares 'bash -c' echo ... '`, nur eine beliebige [Bourne-Style (POSIX) Shell] (https://en.wikipedia.org/wiki/Unix_shell#Bourne_shell_compatible) oder eine andere Shell, die` VARIABLE akzeptiert = Befehlssyntax value`. Mit `env` kann die Shell so gut wie alles sein, weshalb [der Test, den BadSkillz zitiert] (http://security.stackexchange.com/a/68169) sie verwendet. `sh -c" env x = '() {:;}; echo anfälliges' bash -c 'echo ...' "`, ob sh bash ist oder nicht, funktioniert auch. Selbst in einer Shell ohne Bourne-Stil benötigen Sie nicht sowohl "env" als auch "sh-c".
    @EliahKagan Ich sehe das Risiko für Server unter bestimmten Bedingungen, aber wenn Sie sich beispielsweise Mac-Benutzerforen ansehen, besteht diese absolute Panik, dass Mac OS X auf Client-Ebene gefährdet ist. Und das sehe ich ehrlich gesagt nicht. Aber schätzen Sie Ihre POV.
    @EliahKagan "Es ist wahr, dass sh nur manchmal Bash ist." "Nein, es ist kein" manchmal "Problem. `bash` ist bash und` sh` ist die Standard-Unix-Shell. Wenn Sie diese unglaublich einfache Tatsache nicht verstehen, sollten Sie wirklich niemanden über Sicherheitsprobleme informieren.
    @JakeGould Es gibt kein Programm, das "die Standard-Unix-Shell" ist. Unterschiedliche Betriebssysteme verwenden unterschiedliche Shells für `/ bin / sh`. Unter GNU / Linux ist `sh` normalerweise ein Link oder eine Kopie einer anderen Shell. [In Ubuntu und Debian bietet "dash" "sh", obwohl "bash" dies in den vergangenen Jahren getan hat.] (Https://wiki.ubuntu.com/DashAsBinSh) Auf einigen Betriebssystemen bleibt "sh" "bash". (Ich glaube, Slackware ist ein Beispiel, obwohl ich es in letzter Zeit nicht verwendet habe.) Eine schnelle Websuche [oder Wikipedia] (https://en.wikipedia.org/wiki/Bourne_shell#Usage) hätte Sie vor gerettet Ihr Missverständnis und rettete mich vor Ihrem falschen Vorwurf der Unwissenheit.
    @EliahKagan Ich stehe korrigiert. Aber "dash" ist einfach nicht "bash" und ich denke ehrlich, dass die Panik um "Shellshock" mehr Probleme verursachen wird als der Exploit selbst.
    Ich habe gerade meinen Server gepatcht und jetzt erhalte ich den Fehler, nachdem ich den obigen Befehl ausgeführt habe. Bedeutet dies, dass ich immer noch anfällig für CVE-2014-7169 bin, das behauptet, die Korrektur für den 6271-Shell-Schock sei unvollständig?
    @user53029 Der veröffentlichte Fix für CVE-2014-6271 behebt nicht den zugrunde liegenden Konstruktionsfehler, der dazu führt, dass bash Funktionsdefinitionen aus der Umgebung * genau richtig * analysieren oder potenzielle Sicherheitslücken aufweisen muss. In diesem Sinne ist die Korrektur unvollständig. Aber es behebt (soweit bekannt) den Fehler beim Ausführen von nachfolgendem Code nach einer Funktionsdefinition vollständig. Daher ist es weitgehend sinnvoll, CVE-2014-7169 als separate Sicherheitsanfälligkeit zu betrachten. ** Der Patch für 6271 und der Test in dieser Antwort zur Feststellung, ob dieser Patch effektiv angewendet wird, testen nicht für 7169. ** Ich habe diese Antwort um Details erweitert.
    @Eliah Kagan - Was kann ein Angreifer tun, um sich ein Bild über den Sicherheitsgrad zu machen, der durch den Patch gemindert wurde?
    @user53029 Genau. Ein Baum ist fixiert. Aber ist der Wald in einer echten praktischen Gefahr?
    Vorschlag für eine kleine Verbesserung. Wenn Sie dem Testbefehl "env" voranstellen, funktioniert dies auch von csh / tcsh aus.
    Ich benutze Mac OS X und es wird als anfällig angezeigt - aber ich kann vorerst nichts dagegen tun, oder?
    Mit dem letzten Patch (der "Auswertungen" für zufällige Umgebungsvariablen vermeidet) sollte der ursprüngliche Test einwandfrei funktionieren und _nothing_ auf einem vollständig gepatchten System drucken.
    Ich bekomme nichts, wenn ich das tippe
    #2
    +12
    BadSkillz
    2014-09-25 16:34:03 UTC
    view on stackexchange narkive permalink

    Sie können überprüfen, ob Sie anfällig sind, indem Sie die folgenden Zeilen in Ihrer Standard-Shell ausführen, die auf vielen Systemen Bash ist. Wenn Sie die Worte "kaputt" sehen, sind Sie gefährdet. Wenn nur der zweite Befehl "Busted" ausgibt, ist Ihre Bash anfällig, aber die Sicherheitsanfälligkeit wirkt sich nur auf die Teile Ihres Systems aus, die Bash explizit aufrufen, nicht auf die Teile, auf denen die Standard-Shell ausgeführt wird ( sh ). Wenn keiner der Befehle "kaputt" druckt, wird Ihr System gepatcht.

      env X = "() {:;}; echo kaputt" / bin / sh -c "echo abgeschlossen" env X = "() {:;}; Echo kaputt" bash -c "Echo abgeschlossen"  

    Quelle

    Nach dem Patchen kann Ihr System immer noch anfällig sein:

      env X = '() {(a) = > \' bash -c "echo echo vuln"; [["$ (cat echo)" == "vuln"]] && echo "immer noch anfällig :("  

    Quelle und eine andere Quelle

    Ich bin mir nicht sicher, was "\` welche Bash \ "diese" Bash "erreichen soll: Beide führen die" Bash "aus, die zuerst in" PATH "erscheint, und es ist nicht so, als ob" env "vollständig qualifiziert sein muss Namen. (Außerdem brauchst du dafür überhaupt kein "env".)
    @BadSkillz, können Sie "env X =" () {(a) => \ 'sh -c "echo date" etwas klarer machen; Katzenecho`? Was soll das tun oder mir zeigen?
    @Eliah, Es wäre großartig, wenn Sie eine bessere Antwort finden könnten.
    `which bash` könnte Sie an einer bereinigten Eingabe vorbei bringen, die die Shell-Befehlspfadliterale einschränkt.
    @KasperSouren, Ich denke, es zeigt nur einen Fehler beim Parsen von Bash-Funktionen, wie [hier] erwähnt (https://twitter.com/taviso/status/514910129557610496) ... dies ist also keine gültige Bash-Syntax.
    Bleibt X für immer in meiner Umgebung? Was ist, wenn ich bereits eine Umgebungsvariable namens X habe?
    @NateKerkhofs Nein, es wird nicht bleiben, und Sie können eine andere Variable verwenden, wenn Sie möchten
    @NateKerkhofs Umgebungsvariablen sind pro Prozess. `VAR = value some-command` (oder` env VAR = value some-command`) führt `some-command` aus, wobei` VAR` in * seiner * Umgebung auf `value` gesetzt ist. Das `x`, das zu der Shell gehört, in der Sie diesen Befehl ausführen [ist selbst nicht betroffen] (http://paste.ubuntu.com/8425978/), obwohl [die Variable in der Umgebung des untergeordneten Prozesses festgelegt ist] (http: //paste.ubuntu.com/8425989/). Selbst wenn Sie es für die Umgebung der aktuellen Shell festgelegt haben, wie BadSkillz sagt, wäre es nicht persistent und würde keinen Schaden anrichten, und Sie können einen anderen Variablennamen wählen, wenn Sie möchten.
    Ist was sicher? Was ist zu stoppen: `export which = '() {echo / bin / bash;}`? (Eine vollständige würde das Argument testen). Bash führt Funktionen vor den integrierten Funktionen aus. Sie können auf ähnliche Weise auch "deklarieren -f" und "env" behandeln, um die Funktionen auszublenden.
    #3
    +11
    Nzall
    2014-09-25 19:47:04 UTC
    view on stackexchange narkive permalink

    Wenn Sie eine Methode benötigen, um mehrere Server gleichzeitig zu überprüfen, die sich im selben Subnetz befinden, können Sie mit Masscan eine Anfrage an alle senden: https://github.com/robertdavidgraham/masscan

    Eine Beispielkonfigurationsdatei finden Sie unter http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html:

      target = 0.0.0.0/0 // ÄNDERN SIE DIESES IN DAS RICHTIGE SUBNETport = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/ 09 / bash-shellshock-scan-of-internet.html) http-header [Cookie] = () {:; }; ping -c 3 209.126.230.74http-header [Host] = () {:; }; ping -c 3 209.126.230.74http-header [Referer] = () {:; }; ping -c 3 209.126.230.74// Ändern Sie die oben genannten 3 IP-Adressen in die IP des Computers, von dem Sie sie senden.  

    Die anfälligen Computer senden Ihnen einen Ping zurück. Laut dem nachfolgenden Blogpost des Autors ist möglicherweise eine Konfiguration erforderlich.

    Wie kann ich nur einen Server überprüfen?
    @CharlesB stellt lediglich eine Remoteverbindung zum Server her und führt einen der Oneliner auf dieser Seite aus. oder geben Sie die vollständige IP des Servers mit der Subnetzmaske / 32 ein.
    Vielen Dank; konnte es nicht bearbeiten, aber es muss "target-ip" anstelle von "target" sein. Wenn ich meinen Router teste, ist der Ping-Befehl nicht erkennbar ... Gibt es einen anderen Befehl, um diesen Exploit zu beweisen?
    SSH in den Router und tun, was Eliah Khan in seiner Antwort empfiehlt. Sie müssen dies direkt über das Router-Terminal tun.
    Ich habe keinen SSH-Zugriff darauf, es ist eine geschlossene Box von Ihrem ISP. Also keine Möglichkeit, es zu überprüfen?
    Wenn es sich um eine geschlossene Box handelt, was werden Sie tun, wenn sich herausstellt, dass der Exploit aktiv ist? Ich bezweifle, dass Sie das Problem beheben können, da Sie Bash nicht aktualisieren können.
    Sicher, ich werde es nicht reparieren können, aber es dient nur dazu, es zu wissen und meinen ISP danach zu fragen.
    #4
      0
    Liam Marshall
    2014-09-26 23:12:10 UTC
    view on stackexchange narkive permalink

    Sie können ShellShocker ausprobieren, ein CLI-Dienstprogramm, mit dem ein CGI-Skript wie folgt überprüft werden kann:

      python shellshocker.py http://example.com /cgi-bin/possibly-vulnerable-cgi.cgi  
    #5
      0
    Roger
    2014-09-27 04:27:13 UTC
    view on stackexchange narkive permalink

    Sie können überprüfen, ob Ihr Server eine CGI-URL für den folgenden Online-Test sendet:

    http://shellshock.iecra.org

    #6
      0
    colevk
    2014-09-27 05:10:59 UTC
    view on stackexchange narkive permalink

    Ich habe einen Schnelltest geschrieben, der entweder "anfällig" oder "nicht anfällig" druckt:

      env x = '() {:;}; Echo anfällig; Ausfahrt;' bash -c 'echo nicht anfällig' 2> / dev / null  

    Es wird auch mit einem Exit-Code von 2 zurückgegeben, wenn Ihre Version von bash anfällig ist, wenn Sie sie als Teil von verwenden möchten ein Skript.

    Getestet mit den Versionen "3.2.51 (1) -release (x86_64-apple-darwin13)" und "3.2.53 (1) -release (x86_64-apple-darwin13)".


    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...