Wie funktioniert der aktualisierte Shellshock-Schwachstellentest für CVE-2014-7169?

Ich verstehe den ursprünglichen Test für CVE-2014-6271, der war:

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

Der aktualisierte Test und die entsprechende Ausgabe für CVE-2014-7169 verwirren mich jedoch:

$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BST

Könnte jemand kurz erklären, was hier passiert und wie der Patch für CVE-2014-6271 umgangen wird?

Ich habe ein bisschen in den Webseiten gebuddelt, seit ich diese Frage zum ersten Mal gestellt habe.

Laut dem ursprünglichen Entdecker des Fehlers hat bash vor dem Patch CVE-2014-6271 eine Funktion wie die folgende importiert:

foo=() {
  code
}

durch Ersetzen des Gleichheitszeichens durch ein Leerzeichen und Interpretieren ... was bedeutete, dass eine Interpretation über die Funktionsdefinition hinaus möglich war.

Mit dem Patch für CVE-2014-6271 wurde ein spezieller Modus der Funktion parse_and_execute () eingeführt , um die Auswertung auf die Funktionsdefinition und nicht darüber hinaus zu beschränken.

Wie in diesem Thread erläutert , wurde die speziell gestaltete Umgebungsvariable des CVE-2014-7169-Schwachstellentests entwickelt, um 1) den Parser zu Tode zu verwirren 2) Reste im Puffer zu belassen 3) vollständig zu ändern, was der ursprüngliche Befehl bash wann tut es verbindet sich mit den bereits im Puffer befindlichen Abfällen.

So zerlegen Sie die Umgebungsvariable:

X='() { (a)=>\'

• Der Parser wird analysieren () { (a)=>\. Beachten Sie, dass dies \Teil der Zeichenfolge ist. es entgeht nicht dem nachfolgenden einfachen Anführungszeichen.

() {

• Der Parser identifiziert dies als Funktionsdefinition.

(a)=

• Dies verwirrt den Parser zu Tode.

>\

• Der Parser lässt die letzten beiden Zeichen im Puffer.

>\[NEWLINE]

• Irgendwann vor der shAusführung des Befehls wird eine neue Zeile in den Puffer eingefügt.

>\[NEWLINE]echo date

• Wenn shes aufgerufen wird (was in diesem Fall wahrscheinlich ein Symlink zu bash ist), fügt es seine Befehlsargumente echo datezu den bereits im Puffer vorhandenen Zeichen hinzu.

>echo date

• Da die neue Zeile maskiert wird, analysiert bash den Puffer als >echo date, was den gleichen Effekt hat wie date > echo. Eine Datei mit dem Namen echowird erstellt und die Standardausgabe des dateBefehls wird in diese umgeleitet.

; cat echo

• Der zweite Befehl zeigt einfach den Inhalt der neu erstellten Datei an.

Es gibt Ihnen keine schöne saubere Ausgabe, aber es zeigt den Fehler.

Ohne Fehler sollte die Umgebungsvariable Xignoriert werden, bash sollte ausgeführt echo datewerden und cat sollte sich beschweren, dass es keine Datei namens echo gibt. Überlegen Sie beispielsweise, wie sich der Strich verhält:

me@myserver$ rm -f echo && env -i  X='() { (a)=>\' dash -c 'echo date'; cat echo
date
cat: echo: No such file or directory

Ich werde die Ausgabe, die Sie in Ihrer Frage zeigen, nicht wiederholen und ich werde nicht so tun, als würde ich verstehen, wie es funktioniert, aber bash wird ausgeführt dateund die Ausgabe in eine Datei namens "echo" gestellt. Sie können mit Alternativen spielen, dateum sich davon zu überzeugen, dass dies brauchbar und gefährlich ist.