CVE-2020-12641

Falha de command injection (CWE-78) em rcube_image.php do Roundcube Webmail, herdada por qualquer versão anterior à 1.4.4 (e correspondentes 1.3.11/1.2.10). O código concatenava o valor das opções de configuração im_convert_path e im_identify_path diretamente num comando de shell sem escapar caracteres especiais, permitindo execução arbitrária de comandos no servidor. O CVSS 9.8 sugere um ataque remoto trivial e sem autenticação, mas a exploração real depende de o instalador do Roundcube (installer/index.php) estar acessível publicamente e com o arquivo de configuração gravável — algo que o próprio fornecedor classifica como cenário de risco raro em produção, embora ainda assim documentado e explorado na prática (está no KEV da CISA).

O problema está nos métodos resize(), convert() e identify() de program/lib/Roundcube/rcube_image.php. Esses métodos montam uma string de comando concatenando o caminho configurado do ImageMagick (im_convert_path ou im_identify_path) com argumentos fixos (flags de qualidade, resize, formato) e depois passam essa string para rcube::exec(), que executa via shell. Os placeholders de argumento ({in}, {out}, {size} etc.) já eram devidamente escapados, mas o próprio valor de $convert/$cmd — origem da configuração — não passava por nenhuma sanitização antes de entrar na string de comando.

Se im_convert_path ou im_identify_path contiver metacaracteres de shell (ponto e vírgula, pipe, backticks, `$()`, `&&` etc.), o que vem depois do metacaractere é interpretado como um comando adicional pelo shell, e não como argumento do binário do ImageMagick. Isso é injeção de comando clássica: o atacante controla integralmente o valor dessas duas chaves de configuração.

A correção (commit fcfb099) envolve chamar escapeshellcmd() sobre o valor de $convert/$cmd antes de concatenar, nos três pontos onde isso ocorria (resize, convert, identify). Não há sanitização de entrada anterior a essa mudança — a superfície inteira do bug é a ausência desse escape.

O gatilho de execução é automático: o Roundcube chama identify()/convert()/resize() sempre que precisa processar uma imagem anexada ou embutida num e-mail (por exemplo, converter um formato não padrão como TIFF para JPEG para exibição). Basta a vítima abrir/visualizar o e-mail malicioso — não é preciso clicar em nada além disso.

O vetor documentado publicamente (DrunkenShells) funciona em duas etapas. Primeiro, o atacante envia uma requisição POST para installer/index.php contendo o payload de injeção no campo _im_convert_path (por exemplo, um comando para abrir uma reverse shell em PHP), fazendo o instalador escrever essa configuração maliciosa no arquivo de configuração do Roundcube. Segundo, o atacante envia à vítima um e-mail com uma imagem em formato não padrão (ex.: TIFF); quando qualquer usuário abre esse e-mail no webmail, o Roundcube tenta converter a imagem chamando o 'ImageMagick' configurado, executando o comando injetado e devolvendo shell reversa ao atacante.

A pré-condição crítica que a manchete de CVSS 9.8 esconde é a etapa um: o script installer/ precisa estar acessível pela rede e o config.inc.php precisa ser gravável pelo processo web — situação que o Roundcube já orienta a eliminar (remover ou bloquear o diretório installer/ após a configuração inicial) exatamente por ser um vetor de comprometimento total. Em instalações onde isso foi feito corretamente, a falha não é explorável remotamente por um atacante não autenticado; ela só se torna crítica em instalações negligenciadas, PaaS/hosting compartilhado com instalador exposto, ou onde um administrador malicioso/comprometido já tem acesso a essas configurações.

Há exploração confirmada em ambiente real (entrada no catálogo KEV da CISA), PoC pública e template Nuclei, o que eleva o EPSS (~0,84) mesmo considerando a pré-condição. Uma vez atingido o RCE, o impacto é total: comprometimento do processo do webmail, acesso a e-mails de todos os usuários, pivotagem lateral a partir do servidor de mail.

Atualizar para Roundcube Webmail 1.4.4 ou posterior. Os ramos mais antigos foram corrigidos em versões correspondentes — a documentação do fornecedor e o writeup de terceiros citam 1.3.11 e 1.2.10 como os releases de correção para as respectivas séries 1.3.x e 1.2.x. Se não for possível atualizar imediatamente, o controle compensatório real é garantir que o diretório installer/ esteja removido do servidor de produção ou bloqueado por controle de acesso (é a orientação padrão do próprio projeto após qualquer instalação/upgrade) e que o arquivo config.inc.php não seja gravável pelo processo do servidor web depois da configuração inicial — isso fecha o único caminho prático de injetar valores maliciosos em im_convert_path/im_identify_path.

Após a correção original (1.4.4/1.3.11/1.2.10), foi descoberto um bypass (via injeção de flags em executáveis arbitrários e chamada de executáveis remotos em ambientes Windows) corrigido em versões posteriores (1.4.5/1.3.12) — quem aplicou apenas o patch de CVE-2020-12641 sem seguir para essas versões ainda pode estar exposto a essa variante, tratada sob outro identificador.

Não funciona como mitigação apenas restringir quem pode enviar e-mails à organização, já que o vetor de disparo (imagem não padrão em e-mail) é passivo e não depende de autenticação do remetente; o controle efetivo está em nunca permitir que im_convert_path/im_identify_path sejam alteráveis por terceiros e em manter o instalador fora de alcance.

Nos logs do servidor web, procurar requisições POST para /installer/index.php contendo os parâmetros _im_convert_path ou _im_identify_path com metacaracteres de shell (;, |, `, $(), &&, quebras de linha) ou comandos incomuns (fsockopen, exec, bash, powershell, curl, wget). Revisar o config.inc.php de instâncias em produção para valores de im_convert_path/im_identify_path que não sejam simplesmente o caminho de binário do ImageMagick — qualquer coisa com espaço seguido de outro comando é suspeita.

No nível de host, monitorar processos filhos anômalos originados pelo processo PHP/webmail no momento em que mensagens com anexos de imagem são abertas ou processadas (thumbnails), especialmente conexões de rede saindo do servidor de mail sem relação com tráfego IMAP/SMTP esperado. Não há uma assinatura de rede única confiável para o payload em si, já que o comando injetado é arbitrário — o sinal mais forte é a presença do instalador acessível publicamente, que por si só já indica risco independente de tentativa de exploração observada.