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

Question

Eu entendo o teste original para 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 contorna o patch para CVE-2014-6271?

    

Answer 1

Eu tenho andado por aí um pouco desde que publiquei esta pergunta pela primeira vez.

De acordo com o descobridor original do bug, o bash antes do 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 significa que a interpretação além da definição da função era possível.

O patch para 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 em este tópico , a variável de ambiente especialmente criada da vulnerabilidade CVE-2014-7169 teste é projetado para 1) confundir o analisador até a morte 2) deixar recados no buffer 3) mudar completamente o que o comando bash original faz quando combina com os recados que já estão no buffer.

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

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

• O analisador analisará () { (a)=>\ . Note que \ faz parte da string; é não escapando da simples citação.

() {

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

(a)=

• Isso confunde o analisador até a morte.

>\

• O analisador deixa os dois últimos caracteres no buffer.

>\[NEWLINE]

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

>\[NEWLINE]echo date

• Quando sh é chamado (o que é provavelmente um link simbólico para bash nesse caso), ele adiciona seus argumentos de comando, echo date , aos 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 comando date é redirecionado para ele.

; cat echo

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

Answer 2

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

Sem nenhum bug, a variável de ambiente X deve ser ignorada, o bash deve rodar echo date , e cat deve reclamar que não existe um arquivo chamado echo. 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 vou repetir a saída que você mostra na sua pergunta, e não vou fingir que entendi como funciona, mas o bash está executando date e colocando a saída em um arquivo chamado 'echo'. Você pode jogar com alternativas para date para se convencer de que isso é útil e perigoso.