¿Cómo funciona la prueba actualizada de vulnerabilidad Shellshock para CVE-2014-7169?

Entiendo la prueba original para CVE-2014-6271, que fue:

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

Pero estoy confundido por la prueba actualizada y la salida correspondiente para 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

¿Podría alguien explicar brevemente lo que está sucediendo aquí y cómo omite el parche para CVE-2014-6271?

He estado cavando por las webs un poco desde que publiqué esta pregunta por primera vez.

Según el descubridor original del error, bash antes del parche CVE-2014-6271 importó una función como:

foo=() {
  code
}

reemplazando el signo igual con un espacio e interpretándolo ... lo que significaba que era posible interpretar más allá de la definición de la función.

El parche para CVE-2014-6271 introdujo un modo especial de la función parse_and_execute () para limitar la evaluación a la definición de la función, y no más allá.

Sin embargo, como se explica en este hilo , la variable de entorno especialmente diseñada de la prueba de vulnerabilidad CVE-2014-7169 está diseñada para 1) confundir el analizador a la muerte 2) dejar restos en el búfer 3) cambiar completamente lo que hace el comando bash original cuando se combina con los desechos que ya están en el búfer.

Entonces, para diseccionar la variable de entorno:

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

• El analizador analizará () { (a)=>\. Tenga en cuenta que \es parte de la cadena; se no escapa la cita única salida.

() {

• El analizador identifica esto como una definición de función.

(a)=

• Esto confunde al analizador hasta la muerte.

>\

• El analizador deja los dos últimos caracteres sentados en el búfer.

>\[NEWLINE]

• En algún momento antes de shejecutar el comando, se coloca una nueva línea en el búfer.

>\[NEWLINE]echo date

• Cuando shse llama (que probablemente sea un enlace simbólico para bash en este caso), agrega sus argumentos de comando echo datea los caracteres que ya existen en el búfer.

>echo date

• Como se escapa la nueva línea, bash analizará el búfer como >echo date, lo que tiene el mismo efecto que date > echo. Se echocrea un archivo llamado y el stdout del datecomando se redirige a él.

; cat echo

• El segundo comando simplemente muestra el contenido del archivo recién creado.

No le da un resultado limpio, pero demuestra el error.

Sin errores, la variable de entorno Xdebe ignorarse, bash debe ejecutarse echo datey cat debe quejarse de que no hay un archivo llamado echo. Por ejemplo, considere cómo se comporta el guión:

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

No repetiré el resultado que muestra en su pregunta, y no pretendo entender cómo funciona, pero bash se está ejecutando datey coloca el resultado en un archivo llamado 'echo'. Puedes jugar con alternativas para dateconvencerte de que esto es útil y peligroso.