Was bedeutet env x = '() {:;}; command 'bash do und warum ist es unsicher?

Es gibt anscheinend eine Sicherheitsanfälligkeit (CVE-2014-6271) in bash: Bash speziell gestaltete Umgebungsvariablen Code-Injection-Angriff

Ich versuche herauszufinden, was passiert, aber ich bin nicht ganz sicher, ob ich es verstehe. Wie kann das echoausgeführt werden, wie es in einfachen Anführungszeichen steht?

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

EDIT 1 : Ein gepatchtes System sieht so aus:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

BEARBEITEN 2 : Es gibt eine verwandte Sicherheitsanfälligkeit / einen verwandten Patch: CVE-2014-7169, der einen etwas anderen Test verwendet:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

ungepatchte Ausgabe :

vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

teilweise (frühe Version) gepatchte Ausgabe :

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

gepatchte Ausgabe bis einschließlich CVE-2014-7169:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

EDIT 3 : Geschichte geht weiter mit:

• CVE-2014-7186
• CVE-2014-7187
• CVE-2014-6277

bash speichert exportierte Funktionsdefinitionen als Umgebungsvariablen. Exportierte Funktionen sehen folgendermaßen aus:

$ foo() { bar; }
$ export -f foo
$ env | grep -A1 foo
foo=() {  bar
}

Das heißt, die Umgebungsvariable foohat den wörtlichen Inhalt:

() {  bar
}

Wenn eine neue Instanz von bash gestartet wird, sucht sie nach diesen speziell gestalteten Umgebungsvariablen und interpretiert sie als Funktionsdefinitionen. Sie können sogar selbst eines schreiben und sehen, dass es immer noch funktioniert:

$ export foo='() { echo "Inside function"; }'
$ bash -c 'foo'
Inside function

Leider kann das Parsen von Funktionsdefinitionen aus Zeichenfolgen (den Umgebungsvariablen) umfassendere Auswirkungen haben als beabsichtigt. In ungepatchten Versionen werden auch beliebige Befehle interpretiert, die nach Beendigung der Funktionsdefinition auftreten. Dies ist auf unzureichende Einschränkungen bei der Bestimmung akzeptabler funktionsähnlicher Zeichenfolgen in der Umgebung zurückzuführen. Zum Beispiel:

$ export foo='() { echo "Inside function" ; }; echo "Executed echo"'
$ bash -c 'foo'
Executed echo
Inside function

Beachten Sie, dass das Echo außerhalb der Funktionsdefinition beim Bash-Start unerwartet ausgeführt wurde. Die Funktionsdefinition ist nur ein Schritt, um die Evaluierung und den Exploit durchzuführen. Die Funktionsdefinition selbst und die verwendete Umgebungsvariable sind beliebig. Die Shell prüft die Umgebungsvariablen, stellt fest foo, wie sie die Bedingungen für das Aussehen einer Funktionsdefinition erfüllen, wertet die Zeile aus und führt versehentlich auch das Echo aus (bei dem es sich um einen beliebigen Befehl handeln kann, der böswillig ist oder nicht).

Dies wird als unsicher angesehen, da Variablen normalerweise nicht von sich aus direkt den Aufruf von in ihnen enthaltenem willkürlichem Code auslösen dürfen oder sollen. Möglicherweise setzt Ihr Programm Umgebungsvariablen aus nicht vertrauenswürdigen Benutzereingaben. Es ist sehr unerwartet, dass diese Umgebungsvariablen so manipuliert werden können, dass der Benutzer beliebige Befehle ausführen kann, ohne dass Sie ausdrücklich beabsichtigen, diese Umgebungsvariable aus einem im Code angegebenen Grund zu verwenden.

Hier ist ein Beispiel für einen realisierbaren Angriff. Sie betreiben einen Webserver, auf dem eine anfällige Shell im Laufe ihrer Lebensdauer ausgeführt wird. Dieser Webserver übergibt Umgebungsvariablen an ein Bash-Skript. Wenn Sie beispielsweise CGI verwenden, werden häufig Informationen zur HTTP-Anforderung als Umgebungsvariablen vom Webserver einbezogen. Zum Beispiel HTTP_USER_AGENTkönnte der Inhalt des User - Agent eingestellt werden. Dies bedeutet, dass, wenn Sie Ihren Benutzeragenten so fälschen, dass er wie '() {:; }; echo foo 'wird ausgeführt, wenn das Shell-Skript echo fooausgeführt wird. Auch hier echo fookönnte alles sein, bösartig oder nicht.

Dies kann hilfreich sein, um weiter zu demonstrieren, was los ist:

$ export dummy='() { echo "hi"; }; echo "pwned"'
$ bash
pwned
$

Wenn Sie eine anfällige Shell ausführen, werden Sie beim Starten einer neuen Subshell (hier einfach mithilfe der bash-Anweisung) feststellen, dass der beliebige Code ( echo "pwned") sofort im Rahmen seiner Initiierung ausgeführt wird. Anscheinend sieht die Shell, dass die Umgebungsvariable (Dummy) eine Funktionsdefinition enthält, und wertet die Definition aus, um diese Funktion in ihrer Umgebung zu definieren (beachten Sie, dass sie die Funktion nicht ausführt: das würde 'hi' ausgeben.)

Leider wird nicht nur die Funktionsdefinition ausgewertet, sondern der gesamte Text des Werts der Umgebungsvariablen, einschließlich der möglicherweise schädlichen Anweisungen, die auf die Funktionsdefinition folgen. Beachten Sie, dass ohne die anfängliche Funktionsdefinition die Umgebungsvariable nicht ausgewertet wird, sondern lediglich als Textzeichenfolge zur Umgebung hinzugefügt wird. Wie Chris Down betonte, handelt es sich hierbei um einen bestimmten Mechanismus zum Implementieren des Imports exportierter Shell-Funktionen.

Wir können die Funktion sehen, die in der neuen Shell definiert wurde (und die dort als exportiert markiert wurde), und wir können sie ausführen. Außerdem wurde Dummy nicht als Textvariable importiert:

$ declare -f
dummy ()
{
    echo "hi"
}
declare -fx dummy
$ dummy
hi
$echo $dummy
$

Weder die Erstellung dieser Funktion noch die Ausführung dieser Funktion ist Teil des Exploits - es ist nur das Fahrzeug, mit dem der Exploit ausgeführt wird. Der Punkt ist, dass wenn ein Angreifer bösartigen Code, dem eine minimale und unwichtige Funktionsdefinition vorausgeht, in einer Textzeichenfolge bereitstellen kann, die in eine exportierte Umgebungsvariable eingefügt wird, diese ausgeführt wird, wenn eine Subshell gestartet wird, was ein häufiges Ereignis ist in vielen Skripten. Außerdem wird es mit den Rechten des Skripts ausgeführt.

Ich schrieb dies als eine Wiederholung der hervorragenden Antwort von Chris Down im Stil eines Tutorials.

In bash können Sie solche Shell-Variablen haben

$ t="hi there"
$ echo $t
hi there
$

Standardmäßig werden diese Variablen nicht an untergeordnete Prozesse vererbt.

$ bash
$ echo $t

$ exit

Wenn Sie sie jedoch für den Export markieren, setzt bash ein Flag, das bedeutet, dass sie in die Umgebung von Unterprozessen gelangen (obwohl der envpParameter nicht sehr häufig angezeigt wird, hat das mainin Ihrem C-Programm drei Parameter: main(int argc, char *argv[], char *envp[])wobei das letzte Zeigerarray ein Array ist von Shell-Variablen mit ihren Definitionen).

Exportieren wir also twie folgt:

$ echo $t
hi there
$ export t
$ bash
$ echo $t
hi there
$ exit

Während oben tin der Subshell undefiniert war, wird es jetzt angezeigt, nachdem wir es exportiert haben (verwenden export -n tSie diese Option, wenn Sie den Export stoppen möchten).

Aber Funktionen in der Bash sind ein anderes Tier. Sie erklären sie so:

$ fn() { echo "test"; }

Und jetzt können Sie die Funktion einfach aufrufen, indem Sie sie so aufrufen, als wäre es ein anderer Shell-Befehl:

$ fn
test
$

Noch einmal, wenn Sie eine Subshell erzeugen, wird unsere Funktion nicht exportiert:

$ bash
$ fn
fn: command not found
$ exit

Wir können eine Funktion exportieren mit export -f:

$ export -f fn
$ bash
$ fn
test
$ exit

Hier ist der knifflige Teil: Eine exportierte Funktion wie fnwird in eine Umgebungsvariable konvertiert, genau wie unser Export der Shell-Variablen toben war. Dies passiert nicht, wenn fnes sich um eine lokale Variable handelt, aber nach dem Export können wir sie als Shell-Variable sehen. Sie können jedoch auch eine reguläre (dh nicht funktionsfähige) Shell-Variable mit demselben Namen haben. bash unterscheidet anhand des Inhalts der Variablen:

$ echo $fn

$ # See, nothing was there
$ export fn=regular
$ echo $fn
regular
$ 

Jetzt können wir envalle für den Export markierten Shell-Variablen anzeigen und sowohl die reguläre fnals auch die Funktion fnanzeigen:

$ env
.
.
.
fn=regular
fn=() {  echo "test"
}
$

Eine Sub-Shell nimmt beide Definitionen auf: eine als reguläre Variable und eine als Funktion:

$ bash
$ echo $fn
regular
$ fn
test
$ exit

Sie können fnwie oben beschrieben oder direkt als reguläre Variablenzuweisung definieren:

$ fn='() { echo "direct" ; }'

Beachten Sie, dass dies eine ungewöhnliche Sache ist! Normalerweise definieren wir die Funktion fnwie oben mit der fn() {...}Syntax. Aber da bash es durch die Umgebung exportiert, können wir direkt zur oben genannten regulären Definition "abkürzen". Beachten Sie, dass dies (möglicherweise entgegen Ihrer Intuition) nicht zu einer neuen Funktion fnin der aktuellen Shell führt. Aber wenn Sie eine ** sub ** Shell erzeugen, dann wird es.

Brechen wir den Export der Funktion ab fnund lassen Sie die neue reguläre Funktion fn(wie oben gezeigt) intakt.

$ export -nf fn

Jetzt wird die Funktion fnnicht mehr exportiert, sondern die reguläre Variable fnist, und sie enthält () { echo "direct" ; }darin.

Wenn eine Subshell nun eine reguläre Variable sieht, die damit beginnt (), interpretiert sie den Rest als Funktionsdefinition. Dies ist jedoch nur dann der Fall, wenn eine neue Shell beginnt. Wie wir oben gesehen haben, ()verhält sich eine reguläre Shell-Variable, die mit beginnt, nicht wie eine Funktion. Sie müssen eine Unterschale starten.

Und jetzt der "Shellshock" Bug:

Wie wir gerade gesehen haben, ()interpretiert eine neue Shell die Definition einer regulären Variablen, die damit beginnt , als Funktion. Wenn jedoch nach der schließenden Klammer, die die Funktion definiert, mehr angegeben ist, wird ausgeführt, was auch immer vorhanden ist.

Dies sind noch einmal die Anforderungen:

1. Neue Bash wird erzeugt
2. Eine Umgebungsvariable wird aufgenommen
3. Diese Umgebungsvariable beginnt mit "()" und enthält dann einen Funktionskörper in geschweiften Klammern und hat danach Befehle

In diesem Fall führt eine verwundbare Bash die letzteren Befehle aus.

Beispiel:

$ export ex='() { echo "function ex" ; }; echo "this is bad"; '
$ bash
this is bad
$ ex
function ex
$

Die reguläre exportierte Variable exwurde an die Subshell übergeben, die als Funktion interpretiert wurde, aber die nachfolgenden exBefehle wurden ausgeführt ( this is bad), als die Subshell erzeugt wurde.

Erklären Sie den glatten Einzeilentest

Ein beliebter Einzeiler zum Testen der Shellshock-Sicherheitsanfälligkeit ist der in @ jippies Frage genannte:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Hier ist eine Aufschlüsselung: Zuerst ist die :In-Bash nur eine Abkürzung für true. trueund :beide bewerten zu (Sie haben es erraten) wahr, in bash:

$ if true; then echo yes; fi
yes
$ if :; then echo yes; fi
yes
$

Zweitens gibt der envBefehl (der ebenfalls in bash integriert ist) die Umgebungsvariablen aus (wie wir oben gesehen haben), kann aber auch verwendet werden, um einen einzelnen Befehl mit einer exportierten Variablen (oder Variablen) auszuführen, die diesem Befehl zugewiesen wurde, und bash -cführt dann einen einzelnen Befehl aus Befehlszeile:

$ bash -c 'echo hi'
hi
$ bash -c 'echo $t'

$ env t=exported bash -c 'echo $t'
exported
$

Wenn wir also all diese Dinge zusammennähen, können wir bash als Befehl ausführen, ihm eine Dummy-Aufgabe geben (wie bash -c echo this is a test) und eine Variable exportieren, die mit beginnt, ()sodass die Subshell sie als Funktion interpretiert. Wenn Shellshock vorhanden ist, werden auch alle nachfolgenden Befehle in der Subshell sofort ausgeführt. Da die übergebene Funktion für uns irrelevant ist (aber geparst werden muss!), Verwenden wir die kürzeste gültige Funktion, die man sich vorstellen kann:

$ f() { :;}
$ f
$ 

Die Funktion fhier führt nur den :Befehl aus, der true zurückgibt und beendet wird. Hänge nun einen "bösen" Befehl an diesen an und exportiere eine reguläre Variable in eine Subshell und du gewinnst. Hier ist wieder der Einzeiler:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Wird xalso als reguläre Variable mit einer einfachen gültigen Funktion exportiert echo vulnerable, die bis zum Ende angeheftet ist. Dies wird an bash übergeben und bash interpretiert xals eine Funktion (die uns nicht interessiert) und führt dann möglicherweise das Kommando echo vulnerableif shellshock aus.

Wir könnten den Einzeiler ein wenig verkürzen, indem wir die this is a testNachricht entfernen :

$ env x='() { :;}; echo vulnerable' bash -c :

Dies stört nicht this is a test, führt aber den stillen :Befehl erneut aus. (Wenn Sie das -c :dann weglassen, sitzen Sie in der Unterschale und müssen manuell beenden.) Die vielleicht benutzerfreundlichste Version wäre diese:

$ env x='() { :;}; echo vulnerable' bash -c "echo If you see the word vulnerable above, you are vulnerable to shellshock"

Wenn Sie einem Programm beliebige Umgebungsvariablen hinzufügen können, können Sie dafür sorgen, dass es fast alles tut, indem es Bibliotheken Ihrer Wahl lädt. In den meisten Fällen wird dies nicht als Sicherheitsanfälligkeit für das Programm angesehen, das diese Umgebungsvariablen empfängt, sondern für den Mechanismus, mit dem ein Außenstehender beliebige Umgebungsvariablen einspeisen kann.

CVE-2014-6271 ist jedoch anders.

Es ist nichts Falsches daran, nicht vertrauenswürdige Daten in einer Umgebungsvariablen zu haben. Man muss nur sicherstellen, dass es nicht in eine dieser Umgebungsvariablen eingefügt wird, die das Verhalten des Programms ändern können. Etwas abstrakter ausgedrückt, können Sie für einen bestimmten Aufruf eine Whitelist mit Umgebungsvariablennamen erstellen, die von einem Außenstehenden direkt angegeben werden dürfen.

Ein Beispiel, das im Zusammenhang mit CVE-2014-6271 vorgestellt wurde, sind Skripte, die zum Parsen von Protokolldateien verwendet werden. Diese müssen möglicherweise sehr legitimerweise nicht vertrauenswürdige Daten in Umgebungsvariablen weitergeben. Natürlich wird der Name für eine solche Umgebungsvariable so gewählt, dass er keine nachteiligen Auswirkungen hat.

Aber hier ist, was an dieser besonderen Bash-Schwachstelle schlimm ist. Es kann über einen beliebigen Variablennamen ausgenutzt werden. Wenn Sie eine Umgebungsvariable mit dem Namen erstellen GET_REQUEST_TO_BE_PROCESSED_BY_MY_SCRIPT, würden Sie nicht erwarten, dass ein anderes Programm als Ihr eigenes Skript den Inhalt dieser Umgebungsvariablen interpretiert. Durch die Ausnutzung dieses Bash-Fehlers wird jedoch jede einzelne Umgebungsvariable zu einem Angriffsvektor.

Beachten Sie, dass dies nicht bedeutet, dass die Namen von Umgebungsvariablen geheim sein müssen. Wenn Sie die Namen der beteiligten Umgebungsvariablen kennen, wird ein Angriff nicht einfacher.

Wenn program1Aufrufe, program2die ihrerseits aufrufen program3, program1Daten program3über Umgebungsvariablen weiterleiten könnten . Jedes Programm hat eine spezifische Liste von Umgebungsvariablen, die es setzt, und eine spezifische Liste, auf die es einwirkt. Wenn Sie einen Namen gewählt haben, der nicht von erkannt wird program2, können Sie Daten von program1an weitergeben, program3ohne sich darüber Gedanken machen zu müssen, ob dies nachteilige Auswirkungen hat program2.

Ein Angreifer, der die genauen Namen der von exportierten Variablen program1und die Namen der von interpretierten Variablen program2kennt, kann dieses Wissen nicht ausnutzen, um das Verhalten von "program2" zu ändern, wenn sich die Namen nicht überschneiden.

Aber dies program2war ein bashSkript, weil aufgrund dieses Fehlers bashjede Umgebungsvariable als Code interpretiert wurde.

Es wird in dem Artikel erklärt, den Sie verlinkt haben ...

Sie können Umgebungsvariablen mit speziell gestalteten Werten erstellen, bevor Sie die Bash-Shell aufrufen. Diese Variablen können Code enthalten, der ausgeführt wird, sobald die Shell aufgerufen wird.

Das heißt, die Bash, die mit aufgerufen wird, -c "echo this is a test"führt den Code in einfachen Anführungszeichen aus, wenn er aufgerufen wird.

Bash hat Funktionen, wenn auch in einer etwas eingeschränkten Implementierung, und es ist möglich, diese Bash-Funktionen in Umgebungsvariablen zu setzen. Dieser Fehler wird ausgelöst, wenn am Ende dieser Funktionsdefinitionen (innerhalb der Umgebungsvariablen) zusätzlicher Code hinzugefügt wird.

In dem von Ihnen veröffentlichten Codebeispiel wird die Tatsache ausgenutzt, dass die aufgerufene Bash die Auswertung dieser Zeichenfolge nach der Ausführung der Zuweisung nicht beendet. Eine Funktionszuweisung in diesem Fall.

Das Besondere an dem von Ihnen veröffentlichten Code-Snippet ist meines Wissens, dass durch die Verwendung einer Funktionsdefinition vor dem Code, den wir ausführen möchten, einige Sicherheitsmechanismen umgangen werden können.