Como o teste de vulnerabilidade do Shellshock atualizado para CVE-2014-7169 funciona?

Entendo o teste original do CVE-2014-6271, que foi:

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

Mas estou confuso com o teste atualizado e a saída correspondente 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

Alguém poderia explicar brevemente o que está acontecendo aqui e como ele ignora o patch do CVE-2014-6271?

Venho pesquisando um pouco na Web desde que postei essa pergunta pela primeira vez.

De acordo com o descobridor original do bug, o bash anterior ao patch CVE-2014-6271 importou uma função como:

foo=() {
  code
}

substituindo o sinal de igual por um espaço e interpretando-o ... o que significava que era possível interpretar além da definição da função.

O patch para o CVE-2014-6271 introduziu um modo especial da função parse_and_execute () para limitar a avaliação à definição da função, e não além dela.

No entanto, conforme explicado neste encadeamento , a variável de ambiente especialmente criada do teste de vulnerabilidade CVE-2014-7169 foi projetada para 1) confundir o analisador até a morte 2) deixar restos no buffer 3) alterar completamente o que o comando bash original faz quando combina com as sobras já existentes no buffer.

Então, para dissecar a variável de ambiente:

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

• O analisador analisará () { (a)=>\. Observe que \faz parte da string; que é não escapando a cotação única fuga.

() {

• O analisador identifica isso como uma definição de função.

(a)=

• Isso confunde o analisador até a morte.

>\

• O analisador deixa os dois caracteres finais no buffer.

>\[NEWLINE]

• Em algum momento antes da shexecução do comando, uma nova linha é colocada no buffer.

>\[NEWLINE]echo date

• Quando shé chamado (que provavelmente é um link simbólico para bash neste caso), ele adiciona seus argumentos de comando,, echo dateaos caracteres já existentes no buffer.

>echo date

• Como a nova linha é escapada, o bash analisará o buffer como >echo date, que tem o mesmo efeito que date > echo. Um arquivo chamado echoé criado e o stdout do datecomando é redirecionado para ele.

; cat echo

• O segundo comando simplesmente exibe o conteúdo do arquivo recém-criado.

Ele não fornece uma boa saída limpa, mas demonstra o erro.

Sem erros, a variável de ambiente Xdeve ser ignorada, o bash deve ser executado echo datee o gato deve reclamar que não há arquivo chamado eco. Por exemplo, considere como o traço se comporta:

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

Não repetirei a saída que você mostra na sua pergunta e não pretendo entender como ela funciona, mas o bash está sendo executado datee colocando a saída em um arquivo chamado 'eco'. Você pode brincar com alternativas para datese convencer de que isso é utilizável e perigoso.