Pesquisadores demonstraram uma vulnerabilidade de buffer overflow no utilitário untgz do projeto zlib (v1.3.1.2) que permite a corrupção de memória e pode, dependendo de fatores de build e arquitetura, levar a execução de código via nomes de arquivo malformados passados pela linha de comando.
Detalhes técnicos
O problema reside na função TGZfname(), onde um strcpy() sem checagem copia o nome do arquivo de entrada para um buffer global estático de 1.024 bytes. Fornecendo um nome de arquivo maior que o limite, pesquisadores acionaram uma escrita fora dos limites que corrompe memória global imediatamente ao entrar na função — antes de qualquer parsing do arquivo.
Prova de conceito e evidências
Testes com AddressSanitizer (ASAN) demonstraram a exploração usando um argumento de 4.096 bytes, resultando em uma escrita de 2.001 bytes além do buffer protegido. A natureza global da corrupção implica que o efeito persiste além do escopo da função, com comportamento indefinido subsequente.
Impacto e risco
Os impactos relatados incluem negação de serviço (crashes), corrupção de objetos globais e a possibilidade de execução remota de código dependendo de fatores como flags de compilação, layout de memória e proteção do binário. A vulnerabilidade não requer privilégios especiais e tem complexidade de ataque baixa — basta invocar o utilitário com um nome de arquivo especialmente construído.
Ameaças concretas e ambiente afetado
O utilitário untgz é parte do ecossistema zlib; implantações variam por distribuição e pacotes empacotados. Como se trata de um utilitário de linha de comando usado para manipular arquivos TGZ, servidores, pipelines de CI/CD e ambientes que processem arquivos de terceiros em massa podem estar em risco caso a versão vulnerável esteja em uso.
Mitigação e recomendações
- Verificar a presença da versão afetada (v1.3.1.2) em sistemas e imagens de build; atualizar ou substituir por versão segura assim que disponível.
- Aplicar controles de entrada: validar e limitar o comprimento de argumentos em scripts que chamam utilitários de extração.
- Hardenizar builds: usar opções de compilador que dificultem exploração (fortify, ASLR, RELRO etc.) e monitorar execuções suspeitas via EDR/SIEM.
- Evitar processamento automático de TGZ provenientes de fontes não confiáveis sem inspeção prévia.
O que falta
Não há, na divulgação pública, um CVE numérico atribuído no momento. Também faltam dados públicos sobre exploits em campo ou uso ativo em campanhas maliciosas. A ausência dessas informações não reduz a gravidade técnica, mas altera a prioridade de resposta para cada organização conforme sua exposição.
Conclusão
A vulnerabilidade demonstra uma falha clássica de verificação de limites com impacto potencialmente severo. Equipes de segurança devem priorizar identificação de versões vulneráveis, mitigação de pipelines que processam arquivos externos e aplicação rápida de correções ou compensações até que uma correção oficial seja amplamente distribuída.
Fontes: demonstrações com ASAN e relato consolidado em Cyber Security News; detalhes técnicos publicados por pesquisadores em listas de divulgação.