CVE-2022-30333

Falha de directory traversal no UnRAR (Linux/Unix) que permite, durante uma extração de arquivo RAR malicioso, escrever arquivos fora do diretório de destino — via validação incorreta de links simbólicos dentro do arquivo. O impacto real veio à tona quando pesquisadores da Sonar demonstraram que o Zimbra, que usa unrar via Amavisd para escanear anexos de e-mail, podia ser comprometido remotamente e sem autenticação, resultando em RCE completo. WinRAR e o RAR para Android não são afetados — só a implementação Unix/Linux do RarLab.

A causa raiz é um erro de validação de links simbólicos (CWE-59) dentro do processo de extração do unrar, que permite contornar a verificação de path (CWE-22) que deveria confinar todos os arquivos extraídos ao diretório de destino especificado na linha de comando. Um arquivo RAR malicioso pode conter uma entrada que, ao ser extraída, resolve — via symlink — para um caminho fora da árvore esperada, permitindo grava arbitrária em qualquer local para o qual o processo que executa o unrar tenha permissão de escrita.

O atacante controla o conteúdo do arquivo RAR: nome dos entries, estrutura de diretórios embutida e os links simbólicos usados para escapar do diretório de extração. O que ele não controla diretamente é o contexto de execução (usuário, diretório de trabalho, permissões) — isso depende de quem/o que invoca o unrar. A demonstração clássica da falha é criar um `~/.ssh/authorized_keys` no home do usuário que executa a extração, plantando uma chave SSH para acesso remoto persistente.

O caso Zimbra mostra o vetor de maior impacto prático: o pipeline de recebimento de e-mail (Postfix → Amavisd → unrar → Spamassassin/ClamAV → Zimbra) extrai automaticamente anexos RAR de e-mails recebidos, sem qualquer interação do destinatário. Como o Amavis roda com permissões amplas, o attacker conseguiu, na pesquisa da Sonar, escrever um shell JSP dentro do diretório web do Zimbra, obtendo execução de código pré-autenticação. A vulnerabilidade em si está no unrar — o Zimbra só expôs um caminho de invocação automática e não-supervisionada dele.

Pré-requisito central: alguma aplicação ou usuário no sistema-alvo precisa extrair, com um unrar vulnerável (build Linux/Unix do RarLab anterior à correção), um arquivo RAR fornecido ou influenciado pelo atacante. Isso é a condição que faz a severidade variar enormemente: em uma extração manual e local o risco é baixo; em serviços que processam anexos automaticamente — como scanners de spam/antivírus em servidores de e-mail — o vetor se torna remoto e pré-autenticado, sem interação do usuário.

No caso documentado do Zimbra, basta enviar um e-mail com um anexo RAR malicioso para qualquer caixa de correio da instância; o Amavisd extrai o anexo automaticamente para escaneamento de vírus/spam, invocando o unrar vulnerável e acionando a escrita fora do diretório de extração. Não é necessário estar autenticado no Zimbra nem que o destinatário abra o e-mail.

Há exploração confirmada em campo — a CVE está no catálogo KEV da CISA (adicionada em 09/08/2022) — e existem módulo Metasploit e PoC públicos, o que reduz a barreira técnica para reprodução. O EPSS próximo de 1.0 reflete essa disponibilidade de exploit e o histórico de uso ativo. O resultado final depende do contexto: no Zimbra, RCE completo via web shell; genericamente, qualquer escrita de arquivo capaz de ser abusada para persistência (chaves SSH, scripts de inicialização, cron, arquivos de configuração) na conta que roda a extração.

A correção oficial está no código-fonte do UnRAR a partir da versão 6.1.7, incorporada nos binários a partir da versão 6.12 disponibilizados pela RarLab. Atualizar diretamente pelo site do fornecedor é a orientação da Sonar, já que builds distribuídas por repositórios de distribuições podem ter numeração e cronograma de patch diferentes — vale checar a versão real instalada, não confiar apenas no nome do pacote.

Pacotes de distribuição têm suas próprias versões corrigidas: Debian corrigiu o pacote `rar` na versão 2:6.20-0.1~deb10u1 (Debian 10/LTS); Gentoo considera corrigido `app-arch/rar` >= 6.23 e `app-arch/unrar` >= 6.2.10. O advisory do Gentoo é explícito: não há workaround conhecido além de atualizar — não existe flag de configuração ou mitigação equivalente à correção real.

Para ambientes como Zimbra que invocam unrar automaticamente em pipelines de e-mail, a solução do fornecedor foi atualizar/substituir o binário empacotado; como controle compensatório quando a atualização não é imediata, é possível reduzir exposição desabilitando a extração automática de RAR em serviços de scanning (com custo de perder essa camada de verificação) ou isolando o processo de extração em ambiente sem permissão de escrita fora de um diretório temporário descartável. Rodar a extração como usuário sem home directory sensível e sem `.ssh` configurado reduz, mas não elimina, o impacto de um write arbitrário.

Não há assinatura de rede confiável, já que a exploração ocorre no momento da extração local de um arquivo RAR malicioso — o tráfego de entrega (e-mail com anexo RAR, upload de arquivo) não difere de um anexo legítimo até a análise do conteúdo interno do arquivo. Sinais úteis: arquivos RAR com entradas contendo links simbólicos ou caminhos que tentam escapar do diretório de extração (analisável estaticamente antes de extrair); em servidores de e-mail com Amavisd/ClamAV, logs de erro do unrar durante o processamento de anexos; criação inesperada de `~/.ssh/authorized_keys`, scripts de shell em diretórios de inicialização, ou arquivos JSP/PHP novos em diretórios web logo após o processamento de um anexo — no caso Zimbra, arquivos JSP não originados por ação administrativa no diretório da aplicação web são forte indício de exploração bem-sucedida.