CVE-2014-7169
Priorize a correção. Ela está sob exploração confirmada pelo CISA, tem prova de conceito pública e 46 grupo(s) de ameaça a utilizam.
Grupos conhecidos por explorar esta vulnerabilidade (atribuição MITRE ATT&CK).
Apply updates per vendor instructions.
Resumo
CVE-2014-7169 é a segunda falha do episódio Shellshock: o patch inicial para CVE-2014-6271 impediu a execução de comandos colocados diretamente após a definição de função em uma variável de ambiente, mas não impediu que Bash continuasse processando texto residual após o fechamento da função, permitindo escrita de arquivos e execução de código adicional. Afeta qualquer serviço que passe entrada de rede não confiável para variáveis de ambiente antes de invocar Bash — CGI, ForceCommand do OpenSSH, clientes DHCP — tornando-a tão crítica quanto a original apesar de ser tratada como 'correção incompleta'.
Detalhamento técnico
O bug original (CVE-2014-6271, CWE-78) explora o fato de que Bash, ao importar variáveis de ambiente no formato de definição de função ('() { ... }'), continuava executando qualquer comando escrito após o corpo da função dentro daquela mesma string de ambiente. O primeiro patch tentou bloquear isso rejeitando comandos colocados imediatamente após o '}' de fechamento, mas manteve permissivo o parser de function-definition para certas sequências malformadas.
CVE-2014-7169 mostra que, com uma definição de função deliberadamente quebrada — por exemplo usando um subshell aninhado seguido de operadores de redirecionamento como '=>' — o parser do Bash ainda processa strings residuais que vêm depois. O vetor de teste documentado pela Red Hat usa 'env x=() { (a)=>\\' bash -c echo date', que gera efeitos colaterais: no ambiente afetado isso cria um arquivo (por exemplo /tmp/echo) e ainda imprime a saída do comando 'date', comprovando que trecho de código após o fechamento malformado da função continua sendo interpretado.
O atacante controla o conteúdo da variável de ambiente que chega ao Bash através de uma fronteira de privilégio — isto é, um processo com privilégio diferente (ou origem remota) define a variável e o Bash a interpreta ao ser invocado. O resultado documentado é escrita arbitrária de arquivos; o texto da CVE deixa aberto 'possibly other unknown impact', o que na prática pode incluir execução adicional de comandos dependendo do que o processo host faz com a variável reimportada.
A causa raiz é a mesma da CVE-2014-6271: o parser de função do Bash mistura análise de definição de função com análise de comandos subsequentes na mesma string, sem delimitação robusta do fim do bloco de função. O fix definitivo (na série de patches bash43-026 em diante, junto com CVE-2014-6277/6278/7186/7187) reescreveu a forma como Bash nomeia e importa funções exportadas, introduzindo o prefixo 'BASH_FUNC_nome()' para eliminar a ambiguidade entre nome de variável e nome de função.
Como é explorada
O vetor de exploração é qualquer situação em que um atacante controla o valor de uma variável de ambiente que atravessa uma fronteira de privilégio antes de chegar ao Bash — não é necessário shell interativo nem autenticação prévia no serviço afetado. Os cenários citados pelo próprio texto da CVE e pelos advisories incluem: CGI/mod_cgi e mod_cgid do Apache (o servidor web transforma cabeçalhos HTTP em variáveis de ambiente como HTTP_USER_AGENT), OpenSSH com ForceCommand configurado (a variável SSH_ORIGINAL_COMMAND pode ser manipulada por um usuário autenticado com shell restrito), e scripts disparados por clientes DHCP processando opções fornecidas por um servidor DHCP malicioso na rede local.
A pré-condição real não é 'ter Bash instalado' — é ter uma aplicação ou serviço que aceite entrada externa e a repasse como variável de ambiente para um processo Bash. Isso descarta a maioria dos usuários desktop comuns como vetor remoto direto, mas cobre virtualmente todo servidor web com CGI legado, dispositivos embarcados com interfaces administrativas baseadas em CGI, e appliances que usam Bash em scripts de rede — daí a gravidade prática mesmo sem shell remoto óbvio.
Há exploração ativa confirmada e malware documentado circulando explorando a família Shellshock (CVE-2014-6271/7169/6277/6278/7186/7187 tratadas em conjunto pelos vendors), e a CVE está no catálogo KEV da CISA. A CVE-2014-7169 especificamente é caracterizada pelos próprios fornecedores como 'mitigada pelos pacotes já disponíveis para a correção anterior' em alguns casos, mas o Red Hat deixou explícito que era uma falha distinta que exigia patch adicional — não apenas reaplicar o fix de 6271.
Versões
Como se proteger
A mitigação correta é atualizar o pacote Bash para a versão que inclui o conjunto completo de patches pós-Shellshock (bash43-025 e sucessivos, consolidados nas atualizações de distribuição: Red Hat listou bash-4.2.45-5.el7_0.4 para RHEL7, bash-4.1.2-15.el6_5.2 para RHEL6, bash-3.2-33.el5_11.4 para RHEL5 e bash-3.0-27.el4.4 para RHEL4, todas endereçando CVE-2014-6271 e CVE-2014-7169 juntas). Distribuições e fornecedores de appliance emitiram pacotes equivalentes; a única forma confiável de saber se um sistema está corrigido é testar diretamente com os comandos de diagnóstico publicados pela Red Hat, não confiar em número de versão isolado, já que várias distros fizeram backport dos patches sem alterar o número principal do Bash.
Onde atualização imediata não é possível, o paliativo real é reduzir a superfície de exposição: desabilitar ou remover CGI legado em servidores web (mod_cgi/mod_cgid), remover ou reconfigurar ForceCommand em sshd quando expõe SSH_ORIGINAL_COMMAND a usuários não confiáveis, e restringir acesso de rede a serviços que repassam variáveis de ambiente controladas externamente. Regras de WAF que filtram o padrão '() {' em cabeçalhos HTTP reduzem exploração via CGI mas não corrigem a causa e são facilmente contornáveis por variações de payload.
O que não funciona: aplicar apenas o patch para CVE-2014-6271 e considerar o problema resolvido — foi exatamente essa lacuna que gerou a CVE-2014-7169, e a cadeia de correções continuou até CVE-2014-6277/6278/7186/7187. Trocar o shell padrão do sistema para outro interpretador não remove o risco se aplicações continuam invocando /bin/bash explicitamente, o que é comum em scripts CGI e de sistema.
Como detectar
O teste de diagnóstico documentado pela Red Hat identifica exposição local: executar 'env x=() { (a)=>\\' bash -c "echo date"; cat /tmp/echo' após remover previamente esse arquivo — se o sistema exibir a data e o arquivo for criado, está vulnerável a CVE-2014-7169 especificamente (distinto do teste genérico de Shellshock que usa apenas 'echo vulnerable'). Em logs de servidores web, sinais de tentativa de exploração da família Shellshock incluem cabeçalhos HTTP (User-Agent, Referer, Cookie) contendo a sequência literal '() {' seguida de comandos shell, capturados em access logs de CGI.
Não há uma assinatura de rede única e confiável para CVE-2014-7169 isoladamente, já que ela é frequentemente testada e explorada em conjunto com CVE-2014-6271 e as CVEs subsequentes da mesma cadeia (6277, 6278, 7186, 7187); detecção prática tende a tratar toda a família Shellshock como um único padrão de busca em logs e IDS.