CVE-2022-41352

Falha crítica no Zimbra Collaboration Suite (ZCS) 8.8.15 e 9.0 que permite a um atacante não autenticado, enviando apenas um e-mail malicioso, fazer o próprio serviço de antivírus/antispam (amavisd) extrair um arquivo para dentro do diretório público da webapp do Zimbra. O impacto real é execução remota de código via webshell, seguida de escalonamento para qualquer conta de usuário usando o comando administrativo zmprov gdpak. Está no catálogo KEV da CISA com exploração confirmada em campo antes mesmo da publicação formal do advisory.

A causa raiz (CWE-22, path traversal em extração de arquivo) está na forma como o amavisd processa anexos de e-mail que se parecem com arquivos tar/cpio para varredura de vírus. Quando o amavis usa o utilitário cpio para descompactar esses anexos, ele não valida symlinks nem caminhos relativos dentro do arquivo — um cpio malicioso pode conter uma entrada que é, na prática, um symlink apontando para fora do diretório de trabalho temporário (ex.: ../../../../../../jetty/webapps/zimbra/public/), seguida de uma entrada de arquivo que é escrita através desse symlink.

O atacante controla o conteúdo completo do anexo: o nome do arquivo, o caminho do symlink dentro do arquivo cpio, e o payload gravado (tipicamente um JSP webshell). O caso documentado publicamente usa um arquivo com extensão .jpg mas conteúdo real de tar/cpio GNU contendo uma entrada 'data' que é symlink para o diretório public da webapp, seguida da entrada 'data/searchx.jsp' com o webshell.

O problema de fundo é que cpio, por padrão, segue e cria symlinks sem sandboxing de caminho, enquanto pax (o utilitário alternativo) tem barreiras que impedem esse tipo de escrita fora do diretório de extração. O amavisd tem uma lista de preferência de utilitários para extração — quando pax está instalado no sistema, ele é usado automaticamente em vez de cpio; quando pax não está presente, o amavisd cai para cpio silenciosamente (emitindo apenas um WARN no log, não um bloqueio).

Após a gravação do JSP no diretório public (que é servido sem autenticação pela webapp do Zimbra), o atacante acessa o webshell diretamente pela URL pública e o usa para executar comandos no contexto do servidor Zimbra — incluindo zmprov gdpak, que gera um token de pré-autenticação para qualquer conta, permitindo login como qualquer usuário sem senha.

O vetor é puramente por e-mail: o atacante envia uma mensagem com um anexo craftado para qualquer endereço da organização vítima — não precisa ser um alvo específico, nem existir conta prévia, nem qualquer autenticação no ZCS. O único pré-requisito real é que a instalação do Zimbra seja standalone (MTA e mailstore no mesmo host ou acessível) e que o utilitário pax não esteja instalado no sistema operacional — condição comum em CentOS/RHEL a partir da versão 6, onde pax deixou de vir por padrão, mas era historicamente presumida como presente pelo Zimbra. Em Ubuntu, pax é listado como pré-requisito de instalação, então ambientes seguindo esse checklist tendem a não ser vulneráveis — mas isso não é garantido nem verificado pelo próprio instalador do Zimbra.

A exploração documentada publicamente foi observada em incidente real relatado por um administrador em fórum oficial do Zimbra: o anexo malicioso (disfarçado de imagem) foi processado automaticamente pelo amavisd no momento da entrega do e-mail, sem qualquer ação do usuário destinatário além de receber a mensagem. O webshell foi gravado no diretório /opt/zimbra/jetty/webapps/zimbra/public, acessível sem autenticação, e o atacante o usou para gerar preauth e assumir contas de outros usuários, depois apagando o e-mail original para encobrir rastros.

A complexidade técnica de construir o anexo é baixa — trata-se de um arquivo tar/cpio com uma entrada symlink e uma entrada de payload, sem necessidade de bypass de autenticação, CSRF ou interação da vítima além do recebimento do e-mail. Isso, combinado com o resultado final (RCE + acesso a qualquer conta), explica o CVSS 9.8 e a presença confirmada em exploração ativa antes da publicação do CVE, o que motivou a inclusão imediata no catálogo KEV da CISA.

A mitigação prática e imediata, segundo o próprio Zimbra, é instalar o utilitário pax no sistema operacional do servidor MTA/amavis. Uma vez presente, o amavisd passa a preferir automaticamente pax sobre cpio na ordem de extração configurada em amavisd.conf, eliminando o vetor de symlink malicioso — não é necessário editar manualmente a configuração além de garantir que o pacote esteja instalado (em RHEL/CentOS 7+ e derivados, pax não vem mais por padrão desde EL6; em Ubuntu costuma já estar entre os pré-requisitos de instalação do Zimbra, mas isso deve ser verificado, não presumido).

As fontes analisadas não confirmam um patch de código do ZCS que torne pax obrigatório ou remova cpio como fallback — o próprio fórum mostra que instâncias já atualizadas (Zimbra 9 Patch 26, e 8.8.15 Patch 33) permaneciam vulneráveis se pax não estivesse instalado no SO, pois o amavisd apenas registra um WARN no log e continua usando cpio silenciosamente. Ou seja, atualizar o ZCS por si só, sem garantir a presença do binário pax no sistema, não corrige a falha — esse é o mito a evitar.

Como controle compensatório adicional: revisar e restringir permissões de escrita no diretório /opt/zimbra/jetty/webapps/zimbra/public, verificar a configuração $pax em /opt/zimbra/conf/amavisd.conf.in (ou amavisd.conf gerado) para confirmar a ordem de preferência de utilitários, e monitorar os logs do amavis por qualquer ocorrência da mensagem de warning sobre uso de cpio em vez de pax — sua presença indica exposição ativa à falha independentemente da versão do ZCS instalada.

No log do amavis (tipicamente visível via syslog/maillog), a mensagem '(!)WARN: Using cpio instead of pax can be a security risk; please add: $pax='pax'; to amavisd.conf and check that the pax(1) utility is available on the system!' indica que o sistema está na configuração vulnerável (pax ausente), independentemente de ter sido ou não alvo de um anexo malicioso — vale a pena tratar como sinal de exposição, não apenas de exploração.

Como sinal de exploração já ocorrida, procurar por arquivos inesperados (especialmente .jsp) dentro de /opt/zimbra/jetty/webapps/zimbra/public/, e nos logs de entrega de e-mail (amavis) por anexos com extensões de imagem/documento comuns cujo conteúdo real seja um arquivo tar/cpio (identificável via 'file' mostrando 'POSIX tar archive' em vez do tipo esperado pela extensão). Acessos subsequentes a URLs sob /public/ para o(s) arquivo(s) suspeitos e uso do comando administrativo zmprov gdpak nos logs do zmmailboxd também são indicadores fortes de exploração bem-sucedida seguida de sequestro de conta.