CVE-2014-6271

Shellshock é uma falha de injeção de comando (CWE-78) no interpretador GNU Bash: até a versão 4.3, o Bash continua executando código colocado depois do fechamento de uma definição de função exportada via variável de ambiente. Qualquer serviço que passe entrada externa para uma variável de ambiente e depois invoque Bash — CGI do Apache, ForceCommand do OpenSSH, clientes DHCP, entre outros — vira ponto de execução remota de código sem autenticação. O CVSS 9.8 reflete corretamente a gravidade: a exploração é trivial, não exige interação do usuário e o impacto é execução arbitrária no contexto do processo que invocou o shell.

O Bash permite exportar funções shell através de variáveis de ambiente cujo valor começa com a sintaxe '() {'. Ao importar essas variáveis na inicialização de uma nova instância, o parser do Bash lê a definição da função, mas — no código vulnerável — não impõe que a string termine ali. Qualquer comando colocado depois do fechamento de chaves da função é interpretado e executado como comando shell normal, fora do contexto da função. Isso significa que o atacante controla integralmente o conteúdo de uma variável de ambiente e usa esse controle para injetar comandos arbitrários que o Bash executa no momento em que é iniciado, mesmo que a aplicação nunca tenha chamado explicitamente essa função.

O vetor de ataque não é o Bash sendo chamado diretamente pelo atacante, e sim uma aplicação privilegiada que aceita entrada externa (cabeçalho HTTP, variável repassada por CGI, comando SSH, opção DHCP) e a coloca em uma variável de ambiente antes de invocar Bash — cruzando uma fronteira de privilégio entre quem define a variável e quem executa o shell. mod_cgi/mod_cgid do Apache repassam cabeçalhos HTTP (como User-Agent, Referer, Cookie) como variáveis de ambiente para scripts CGI; a feature ForceCommand do OpenSSH sshd também expõe variáveis controladas pelo cliente SSH ao Bash executado pelo servidor.

O ponto crítico documentado pelo CERT/CC e pela Red Hat é que a correção original publicada para CVE-2014-6271 foi incompleta: ela impedia a execução de comandos após a função, mas não cobria todos os caminhos de parsing. A vulnerabilidade residual recebeu CVE-2014-7169, e problemas adicionais no mesmo mecanismo geraram CVE-2014-6277, CVE-2014-7186 e CVE-2014-7187. Ou seja, 'corrigir CVE-2014-6271' isoladamente, com o patch original, não elimina o risco — é preciso aplicar o pacote que também trata CVE-2014-7169 em diante.

Na prática, a exploração depende de existir uma aplicação que (a) aceite entrada controlada pelo atacante, (b) coloque essa entrada em uma variável de ambiente, e (c) chame Bash para processar algo — direta ou indiretamente. O caso mais explorado foi CGI em servidores Apache com mod_cgi/mod_cgid: o atacante envia uma requisição HTTP com um cabeçalho (por exemplo User-Agent) contendo a string de payload '() { :;}; comando', o servidor CGI copia o cabeçalho para uma variável de ambiente, e o script CGI, ao ser executado via Bash, dispara o comando injetado com os privilégios do processo do servidor web. Não é necessária autenticação nem qualquer interação do usuário — é uma requisição HTTP única.

Outros vetores documentados incluem sshd com ForceCommand habilitado (onde variáveis do cliente SSH são repassadas ao shell forçado, mesmo com uma conta restrita), clientes DHCP que executam scripts de configuração de rede recebendo opções do servidor DHCP como variáveis de ambiente (nesse caso o atacante precisa controlar a resposta DHCP, geralmente estando na mesma rede ou controlando o servidor), e qualquer software que gere ambiente a partir de dados de rede antes de invocar Bash (CUPS, git, alguns clientes de e-mail, dispositivos embarcados que usam Bash como shell padrão).

O CERT/CC classificou a exploração como ativa desde os primeiros dias de divulgação, e a Red Hat relatou circulação de malware explorando a falha em 29/09/2014 — worms automatizados escaneando a internet em busca de servidores CGI vulneráveis para instalar bots de DDoS e mineração. A presença no catálogo KEV da CISA, módulo Metasploit e template Nuclei confirmam que a exploração continua trivial de automatizar mesmo anos depois, contra qualquer instância legada ainda exposta.

A mitigação correta é atualizar o pacote Bash para uma versão que trate toda a cadeia CVE-2014-6271 + CVE-2014-7169 (e idealmente os CVEs subsequentes 6277/7186/7187), não apenas o primeiro patch — aplicar somente a correção original de CVE-2014-6271 deixa o sistema explorável via CVE-2014-7169. Nos pacotes Red Hat isso corresponde a: RHEL 7 bash-4.2.45-5.el7_0.4, RHEL 6 bash-4.1.2-15.el6_5.2, RHEL 5 bash-3.2-33.el5_11.4, RHEL 4 bash-3.0-27.el4.4 (mais variantes SJIS e EUS/AUS listadas pelo fornecedor). Distribuições e sistemas com Bash próprio (BSD, macOS, roteadores embarcados) precisam do patch equivalente do respectivo mantenedor/fornecedor; a lista completa de vendors afetados e status está no VU#252743 do CERT/CC.

Quando atualizar não é possível de imediato, o controle compensatório real é reduzir a superfície de exposição: desativar ou substituir scripts CGI que invocam Bash, trocar o shell padrão de serviços de rede (sshd com ForceCommand, DHCP hooks) para um interpretador não vulnerável, ou filtrar/normalizar cabeçalhos HTTP e demais entradas antes de repassá-las como variáveis de ambiente. Regras de WAF que bloqueiam a assinatura '() {' em cabeçalhos ajudam a reduzir exploração automatizada e oportunista, mas não fecham o vetor — atacantes podem variar a codificação ou usar vetores não-HTTP (DHCP, SSH) que o WAF não vê.

O que não funciona: acreditar que aplicar apenas o primeiro patch de setembro de 2014 resolve o problema — isso é exatamente o cenário que gerou CVE-2014-7169 e os CVEs seguintes. Também não basta trocar /bin/sh para outro shell se scripts ou serviços ainda invocam /bin/bash explicitamente.

O teste de diagnóstico publicado pela Red Hat e pelo CERT/CC identifica se uma instalação está vulnerável: executar 'env x='"'"'() { :;}; echo vulnerable'"'"' bash -c "echo this is a test"' e verificar se a palavra 'vulnerable' aparece na saída — se aparecer, o Bash ainda processa comandos após a definição de função. Para exploração remota via CGI, o sinal em log de acesso do Apache é a presença da assinatura '() {' em cabeçalhos como User-Agent, Referer, Cookie ou em parâmetros de query string, seguida de comandos shell (curl, wget, /bin/bash, base64 -d) — esse padrão é característico de scanners automatizados e do módulo Metasploit/Nuclei.

Para vetores fora de HTTP (SSH com ForceCommand, DHCP), não há assinatura de rede padronizada e confiável a se observar em logs convencionais de aplicação; a detecção nesses casos depende de monitoramento de execução de processos (EDR) capturando Bash filho gerando processos ou conexões de saída inesperadas a partir de daemons de rede, já que o tráfego em si não expõe claramente a variável de ambiente maliciosa.