CVE-2010-4344

CVE-2010-4344 é um heap-based buffer overflow na função string_vformat (string.c) do Exim, usada internamente para montar strings formatadas, inclusive linhas de log de rejeição SMTP. Um atacante remoto não autenticado pode corromper a heap do processo exim enviando uma sessão SMTP com dois comandos MAIL seguidos de uma mensagem grande com cabeçalhos malformados, obtendo execução de código com privilégios do usuário 'exim' — não root direto. A falha foi observada sendo explorada in-the-wild antes da divulgação pública, está no catálogo KEV da CISA e ganhou módulo Metasploit, tornando-a prioridade prática mesmo sem escalada automática para root.

A vulnerabilidade é um heap-based buffer overflow (CWE-122) dentro de string_vformat, a função tipo vsnprintf interna do Exim usada para construir mensagens formatadas, incluindo as linhas gravadas quando uma sessão SMTP é rejeitada. O caminho de código só é alcançado em um cenário de erro específico: uma sessão que emite dois comandos MAIL sem RSET entre eles é uma violação de protocolo que aciona a lógica de rejeição do Exim, a qual formata a mensagem recebida — incluindo cabeçalhos controlados pelo atacante — para registrar o motivo da rejeição no log.

O problema está no cálculo de tamanho de buffer feito antes ou durante essa formatação: quando a mensagem rejeitada é grande e contém cabeçalhos malformados/craftados, o tamanho real do conteúdo excede o espaço alocado na heap para a string de log, e string_vformat escreve além dos limites do buffer, corrompendo estruturas adjacentes na heap.

O atacante controla o conteúdo dos cabeçalhos da mensagem e o timing dos comandos MAIL — não controla diretamente endereços de memória, mas ao moldar cuidadosamente o tamanho e o conteúdo dos dados que acabam no buffer de log, pode influenciar o que é sobrescrito na heap, abrindo caminho para desvio de fluxo de execução. Por estar isolado em um caminho de tratamento de erro pouco exercitado por testes normais, o bug passou despercebido por anos até ser encontrado por exploração ativa.

O vetor é uma conexão SMTP direta ao Exim, sem necessidade de autenticação, TLS ou configuração não padrão — basta o serviço estar exposto e rodando versão vulnerável. O atacante abre uma sessão, emite dois comandos MAIL em sequência (violação de protocolo que força o caminho de rejeição) e envia, via DATA, uma mensagem grande com cabeçalhos craftados que, ao serem formatados para a linha de log de rejeição, disparam o overflow em string_vformat.

Transformar a corrupção de heap em execução de código confiável exige controle fino sobre layout de heap e conteúdo sobrescrito — não é trivial, mas foi alcançado por atacantes antes da divulgação pública (o CERT/CC registrou a falha como 'reported being exploited in the wild') e depois formalizado em módulo Metasploit, o que baixou a barreira de exploração para qualquer atacante com acesso de rede à porta SMTP.

O resultado da exploração bem-sucedida é execução de código com os privilégios do usuário que roda o Exim (tipicamente 'exim', não root). Para chegar a root a partir daí, é necessária uma falha adicional de escalada de privilégio — o próprio thread de coordenação da falha (oss-security, dez/2010) documenta CVE-2010-4345 como a vulnerabilidade companheira que permite ao usuário exim rodar comandos como root via manipulação de arquivos de configuração. Avaliar o risco real de CVE-2010-4344 isoladamente, portanto, exige considerar se esse segundo salto está disponível no ambiente.

A correção oficial é atualizar para Exim 4.70 ou versão posterior, que inclui o patch para string_vformat referenciado no commit 24c929a27415c7cfc7126c47e4cad39acf3efa6b do repositório git do Exim. Distribuições publicaram atualizações de pacote próprias antes ou junto com o release oficial — Debian, Ubuntu (USN-1032-1), openSUSE e Red Hat trataram o caso via seus próprios canais de segurança, então em ambientes com Exim empacotado pela distro o caminho é aplicar a atualização do pacote correspondente, não necessariamente subir para a tag 4.70 do upstream.

Se a atualização imediata não for possível, o único paliativo real é reduzir exposição de rede: restringir quem pode conectar na porta SMTP do Exim a fontes confiáveis (firewall, ACL de rede), o que limita mas não elimina o risco em servidores que precisam aceitar e-mail da internet pública. Não há flag de configuração do Exim documentada que desative a função de log de rejeição sem custo — desligar logging de rejeição tira visibilidade operacional e de segurança sem necessariamente impedir a chamada da função vulnerável em todos os cenários, e não deve ser tratado como mitigação equivalente ao patch.

Em logs SMTP/transcript, procurar sessões com dois comandos MAIL emitidos sem RSET intermediário seguidos de uma mensagem volumosa com cabeçalhos anômalos ou malformados — esse padrão de duplo MAIL é a assinatura comportamental citada na descrição oficial e replicada por ferramentas de exploração conhecidas (incluindo o módulo Metasploit). Nos logs do próprio Exim, crashes do processo, core dumps ou entradas de panic log relacionadas a formatação de rejeição são indícios de tentativa (bem ou mal sucedida) de exploração; no nível de processo, um daemon exim gerando shells ou processos filhos inesperados é sinal de comprometimento pós-exploração. Não existe uma assinatura de rede oficial e universalmente confiável além desse padrão de comandos SMTP, então detecção depende de logging habilitado e granular na camada de aplicação.