Ist das Verhalten hinter der Shellshock-Schwachstelle in Bash dokumentiert oder überhaupt gewollt?

Eine aktuelle Sicherheitslücke, CVE-2014-6271, wie Bash interpretiert Umgebungsvariablen bekannt war. Der exploit beruht auf der Bash Parsen einige environment-Variablen-Deklarationen, wie Funktionsdefinitionen, aber dann weiterhin das ausführen von code nach der definition:

$ x='() { echo i do nothing; }; echo vulnerable' bash -c ':'
vulnerable

Aber ich verstehe es nicht. Es gibt nichts, was ich in der Lage gewesen, zu finden in der Bash-Dokumentation über die Interpretation von environment-Variablen als Funktionen überhaupt (außer für Erben-Funktionen, das ist unterschiedlich). In der Tat, eine ordnungsgemäße benannte definition einer Funktion wird nur behandelt wie ein Wert:

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

Aber eine korrupte man druckt nichts:

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

$ # Nothing but newline

Den korrupten Funktion ist Unbenannt, und so kann ich nicht nur es nennen. Steht diese Sicherheitsanfälligkeit in einem reinen Umsetzung bug, oder ist es eine beabsichtigte Funktion hier, dass ich einfach nicht sehen kann?

Update

Pro Barmar Kommentar, habe ich die Hypothese aufgestellt der name der Funktion wurde der parameter name:

$ n='() { echo wat; }' bash -c 'n'
wat

Konnte ich schwöre, ich versuchte vor, aber ich denke, dass ich nicht hart genug versuchen. Es ist wiederholbar jetzt. Hier ist ein wenig mehr testen:

$ env n='() { echo wat; }; echo vuln' bash -c 'n'
vuln
wat
$ env n='() { echo wat; }; echo $1' bash -c 'n 2' 3 -- 4

wat

...also scheinbar die Argumente sind nicht festgelegt auf die Zeit der exploit ausgeführt wird.

Trotzdem, die grundsätzliche Antwort auf meine Frage ist, ja, das ist wie Bash implementiert geerbt Funktionen.

Wie denken Sie Erben funktioniert in den ersten Platz? Die einzige Art der Vererbung zwischen Prozessen ist die Umwelt. So exportierten Funktionen müssen codiert sein, die in der Umgebung irgendwie.
der Beispiel-code in den link, den Sie enthalten, beginnt mit env wie in env x='.... Nicht sicher, wie das einen Unterschied macht, entweder. FYI ksh emittiert keine Ergebnisse dieser tests nach dem ändern von Referenzen aus bash -c zu ksh -c.
Das dauerte bash 4.3.25-1 geschlossen wird die Ausführung des Befehls nach der seltsamen definition einer Funktion, aber die Funktion ist noch erhalten, definiert...
Es gibt eine neue Sicherheitslücke kommen unten das Rohr als auch access.redhat.com/security/cve/CVE-2014-7169
Definition einer Funktion auf diese Weise ist eine beabsichtigte Funktion; der bug ist mit dem extra-code nach der definition einer Funktion wird ausgeführt.
Zu get this straight, können wir immer noch dieses: export ls='(){ /bin/ls $@; echo "Caught you";}'?
Fast. Die Zeichenfolge beginnen muss explizit mit () { (beachten Sie das Leerzeichen). Ansonsten, ja, bash drehen, die in eine Funktion namens ls wenn er sieht, dass Strings in seiner Umgebung auf Start. Die schließende geschweifte Klammer, es stellt sich heraus, ist etwas optional.
in meiner Verteidigung, ich konnte ja nicht wissen, was Erben bedeutet. Bedenken Sie, dass Sie setzen x=3 und es in einer subshell: $(echo $x), aber das ist etwas anders vom Export x. Bis dieser bug zum Vorschein kam, wusste ich nicht einmal, Sie könnten export-Funktionen.
Siehe Was bedeutet env x='() { :;}; Befehl' bash zu tun und warum ist es unsicher?

InformationsquelleAutor kojiro | 2014-09-24

49

Das scheint eine Umsetzung bug.

Anscheinend, die Art und Weise exportierten Funktionen arbeiten in bash ist, dass Sie speziell formatierte Umgebungsvariablen. Wenn Sie eine Funktion exportieren:
```
f() { ... }
```
es definiert eine Umgebungsvariable wie:
```
f='() { ... }'
```
Was wahrscheinlich geschieht, ist, dass, wenn die neue shell sieht eine Umgebungsvariable, deren Wert beginnt mit () es stellt den Namen der Variablen und führt die resultierende Zeichenkette. Der bug ist, dass diese Ausführung etwas nach die definition der Funktion als gut.

Beschriebene Korrektur ist offenbar zu analysieren, das Ergebnis zu sehen, wenn Sie eine gültige Funktionsdefinition. Wenn nicht, druckt es die Warnung über das ungültige Funktion definition versuchen.

Dieser Artikel bestätigt meine Erklärung für die Ursache des Fehlers. Es geht auch ein bisschen mehr ins detail darüber, wie das Update behebt es: nicht nur, dass Sie analysieren die Werte genauer an, aber die Variablen, die verwendet werden, um pass exportierten Funktionen einer bestimmten Namenskonvention. Diese Namenskonvention unterscheidet sich von verwendet, die für die Umgebungsvariablen erstellt für CGI-Skripte, so dass ein HTTP-client sollte nie in der Lage, um den Fuß in dieser Tür.
- Wie kommt es, Umgebung Variablen können Sie Funktionen ausführen, nicht aber bash-Befehle direkt.
- Es ist nicht "lassen" Sie etwas tun. Bash verwendet diese speziell formatierte environment-Variablen wie die Art und Weise, um zu Erben-Funktionen. Wenn es nicht formatiert wie dieses, gibt es keinen Grund, es auszuführen, es ist einfach nur Daten.
InformationsquelleAutor Barmar
16

Folgende:
```
x='() { echo I do nothing; }; echo vulnerable' bash -c 'typeset -f'
```
Drucke
```
vulnerable
x () 
{ 
    echo I do nothing
}
declare -fx x
```
scheint, als Bash, nachdem er analysiert die x=... entdeckt, das es da eine Funktion, mit der Sie ausgeführt hat, sah der declare -fx x und erlaubt die Ausführung des Befehls nach der Erklärung.

echo vulnerable
```
x='() { x; }; echo vulnerable' bash -c 'typeset -f'
```
Drucke:
```
vulnerable
x () 
{ 
    echo I do nothing
}
```
und ausführen der x
```
x='() { x; }; echo Vulnerable' bash -c 'x'
```
Drucke
```
Vulnerable
Segmentation fault: 11
```
segfaults - unendliche rekursive Aufrufe

Es nicht überschreibt, die bereits definierte Funktion
```
$ x() { echo Something; }
$ declare -fx x
$ x='() { x; }; echo Vulnerable' bash -c 'typeset -f'
```
Drucke:
```
x () 
{ 
    echo Something
}
declare -fx x
```
z.B. die x -, bleibt die bisher (korrekt) definierte Funktion.

Für die Bash 4.3.25(1)-release die Sicherheitslücke geschlossen ist, so
```
x='() { echo I do nothing; }; echo Vulnerable' bash -c ':'
```
Drucke
```
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
```
aber - was ist seltsam (zumindest für mich)
```
x='() { x; };' bash -c 'typeset -f'
```
TROTZDEM GEDRUCKT
```
x () 
{ 
    x
}
declare -fx x
```
und die
```
x='() { x; };' bash -c 'x'
```
speicherzugriffsverletzungen zu, so dass es NOCH akzeptieren das seltsame definition einer Funktion...
- Ihren letzten test, zeigt x nicht überschrieben wird, sieht tatsächlich aus wie ein bug als gut. Ich würde erwarten, dass der Befehl environment override Vorrang; es ist, zumindest für "normale" Umgebungsvariablen". Betrachten declare -x foo=5; bash -c 'echo $foo'; foo=9 bash -c 'echo $foo'. Die ersten Ausgänge 5; die zweiten Ausgänge 9.
- RE: update 2, das ist die export-Funktion funktioniert wie erwartet. Die zugewiesene Zeichenfolge x ist die definition einer Funktion und nichts mehr, so dass es exportiert wird.
- Kann man nicht eine Funktion definieren, die so, zumindest nicht explizit. Nur eine Instanz von bash erbt ein solcher Wert wird "instanziieren" es als ausführbare Funktion. Das ist, mit export foo='() { echo 5; }', foo bleibt eine normale string-parameter in der aktuellen shell, sondern ein Kind bash wird es eine Funktion (echo $foo würde nichts drucken, zum Beispiel, weil es keinen parameter mit dem Namen foo im Kind, nur eine Funktion).
- Was ich sagen kann, ist genau, was bash Tat: es bewertet die Zeichenfolge in der Umgebung, deren prefix war eine gültige definition einer Funktion, die ohne Rücksicht auf was auch immer nachfolgende code ausgewertet wurde zusammen mit ihm.
- die Sicherheitslücke ist NICHT geschlossen, das Update ist unvollständig, und nur härter, um die Sicherheitsanfälligkeit verwenden. CVE-2014-6271 wurde geschlossen, aber CVE-2014-7169 wurde geöffnet. Ein weiterer patch wird Folgen. cheers
InformationsquelleAutor jm666

Ich denke, es lohnt ein Blick auf das Bash-code selbst. Der patch gibt ein wenig Einsicht in das problem. Insbesondere

*** ../bash-4.3-patched/variables.c 2014-05-15 08:26:50.000000000 -0400
--- variables.c 2014-09-14 14:23:35.000000000 -0400
***************
*** 359,369 ****
      strcpy (temp_string + char_index + 1, string);

!     if (posixly_correct == 0 || legal_identifier (name))
!       parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
!
!     /* Ancient backwards compatibility.  Old versions of bash exported
!        functions like name()=() {...} */
!     if (name[char_index - 1] == ')' && name[char_index - 2] == '(')
!       name[char_index - 2] = '\0';

      if (temp_var = find_function (name))
--- 364,372 ----
      strcpy (temp_string + char_index + 1, string);

!     /* Don't import function names that are invalid identifiers from the
!        environment, though we still allow them to be defined as shell
!        variables. */
!     if (legal_identifier (name))
!       parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

      if (temp_var = find_function (name))

Beim Bash exportiert eine Funktion, zeigt es sich als eine Umgebungsvariable, zum Beispiel:

$ foo() { echo 'hello world'; }
$ export -f foo
$ cat /proc/self/environ | tr '\0' '\n' | grep -A1 foo
foo=() {  echo 'hello world'
}

Wenn Sie einen neuen Bash-Prozess findet eine Funktion definiert auf diese Weise in seine Umgebung, es evalutes den code in die variable mit parse_and_execute(). Für normale, nicht-bösartigen code ausführen es definiert lediglich die Funktion in der Bash und bewegt sich auf. Jedoch, weil es an eine generische Ausführung-Funktion der Bash wird korrekt Parsen und ausführen zusätzlichen code definiert, dass die variable nach der definition der Funktion.

Können Sie sehen, dass in den neuen code ein flag namens SEVAL_ONECMD Hinzugefügt wurde erzählt, dass Bash nur bewerten, der erste Befehl (das heißt, die definition der Funktion) und SEVAL_FUNCDEF nur functio0n Definitionen.

InformationsquelleAutor FatalError

0

In Bezug auf Ihre Frage über die Dokumentation, bemerkt, dass hier in der commandline Dokumentation für die env Befehl, dass eine Untersuchung der syntax zeigt, dass env funktioniert wie beschrieben.
- Gibt es Optional 4 möglichen Optionen
- Eine optionale Bindestrich als ein synonym für -i (für die Abwärtskompatibilität nehme ich an)
- Null oder mehr NAME=WERT-Paaren. Diese sind die Variablen-Belegung(s), die include-Funktion Definitionen.
- Beachten Sie, dass kein Semikolon (;) ist es erforderlich, zwischen oder nach den Zuordnungen.
- Das Letzte argument(s) kann aus einem einzigen Befehl, gefolgt durch das argument(en). Es wird ausgeführt, mit welchem die Berechtigungen erteilt wurden, um den login verwendet wird. Sicherheit wird gesteuert durch die Einschränkung von Berechtigungen auf der login-Benutzer und Berechtigungen auf Benutzer zugänglich ist, die ausführbare Dateien, so dass andere Benutzer als der ausführbaren Besitzer können nur Lesen und ausführen des Programms nicht verändert werden.
```
[ spot@LX03:~ ] env --help
Usage: env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
Set each NAME to VALUE in the environment and run COMMAND.

  -i, --ignore-environment   start with an empty environment
  -u, --unset=NAME           remove variable from the environment
      --help     display this help and exit
      --version  output version information and exit

A mere - implies -i.  If no COMMAND, print the resulting environment.

Report env bugs to bug-coreutils@gnu.org
GNU coreutils home page: <http://www.gnu.org/software/coreutils/>
General help using GNU software: <http://www.gnu.org/gethelp/>
Report env translation bugs to <http://translationproject.org/team/>
```
InformationsquelleAutor DocSalvager

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.