CVE-2014-6278

CVE-2014-6278 é a sexta e mais grave falha da série Shellshock: mesmo em sistemas já corrigidos contra o CVE-2014-6271 original, o parser de definições de função do Bash continuava aceitando código arbitrário embutido em variáveis de ambiente, permitindo execução remota de comandos completa (não apenas leitura de memória, como no CVE-2014-6277 irmão). Foi descoberta por Michal Zalewski (lcamtuf) via fuzzing dias após o patch inicial, mostrando que a correção da Red Hat/upstream para o CVE-2014-6271 era incompleta. Importa porque qualquer serviço que exporte variáveis de ambiente controláveis por um atacante para um processo Bash — CGI, ForceCommand do SSH, clientes DHCP, scripts de sistema — fica vulnerável a RCE trivial, sem autenticação.

A causa raiz é a mesma do CWE-78 do CVE-2014-6271: o Bash, ao importar uma variável de ambiente cujo valor tem a forma de uma definição de função (prefixo '() {'), invoca seu parser interno para reconstruir a função. O patch original para o CVE-2014-6271 tentou apenas truncar o parsing no fim do corpo da função declarada, sem isolar de fato o parser de entrada não confiável — Zalewski descreveu essa abordagem como assentada em duas premissas frágeis: que o parsing de funções controladas pelo atacante não teria efeitos colaterais no código confiável executado depois, e que o parser (não projetado para lidar com entrada hostil) estaria livre de bugs de C.

A segunda premissa caiu rápido: Tavis Ormandy achou o CVE-2014-7169 (o parser continuava procurando um nome de arquivo de redirecionamento além da fronteira do trecho não confiável). A primeira caiu com o CVE-2014-6277, um uso de memória não inicializada em make_redirect()/copy_redirect() que Zalewski achou fuzzando com AFL. Horas depois do 6277, o mesmo fuzzing produziu o CVE-2014-6278: um caso ainda mais direto, do tipo 'coloque seus comandos aqui', em que — mesmo com o patch original do 6271 e o patch subsequente para o 7169 aplicados — era possível construir uma variável de ambiente que levava o Bash a executar comandos arbitrários após a definição de função ser processada.

Em outras palavras, o CVE-2014-6278 demonstra que o modelo de correção 'consertar o parser para não vazar execução após o fim da função' era estruturalmente insuficiente enquanto o parser continuasse recebendo, sem isolamento, strings de origem remota. A solução real proposta por Florian Weimer (Red Hat) — e que Zalewski recomenda aplicar imediatamente — é isolar a funcionalidade de exportação de função num namespace prefixado, de forma que variáveis comuns como HTTP_COOKIE nunca cheguem a esse caminho de código.

O vetor é idêntico ao do Shellshock original: qualquer mecanismo que passe uma string controlada pelo atacante como valor de uma variável de ambiente que depois é herdada por um processo Bash. Os exemplos citados no advisory são CGI/mod_cgi e mod_cgid do Apache HTTP Server (via cabeçalhos HTTP mapeados para variáveis de ambiente), o recurso ForceCommand do OpenSSH sshd, e scripts executados por clientes DHCP a partir de opções fornecidas pelo servidor DHCP. Em todos os casos a pré-condição real é uma fronteira de privilégio em que quem define a variável de ambiente (rede, cliente HTTP, servidor DHCP malicioso) é menos confiável que o processo Bash que a herda — não é necessário estar autenticado no serviço-alvo.

A diferença prática frente ao CVE-2014-6271 é que o CVE-2014-6278 funciona mesmo em ambientes já corrigidos contra a falha original (e, em alguns casos, também contra o CVE-2014-7169), porque a correção inicial só bloqueava a forma específica de payload usada nos primeiros PoCs, sem eliminar a classe de bug. Não há PoC público detalhado nas fontes consultadas aqui (Zalewski deliberadamente reteve os detalhes técnicos por alguns dias para dar tempo de patch), mas a mecânica — construção de uma definição de função cujo corpo, ao ser reparseado, resulta em execução de comandos adicionais — é a mesma família de abuso do parser de funções do Bash.

A CVE está no catálogo KEV da CISA e possui módulo Metasploit, refletindo exploração massiva e automatizada do conjunto Shellshock (CVE-2014-6271/7169/6277/6278/7186/7187) contra servidores web expostos via CGI logo após a divulgação em setembro/outubro de 2014 — a maior parte da exploração observada na prática mirava o vetor CGI genérico, não necessariamente distinguindo qual CVE específica da família estava sendo usada.

A correção definitiva é atualizar para uma versão de Bash que incorpore o patch de Florian Weimer, que isola a exportação de funções num namespace prefixado em vez de tentar apenas truncar o parsing — essa abordagem foi incorporada upstream e distribuída pelos mantenedores de distribuição pouco depois da divulgação (referenciada nos avisos de segurança da Oracle Linux e openSUSE listados abaixo, entre outros). A descrição oficial do CVE afirma que o Bash é vulnerável 'through 4.3 bash43-026', ou seja, todo patch level até o 026 do ramo 4.3 está exposto; aplique o patch/pacote da sua distribuição que corresponda à correção pós-026 do mantenedor.

Se não for possível atualizar imediatamente, o teste indicado por Zalewski para verificar exposição é executar, com uma variável de ambiente contendo uma definição de função mínima, um subshell Bash e observar se o corpo da função é reparseado incorretamente — qualquer sistema que ainda aceite esse padrão deve ser tratado como vulnerável a RCE remoto, mesmo que já tenha recebido o patch original do CVE-2014-6271. Não confie em filtros de WAF que bloqueiam apenas a assinatura '() { ' clássica: como o próprio conjunto de CVEs Shellshock demonstrou, pequenas variações na sintaxe de definição de função (redirecionamentos, here-documents, aninhamento) contornam bloqueios baseados em assinatura simples — a mitigação técnica real é o patch do parser, não filtragem de payload.

Como controle compensatório onde a atualização não é imediata, remover ou reduzir a superfície de exposição de variáveis de ambiente controladas externamente para processos Bash (por exemplo, migrar CGI para tecnologias que não invoquem shell, restringir ForceCommand a binários que não sejam shells, sanitizar opções de DHCP antes de scripts de cliente) reduz o risco, mas não elimina a vulnerabilidade subjacente no interpretador.

O teste funcional citado por Zalewski para verificar exposição residual é definir uma variável de ambiente com uma função mínima (por exemplo, do tipo '_x="() { echo vulnerable; }" bash -c ...') e observar se o Bash ainda interpreta esse padrão como função exportável sem aplicar o isolamento de namespace — se sim, o sistema está exposto tanto ao CVE-2014-6271/7169 quanto potencialmente ao 6278. Em logs de servidores web, indícios de tentativas de exploração da família Shellshock aparecem como cabeçalhos HTTP (User-Agent, Referer, Cookie etc.) contendo a sequência '() {' seguida de comandos, mas como o CVE-2014-6278 explora variações do parser após payloads que pareciam neutralizados pelo patch original, não há uma assinatura de log única e confiável que distinga essa CVE especificamente das demais do grupo Shellshock — qualquer ocorrência da sequência de definição de função em campos de entrada HTTP deve ser tratada como tentativa de exploração da família completa.