Este resumo é o melhor que encontrei na internet sobre Shell Shock (também conhecido como Bash Bug) explica:
O risco gira em torno da capacidade de definir arbitrariamente variáveis de ambiente dentro de um shell Bash que especifica uma definição de função. O problema começa quando o Bash continua a processar os comandos do shell após a definição da função, resultando no que classificamos como um "ataque de injeção de código". Vamos olhar novamente para o exemplo de Robert e vamos apenas seguir esta linha:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
A definição da função é () {:; }; e o comando shell é a instrução ping e os parâmetros subsequentes. Quando isso é processado no contexto de um shell Bash, o comando arbitrário é executado. Em um contexto da web, isso significaria por meio de um mecanismo como um script CGI e não necessariamente como um cabeçalho de solicitação. Vale a pena ler o advisory do seclists.org em detalhes, incluindo a afirmação de que o caminho e a string de consulta podem ser vetores potenciais para o ataque.
É claro que um meio de mitigar esse vetor de ataque em particular é simplesmente desabilitar qualquer funcionalidade CGI que faça chamadas para um shell e, de fato, alguns estão recomendando isso. Em muitos casos, porém, isso será uma mudança séria e, no mínimo, exigirá alguns testes extensos para garantir que não causará problemas imediatos no site, o que, em muitos casos, irá causar problemas.
A prova HTTP acima é simples, mas eficaz, apesar de apenas uma implementação sobre um protocolo comum. Uma vez que você começa a jogar em Telnet e SSH e, aparentemente, até em DHCP, o escopo aumenta drasticamente, de modo algum estamos falando sobre a exploração de servidores de aplicativos da web aqui. (Aparentemente, o risco está presente apenas no SSH pós-autenticação, mas em um estágio tão inicial da divulgação pública, inevitavelmente, veremos outros vetores de ataque surgindo ainda.)