Comment fonctionne le test de vulnérabilité Shellshock mis à jour pour CVE-2014-7169?

Je comprends le test d'origine pour CVE-2014-6271, qui était:

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

Mais je suis confus par le test mis à jour et la sortie correspondante pour CVE-2014-7169:

$ 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

Quelqu'un pourrait-il expliquer brièvement ce qui se passe ici et comment il contourne le correctif pour CVE-2014-6271?

Je fouille un peu sur les sites Web depuis que j'ai publié cette question pour la première fois.

Selon le découvreur d'origine du bogue, bash avant le correctif CVE-2014-6271 a importé une fonction telle que:

foo=() {
  code
}

en remplaçant le signe égal par un espace et en l'interprétant ... ce qui signifiait qu'une interprétation au-delà de la définition de la fonction était possible.

Le correctif pour CVE-2014-6271 a introduit un mode spécial de la fonction parse_and_execute () pour limiter l'évaluation à la définition de la fonction, et non au-delà.

Cependant, comme expliqué dans ce fil , la variable d'environnement spécialement conçue du test de vulnérabilité CVE-2014-7169 est conçue pour 1) confondre l'analyseur à mort 2) laisser des notes dans le tampon 3) changer complètement ce que fait la commande bash d'origine lorsque il se combine avec les notes déjà dans le tampon.

Donc pour disséquer la variable d'environnement:

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

• L'analyseur analysera () { (a)=>\. Notez que cela \fait partie de la chaîne; il n'échappe pas à la citation simple de fin.

() {

• L'analyseur identifie cela comme une définition de fonction.

(a)=

• Cela confond l'analyseur à mort.

>\

• L'analyseur laisse les deux derniers caractères assis dans le tampon.

>\[NEWLINE]

• À un certain moment avant l' shexécution de la commande, une nouvelle ligne est placée dans le tampon.

>\[NEWLINE]echo date

• Quand shest appelé (qui est probablement un lien symbolique vers bash dans ce cas), il ajoute ses arguments de commande echo date, aux caractères déjà existants dans le tampon.

>echo date

• Puisque la nouvelle ligne est échappée, bash analysera le tampon comme >echo date, ce qui a le même effet que date > echo. Un fichier nommé echoest créé et la sortie standard de la datecommande y est redirigée.

; cat echo

• La deuxième commande affiche simplement le contenu du fichier nouvellement créé.

Cela ne vous donne pas une belle sortie propre, mais cela démontre le bogue.

Sans bogue, la variable d'environnement Xdoit être ignorée, bash doit s'exécuter echo dateet cat doit se plaindre qu'il n'y a pas de fichier appelé echo. Par exemple, considérez le comportement du tiret:

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

Je ne répéterai pas la sortie que vous montrez dans votre question, et je ne prétendrai pas comprendre comment cela fonctionne, mais bash est en cours d'exécution dateet place la sortie dans un fichier appelé 'echo'. Vous pouvez jouer avec des alternatives à datepour vous convaincre que cela est utilisable et dangereux.