CVE-2018-6789

Overflow de um byte na função de decodificação Base64 (b64decode) do Exim, acionável antes de qualquer autenticação através de comandos SMTP que usam Base64 (como AUTH). A DEVCORE, que reportou a falha, afirma que o bug existe desde o primeiro commit do Exim e afeta todas as versões anteriores à 4.90.1, com RCE pré-autenticação demonstrada e ao menos 400 mil servidores expostos segundo a estimativa dos pesquisadores.

A falha está em base64.c, na função b64decode. O código aloca um buffer de tamanho 3*(len/4)+1 bytes para armazenar os dados decodificados. Quando a string de entrada não é um Base64 válido e seu comprimento é da forma 4n+3, a rotina de decodificação consome 3n+2 bytes durante o processo, mas o buffer alocado só reserva 3n+1 — um byte de heap overflow (off-by-one, CWE-193/CWE-787). Normalmente esse byte extra cai em memória não utilizada e é inofensivo, mas o conteúdo escrito nesse byte é controlável pelo atacante, o que abre caminho para corromper metadados de heap adjacentes quando o layout de memória é manipulado.

O Exim usa alocadores próprios (store_get, store_malloc, store_free, store_reset) que, para certos tipos de buffer, chamam diretamente malloc/free do glibc. A DEVCORE identificou que o comando AUTH — usando qualquer authenticator baseado em Base64, como CRAM-MD5 — aloca o buffer de decodificação via store_get(), e que o buffer sender_host_name (preenchido pelo comando EHLO/HELO, liberado e realocado via store_free/store_malloc) pode ser posicionado no heap imediatamente após o buffer vulnerável. Isso torna o byte sobrescrito parte dos metadados de um chunk glibc controlável pelo atacante.

A exploração publicada pela DEVCORE depende de técnicas de heap grooming: forçar um chunk grande para o unsorted bin, encadear comandos EHLO/AUTH em sequência calculada para posicionar sender_host_name imediatamente após o buffer de decodificação, e usar o byte de overflow para corromper o tamanho do chunk seguinte, viabilizando um write arbitrário. É engenharia de exploração de heap glibc, não uma falha lógica simples de trigger direto.

O vetor é rede, sem necessidade de autenticação prévia: o comando SMTP AUTH (ou qualquer outro que envolva decodificação Base64) já é suficiente para acionar o overflow, desde que o servidor tenha algum authenticator baseado em Base64 habilitado — CRAM-MD5 é citado como exemplo, mas a DEVCORE afirma que qualquer authenticator que use Base64 também serve. Essa é a pré-condição real: a exploração testada exigiu autenticador Base64 descomentado na configuração (situação padrão em pacotes Debian/Ubuntu da época, mas não necessariamente universal).

Na prova de conceito da DEVCORE, contra Exim4 4.88/4.89 em Debian Stretch e Ubuntu Zesty, o exploit combina EHLO, MAIL FROM/RCPT TO e AUTH em sequência específica para manipular o heap do glibc, transformando o overflow de um único byte em corrupção de metadados de chunk e, a partir daí, em escrita arbitrária e execução de código — tudo antes de autenticação bem-sucedida (pre-auth RCE). Os próprios descobridores classificaram a exploração como não trivial (exige conhecimento de heap exploitation), mas confirmaram exploit funcional já no relato inicial ao Exim em fevereiro de 2018.

A CVE está no catálogo KEV da CISA, confirmando exploração observada in the wild além da PoC pública. Não há indicação nas fontes de que a exploração dependa de versão específica de glibc alterar a viabilidade — apenas que o layout de heap alvo foi verificado nos ambientes testados.

A correção definitiva é atualizar para Exim 4.90.1, que corrige o cálculo de tamanho do buffer em b64decode. Distribuições lançaram backports: Debian (aviso LTS) e Ubuntu (USN-3565-1) publicaram pacotes corrigidos para seus ramos suportados — consulte o aviso da própria distribuição para a versão exata do pacote corrigido, já que os números variam por release.

Antes do patch, o próprio mantenedor do Exim (Heiko Schlittermann) declarou publicamente que 'uma mitigação não é conhecida' — não há flag de configuração documentada que neutralize o bug sem aplicar o patch. Como pré-condição de exploração conhecida envolve authenticators Base64 (ex.: CRAM-MD5) habilitados no smtpd, desabilitar temporariamente authenticators SMTP baseados em Base64 reduz a superfície de ataque quando a atualização imediata não é possível, mas não é uma mitigação testada nem endossada oficialmente — trata-se de redução de exposição, não de correção.

Não há mitigação via WAF, já que a exploração ocorre no próprio protocolo SMTP em nível de aplicação/memória, não em payload HTTP. Filtrar ou limitar conexões SMTP não autenticadas na borda de rede reduz a exposição, mas não impede um cliente autenticado (ou uma sessão AUTH parcial) de acionar a falha.

Não há assinatura de rede amplamente documentada nas fontes consultadas para distinguir tentativas de exploração de uso legítimo de AUTH/Base64 em SMTP, já que o payload malicioso é uma sequência de comandos SMTP (EHLO, MAIL FROM/RCPT TO, AUTH) com strings Base64 malformadas de comprimento específico (4n+3) intercaladas para grooming de heap — algo que pode se assemelhar a tráfego SMTP legítimo malformado. Monitorar crashes ou reinícios inesperados do processo exim (SIGSEGV/SIGABRT) durante sessões SMTP, e logs de erro relacionados a decodificação Base64 malformada em rajadas repetidas do mesmo IP, são indicadores indiretos, mas não constituem detecção confiável de tentativa de exploração.