it-swarm.com.de

Wann wurde der Shellshock-Fehler (CVE-2014-6271 / 7169) eingeführt, und welcher Patch behebt ihn vollständig?

Einige Zusammenhänge zum Fehler: CVE-2014-6271

Bash unterstützt den Export nicht nur von Shell-Variablen, sondern auch von Shell-Funktionen in andere Bash-Instanzen über die Prozessumgebung in (indirekte) untergeordnete Prozesse. Aktuelle Bash-Versionen verwenden eine Umgebungsvariable, die nach dem Funktionsnamen benannt ist, und eine Funktionsdefinition, die mit „() {“ im Variablenwert beginnt, um Funktionsdefinitionen durch die Umgebung zu verbreiten. Die Sicherheitsanfälligkeit tritt auf, weil bash nach der Verarbeitung der Funktionsdefinition nicht beendet wird. Es analysiert weiterhin Shell-Befehle und führt sie gemäß der Funktionsdefinition aus. Zum Beispiel eine Umgebungsvariableneinstellung von

  VAR=() { ignored; }; /bin/id

führt/bin/id aus, wenn die Umgebung in den Bash-Prozess importiert wird.

Quelle: http://seclists.org/oss-sec/2014/q3/65

Wann wurde der Fehler eingeführt und welcher Patch behebt ihn vollständig? (Siehe CVE-2014-7169 )

Was sind die anfälligen Versionen, die im CVE (anfangs) nicht erwähnt wurden (3. {0..2} und 4. {0..3})?

Wurde der fehlerhafte Quellcode in anderen Projekten wiederverwendet?

Zusätzliche Informationen sind wünschenswert.


Verwandte: Was macht env x = '() {:;}; Befehl' bash und warum ist es unsicher?

122
Deer Hunter

TL; DR

Die Shellshock-Sicherheitsanfälligkeit wurde vollständig behoben

  • Auf dem Bash-2.05b-Zweig: 2.05b.10 und höher (Patch 10 enthalten)
  • Auf dem Bash-3.0-Zweig: 3.0.19 und höher (Patch 19 enthalten)
  • Auf dem Bash-3.1-Zweig: 3.1.20 und höher (Patch 20 enthalten)
  • Auf dem Bash-3.2-Zweig: 3.2.54 und höher (Patch 54 enthalten)
  • Auf dem Bash-4.0-Zweig: 4.0.41 und höher (Patch 41 enthalten)
  • Auf dem Bash-4.1-Zweig: 4.1.14 und höher (Patch 14 enthalten)
  • Auf dem Bash-4.2-Zweig: 4.2.50 und höher (Patch 50 enthalten)
  • Auf dem Bash-4.3-Zweig: 4.3.27 und höher (Patch 27 enthalten)

Wenn Ihre Bash eine ältere Version anzeigt, hat Ihr Betriebssystemhersteller sie möglicherweise noch selbst gepatcht. Überprüfen Sie sie daher am besten.

Wenn:

env xx='() { echo vulnerable; }' bash -c xx

zeigt "verletzlich", du bist immer noch verletzlich. Dies ist der einzige relevante Test (ob der Bash-Parser noch Code in any Umgebungsvariable ausgesetzt ist).

Einzelheiten.

Der Fehler war in der anfänglichen Implementierung der Funktion Exportieren/Importieren, die am 5 eingeführt wurdeth vom August 1989 von Brian Fox und erstmals etwa einen Monat später in bash-1.03 veröffentlicht, zu einer Zeit, in der bash nicht so weit verbreitet war, bevor die Sicherheit ein großes Problem darstellte und HTTP und das Web oder Linux überhaupt existierten.

Aus dem ChangeLog in 1.05 :

Fri Sep  1 18:52:08 1989  Brian Fox  (bfox at aurel)

       * readline.c: rl_insert ().  Optimized for large amounts
         of typeahead.  Insert all insertable characters at once.

       * I update this too irregularly.
         Released 1.03.
[...]
Sat Aug  5 08:32:05 1989  Brian Fox  (bfox at aurel)

       * variables.c: make_var_array (), initialize_Shell_variables ()
         Added exporting of functions.

Einige Diskussionen in gnu.bash.bug und comp.unix.questions zu dieser Zeit erwähnen ebenfalls die Funktion.

Es ist leicht zu verstehen, wie es dahin kam.

bash exportiert die Funktionen in env vars wie

foo=() {
  code
}

Und beim Import muss es nur so interpretiert werden, dass = Durch ein Leerzeichen ersetzt wird ... außer dass es nicht blind interpretiert werden sollte.

Es ist auch insofern gebrochen, als in bash (im Gegensatz zur Bourne-Shell) skalare Variablen und Funktionen einen anderen Namensraum haben. Eigentlich wenn du hast

foo() { echo bar; }; export -f foo
export foo=bar

bash fügt beide gerne in die Umgebung ein (Ja-Einträge mit demselben Variablennamen), aber viele Tools (einschließlich vieler Shells) geben sie nicht weiter.

Man würde auch argumentieren, dass bash dafür ein BASH_ - Namespace-Präfix verwenden sollte, da dies nur von bash zu bash relevant ist. rc verwendet für eine ähnliche Funktion das Präfix fn_.

Ein besserer Weg, dies zu implementieren, wäre gewesen, die Definition aller exportierten Variablen in eine Variable wie:

BASH_FUNCDEFS='f1() { echo foo;}
  f2() { echo bar;}...'

Das müsste noch bereinigt werden, aber das könnte zumindest nicht ausnutzbarer sein als $BASH_ENV Oder $SHELLOPTS ...

Es gibt einen Patch, der verhindert, dass bash etwas anderes als die darin enthaltene Funktionsdefinition interpretiert ( 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. Es wird also bald einen weiteren Patch geben.

Bis zu einem Hardening-Fix, der verhindert, dass Bash Code in einer Variablen interpretiert (wie bei Verwendung des obigen Ansatzes BASH_FUNCDEFS), Wissen wir nicht sicher, ob wir nicht durch einen Fehler im Bash-Parser verwundbar sind. Und ich glaube, dass es früher oder später einen solchen Härtungsfix geben wird.

Bearbeiten 28.09.2014

Es wurden zwei zusätzliche Fehler im Parser gefunden (CVE-2014-718 {6,7}) (beachten Sie, dass die meisten Shells in Eckfällen Fehler in ihrem Parser enthalten müssen. Dies wäre kein Problem gewesen, wenn dieser Parser dies nicht getan hätte nicht vertrauenswürdigen Daten ausgesetzt).

Während alle 3 Fehler 7169, 7186 und 7187 in den folgenden Patches behoben wurden, drängte Red Hat auf die Härtungskorrektur. In ihrem Patch haben sie das Verhalten so geändert, dass Funktionen in Variablen mit dem Namen BASH_FUNC_myfunc() exportiert wurden, was Chets Entwurfsentscheidung mehr oder weniger erschwert.

Chet später veröffentlichte diesen Fix als offiziellen Upstreams-Bash-Patch .

Dieser härtende Patch oder Varianten davon sind jetzt für die meisten großen Linux-Distributionen verfügbar und haben es schließlich zu Apple OS/X) geschafft.

Dies beseitigt nun die Besorgnis über eine beliebige Umgebung, die den Parser über diesen Vektor ausnutzt, einschließlich zweier weiterer Schwachstellen im Parser (CVE-2014-627 {7,8}), die wurden später bekannt gegeben von Michał Zalewski ( CVE-2014-6278 ist fast so schlecht wie CVE-2014-6271), zum Glück, nachdem die meisten Leute Zeit hatten, das Härtungspflaster zu installieren

Fehler im Parser werden ebenfalls behoben, aber sie sind jetzt kein so großes Problem mehr, da der Parser nicht mehr so ​​leicht nicht vertrauenswürdigen Eingaben ausgesetzt ist.

Beachten Sie, dass die Sicherheitslücke zwar behoben wurde, es jedoch wahrscheinlich einige Änderungen in diesem Bereich gibt. Die anfängliche Korrektur für CVE-2014-6271 hat die Abwärtskompatibilität dadurch beeinträchtigt, dass der Import von Funktionen mit . Oder : Oder / Im Namen gestoppt wird. Diese können jedoch immer noch durch Bash deklariert werden, was zu einem inkonsistenten Verhalten führt. Da häufig Funktionen mit . Und : Im Namen verwendet werden, wird wahrscheinlich ein Patch wiederhergestellt, der zumindest diejenigen aus der Umgebung akzeptiert.

Warum wurde es nicht früher gefunden?

Darüber habe ich mich auch gewundert. Ich kann ein paar Erklärungen geben.

Erstens denke ich, dass ein Sicherheitsforscher (und ich bin kein professioneller Sicherheitsforscher), der speziell nach Sicherheitslücken in Bash gesucht hätte, diese wahrscheinlich gefunden hätte.

Wenn ich beispielsweise ein Sicherheitsforscher wäre, könnten meine Ansätze sein:

  1. Schauen Sie sich an, woher bash Eingaben erhält und was es damit macht. Und die Umwelt ist offensichtlich.
  2. Schauen Sie, an welchen Stellen der bash - Interpreter aufgerufen wird und auf welchen Daten. Wieder würde es auffallen.
  3. Das Importieren von exportierten Funktionen ist eine der Funktionen, die deaktiviert ist, wenn bash setuid/setgid ist, was das Betrachten noch offensichtlicher macht.

Nun, ich vermute, niemand hat daran gedacht, bash (den Interpreter) als Bedrohung zu betrachten, oder dass die Bedrohung auf diese Weise hätte kommen können.

Der bash -Interpreter ist nicht dazu gedacht, nicht vertrauenswürdige Eingaben zu verarbeiten.

Shell Skripte (nicht der Interpreter) werden unter Sicherheitsgesichtspunkten häufig genau betrachtet. Die Shell-Syntax ist so umständlich und es gibt so viele Einschränkungen beim Schreiben zuverlässiger Skripte (ich oder andere haben jemals den Split + Glob-Operator erwähnt oder warum sollten Sie beispielsweise Variablen zitieren?), Dass Sicherheitslücken in Skripten, die verarbeitet werden, häufig vorkommen nicht vertrauenswürdige Daten.

Aus diesem Grund hören Sie oft, dass Sie keine CGI-Shell-Skripte schreiben sollten, oder Setuid-Skripte sind auf den meisten Unices deaktiviert. Oder dass Sie besonders vorsichtig sein sollten, wenn Sie Dateien in weltweit beschreibbaren Verzeichnissen verarbeiten (siehe beispielsweise CVE-2011-0441 ).

Der Fokus liegt darauf, den Shell-Skripten, nicht dem Interpreter.

Sie können einen Shell-Interpreter über eval oder . Nicht vertrauenswürdigen Daten aussetzen (fremde Daten als zu interpretierenden Shell-Code eingeben) oder ihn für vom Benutzer bereitgestellte Dateien aufrufen, benötigen dann jedoch keine Sicherheitsanfälligkeit in bash, um es auszunutzen. Es ist ziemlich offensichtlich, dass wenn Sie nicht bereinigte Daten zur Interpretation an eine Shell übergeben, diese interpretiert werden.

Daher wird die Shell in vertrauenswürdigen Kontexten aufgerufen. Es gibt feste Skripte zum Interpretieren und meistens (weil es so schwierig ist, zuverlässige Skripte zu schreiben) feste Daten zum Verarbeiten.

In einem Webkontext kann eine Shell beispielsweise folgendermaßen aufgerufen werden:

popen("sendmail -oi -t", "w");

Was kann damit möglicherweise schief gehen? Wenn etwas Falsches in Betracht gezogen wird, handelt es sich um die Daten, die dieser sendmail zugeführt werden, nicht darum, wie diese Shell-Befehlszeile selbst analysiert wird oder welche zusätzlichen Daten dieser Shell zugeführt werden. Es gibt keinen Grund, die Umgebungsvariablen zu berücksichtigen, die an diese Shell übergeben werden. Und wenn Sie dies tun, stellen Sie fest, dass es sich um alle env-Variablen handelt, deren Name mit "HTTP_" beginnt oder bei denen es sich um bekannte CGI-env-Variablen wie SERVER_PROTOCOL Oder QUERYSTRING handelt, mit denen die Shell oder sendmail nichts zu tun haben machen mit.

In Kontexten zur Erhöhung von Berechtigungen wie beim Ausführen von setuid/setgid oder über Sudo wird die Umgebung im Allgemeinen berücksichtigt, und in der Vergangenheit gab es zahlreiche Sicherheitslücken, wiederum nicht gegen die Shell selbst, sondern gegen die Dinge, die die Berechtigungen erhöhen, wie Sudo (siehe zum Beispiel CVE-2011-3628 ).

Zum Beispiel vertraut bash der Umgebung nicht, wenn es setuid ist oder von einem setuid-Befehl aufgerufen wird (denken Sie beispielsweise an mount, das Helfer aufruft). Insbesondere werden exportierte Funktionen ignoriert.

Sudo bereinigt die Umgebung: alle standardmäßig, mit Ausnahme einer weißen Liste, und wenn dies nicht konfiguriert ist, werden zumindest einige schwarze Listen aufgelistet, von denen bekannt ist, dass sie eine Shell oder eine andere betreffen (wie PS4). BASH_ENV, SHELLOPTS...). Außerdem werden die Umgebungsvariablen auf die schwarze Liste gesetzt, deren Inhalt mit () Beginnt (weshalb CVE-2014-6271 keine Eskalation von Berechtigungen über Sudo zulässt).

Dies gilt jedoch auch für Kontexte, in denen der Umgebung nicht vertraut werden kann: Jede Variable mit einem beliebigen Namen und Wert kann von einem böswilligen Benutzer in diesem Kontext festgelegt werden. Dies gilt nicht für Webserver/ssh oder alle Vektoren, die CVE-2014-6271 nutzen, in denen die Umgebung gesteuert wird (zumindest der Name der Umgebungsvariablen wird gesteuert ...)

Es ist wichtig, eine Variable wie echo="() { evil; }" zu blockieren, aber nicht HTTP_FOO="() { evil; }", da HTTP_FOO Von keinem Shell-Skript oder jeder Befehlszeile als Befehl aufgerufen wird. Und Apache2 wird niemals eine echo oder BASH_ENV Variable setzen.

Es ist ziemlich offensichtlich, dass einige Umgebungsvariablen in einigen Kontexten aufgrund ihres Namens auf die schwarze Liste gesetzt werden sollten, aber niemand dachte, dass sie basierend auf ihrem auf der schwarzen Liste stehen sollten Inhalt (außer Sudo). Mit anderen Worten, niemand hätte gedacht, dass beliebige Umgebungsvariablen ein Vektor für die Code-Injektion sein könnten.

Ich würde sagen, dass umfangreiche Tests, als das Feature hinzugefügt wurde, es hätten fangen können.

Wenn Sie auf die Funktion testen, testen Sie die Funktionalität. Die Funktionalität funktioniert gut. Wenn Sie die Funktion in einem bash -Aufruf exportieren, wird sie in einem anderen ordnungsgemäß importiert. Bei einem sehr gründlichen Test konnten Probleme auftreten, wenn sowohl eine Variable als auch eine Funktion mit demselben Namen exportiert wurden oder wenn die Funktion in ein anderes Gebietsschema importiert wurde als das, in das sie exportiert wurde.

Um die Sicherheitsanfälligkeit erkennen zu können, ist dies jedoch kein Funktionstest, den Sie hätten durchführen müssen. Der Sicherheitsaspekt hätte im Mittelpunkt stehen müssen, und Sie würden nicht die Funktionalität testen, sondern den Mechanismus und wie er missbraucht werden könnte.

Es ist nicht etwas, das Entwickler (insbesondere 1989) oft im Hinterkopf haben, und ein Shell-Entwickler könnte entschuldigt werden, dass seine Software wahrscheinlich nicht im Netzwerk ausgenutzt werden kann.

205

Laut der NVD-Datenbank bei NIST ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271 ) sind ALLE VERSIONEN von bash vom 1.14.0 ab sind anfällig.

RedHat bekam Wind vom Bug am 14. September .

Der von Mr.Ramey (Bash-Betreuer) am 26. September 2014 veröffentlichte Patch behebt den Fehler CVE-2014-7169-Fehler .

Wenden Sie diese und alle vorherigen Patches auf die entsprechenden Bash-Quellen an:


Zusätzliche Schwachstellen in Bash


Ein bisschen mehr über die Geschichte des Fehlers (mit freundlicher Genehmigung von mikeserv )

Quelle: http://www.linuxmisc.com/12-unix-Shell/e3f174655d75a48b.htm

1994 beschrieb Chet Ramey es als älter als die alte POSIX 2-Spezifikation, die sowieso exportierte Funktionen spezifizierte. Zumindest beschrieb er den Bash-Mechanismus so - ob er damals wie heute so fehlerhaft war oder nicht, weiß ich nicht. Er diskutiert auch die Funktionsexporte von rc in diesem Thread.

19
Deer Hunter