Como esse bug afeta muitas plataformas, podemos aprender algo com o processo pelo qual essa vulnerabilidade foi encontrada: foi um momento εὕρηκα (eureka) ou o resultado de uma verificação de segurança?
Como sabemos que Stéphane encontrou o bug do Shellshock, e outros também podem conhecer o processo, estaríamos interessados na história de como ele encontrou o bug.
Responder1
Para tranquilizar alguns, não encontrei o bug observando explorações, não tenho motivos para acreditar que ele tenha sido explorado antes de ser divulgado (embora, é claro, não possa descartar essa possibilidade). Também não encontrei olhando basho código de.
Não posso dizer que me lembro exatamente da minha linha de pensamentos na época.
Isso veio mais ou menos de alguma reflexão sobre alguns comportamentos de algum software que achoperigoso(os comportamentos, não o software). O tipo de comportamento que faz você pensar:isso não parece uma boa ideia.
Nesse caso, eu estava refletindo sobre a configuração comum do ssh que permite passar variáveis de ambiente não higienizadas do cliente, desde que seu nome comece com LC_. A ideia é que as pessoas possam continuar usando sua própria linguagem ao sshusar outras máquinas. Uma boa ideia até você começar a considerar o quão complexo é o tratamento da localização, especialmente quando o UTF-8 é incluído na equação (e vendo como ele é mal tratado por muitos aplicativos).
Em julho de 2014, eu já havia relatado uma vulnerabilidade no tratamento da localização da glibc que combinava com aquela sshd
configuração, eoutros doiscomportamentos perigososda bashcasca
permitia que invasores (autenticados) invadissem servidores git, desde que conseguissem fazer upload de arquivos para lá e bashfossem usados como shell de login do usuário git unix (CVE-2014-0475).
Eu estava pensando que provavelmente seria uma má ideia usar bashcomo shell de login de usuários que oferecem serviços sobre ssh, visto que é um shell bastante complexo (quando tudo que você precisa é apenas analisar uma linha de comando muito simples) e herdou a maioria dos erros de design de ksh. Como já havia identificado alguns problemas de bashuso nesse contexto (para interpretar ssh ForceCommands), fiquei me perguntando se havia potencialmente mais lá.
AcceptEnv LC_*permite qualquer variável cujo nome comece com LC_e tive a vaga lembrança de quebash funções exportadas(aperigosoembora na época fosse um recurso útil) estavam usando variáveis de ambiente cujo nome era algo parecido
myfunction()e estavam se perguntando se não havia algo interessante para ver ali.
Eu estava prestes a descartá-lo, alegando que a pior coisa que alguém poderia fazer seria redefinir um comando chamado, LC_something
o que não poderia realmente ser um problema, pois esses nomes de comando não existem, mas então comecei a me perguntar comobash
importadoessas variáveis de ambiente.
E se as variáveis fossem chamadas, LC_foo;echo test; f()por exemplo? Então decidi dar uma olhada mais de perto.
A:
$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() { :
}
revelou que minha lembrança estava errada, pois as variáveis não foram chamadas myfunction(), mas myfunction(e é o
valorque começa com ()).
E um teste rápido:
$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'
confirmou minha suspeita de que o nome da variável não foi higienizado e o código foi avaliadona inicialização.
Pior, muito pior, ovalortambém não foi higienizado:
$ env 'foo=() { :;}; echo test' bash -c :
test
Isso significava quequalquervariável de ambiente pode ser um vetor.
Foi quando percebi a extensão do problema, confirmei que ele também era explorável por HTTP ( HTTP_xxx/ QUERYSTRING... env vars), outros como serviços de processamento de e-mail, mais tarde DHCP (e provavelmente uma longa lista) e relatei (com cuidado) .