CVE-2016-3718

CVE-2016-3718 é a falha de Server-Side Request Forgery (SSRF) dentro do conjunto de vulnerabilidades conhecido como 'ImageTragick', divulgado em maio de 2016. Os coders HTTP e FTP do ImageMagick, usados pelos formatos MVG e SVG para buscar recursos externos referenciados em uma imagem, fazem a requisição sem validar ou restringir o destino, permitindo que um atacante force o servidor que processa a imagem a fazer requisições HTTP GET ou abrir sessões FTP para qualquer host/porta que o atacante escolher. É de baixa severidade isolada (CVSS 5.5, sem RCE), mas ganha peso porque estava embutida no mesmo lote que trazia CVE-2016-3714 (RCE via injeção de shell no delegate) e outras falhas de leitura/exclusão/movimentação de arquivo — qualquer serviço que aceite upload de imagem e use ImageMagick com policy.xml padrão da época estava exposto a todo o pacote.

A causa raiz é CWE-918 (Server-Side Request Forgery). ImageMagick decide o tipo de arquivo pelo conteúdo, não pela extensão, então um arquivo com magic bytes de MVG ou SVG é processado pelo parser correspondente mesmo renomeado para .jpg ou .png. Dentro de um arquivo MVG (Magick Vector Graphics) ou SVG, uma primitiva como 'fill' ou o atributo xlink:href pode referenciar uma URL com esquema http://, https:// ou ftp://; o parser resolve esse recurso via os coders HTTP/FTP do próprio ImageMagick, que fazem a chamada de rede diretamente do processo que está convertendo a imagem.

O atacante controla integralmente a URL de destino — host, porta e, no caso de FTP, credenciais embutidas na URL. Não há lista de bloqueio de IPs internos (RFC1918, link-local, metadata endpoints de cloud) nem validação de esquema além do parsing do próprio formato. O request parte da rede interna do servidor vulnerável, com a identidade de rede desse servidor, contornando qualquer controle de perímetro que dependa de origem.

A falha compartilha a mesma superfície de ataque do restante do lote ImageTragick: os pseudo-protocolos e coders do ImageMagick (label:, msl:, ephemeral:, https:, http:, ftp:) são todos acessíveis a partir de conteúdo de imagem controlado pelo atacante, sem que a aplicação hospedeira precise fazer nada de especial além de chamar convert/identify (ou a API C/PHP equivalente) sobre um arquivo não confiável.

O ChangeLog oficial do projeto (referenciado no advisory) mostra que a correção passou a restringir/desabilitar esses coders por padrão via policy.xml, em vez de reescrever a lógica de resolução de URL para bloquear ranges internos — ou seja, o fix é primariamente uma mudança de política de acesso, não uma sanitização de destino.

Vetor: entrega de um arquivo MVG ou SVG malformado (ou disfarçado com extensão de imagem comum) para qualquer fluxo que processe imagens com ImageMagick — upload de avatar, geração de thumbnail, conversão de documento, etc. Pré-requisito real: a aplicação precisa chamar o ImageMagick sobre conteúdo fornecido pelo usuário sem restringir os coders habilitados; não é preciso autenticação no ImageMagick em si, só a capacidade de fazer a aplicação-alvo processar o arquivo (que costuma ser um simples upload público). Não exige interação de usuário final além do próprio pipeline de processamento da aplicação — a exploração é automática no momento da conversão.

O resultado prático é o servidor fazendo uma requisição HTTP GET ou sessão FTP para um destino escolhido pelo atacante. Isso serve para: scanning de rede interna a partir do IP do servidor, consulta a serviços de metadata de provedores de nuvem, bypass de firewall/ACL baseado em origem, ou como primitiva de exfiltração (o servidor confirma que o request foi feito, revelando alcance de rede). Por si só CVE-2016-3718 não gera RCE nem leitura de arquivo — isso vem das CVEs vizinhas do mesmo lote (3714, 3715, 3716, 3717) exploradas com a mesma técnica de arquivo MVG/SVG malformado.

A falha está no catálogo KEV da CISA, confirmando exploração ativa observada, e há PoC pública circulando desde a divulgação original (a análise técnica do pesquisador do Mail.Ru, publicada na lista oss-security, mostra o payload MVG mínimo usado para disparar a requisição). Dado que o PoC é trivial — poucas linhas de MVG — e a vulnerabilidade está presente em qualquer pipeline de upload de imagem não corrigido, o custo de exploração é baixo.

Correção do fornecedor: atualizar para ImageMagick 6.9.3-10 ou posterior no ramo 6.x, ou 7.0.1-1 ou posterior no ramo 7.x. Distribuições backportaram a correção em seus próprios ciclos (Red Hat via RHSA-2016:0726 para RHEL 6/7; openSUSE, Debian e Gentoo têm advisories equivalentes referenciados). Para GraphicsMagick, que compartilha o mesmo modelo de coders, a correção do CVE-2016-3718 chegou via DLA-1401-1 (Debian LTS) na versão 1.3.20-3+deb8u3.

Se não for possível atualizar imediatamente, o paliativo real e amplamente adotado na época foi editar /etc/ImageMagick/policy.xml para desabilitar explicitamente os coders EPHEMERAL, HTTPS, HTTP, URL, FTP, MVG, MSL, TEXT e LABEL (é o que o próprio pacote atualizado da Red Hat passou a trazer como policy.xml padrão). Isso bloqueia a via de exploração sem exigir recompilação, mas tem custo: qualquer funcionalidade da aplicação que dependa legitimamente desses coders (por exemplo, converter SVG com referências remotas) para de funcionar. Restringir os coders via policy.xml é mitigação efetiva mesmo depois do patch, como camada de defesa em profundidade.

O que NÃO funciona: filtrar por extensão de arquivo ou usar 'identify' para validar o conteúdo antes da conversão — o próprio 'identify' é vulnerável ao mesmo parsing malicioso, e o ImageMagick detecta tipo por conteúdo, não por extensão, então renomear o arquivo de entrada não impede nada. Sanitizar apenas o nome do arquivo de saída também não mitiga, pois a falha está na resolução da URL embutida no MVG/SVG de entrada, não no nome do arquivo.

Em logs de aplicação ou proxy de saída, o sinal é uma requisição HTTP ou sessão FTP originada do processo/host que executa ImageMagick (convert, identify, ou bibliotecas que o invocam) para destinos incomuns — IPs internos (RFC1918, 169.254.169.254 e variantes de metadata de nuvem), portas atípicas, ou domínios que não fazem parte do fluxo normal da aplicação. Correlacionar esses requests de saída com uploads de imagem recentes no mesmo intervalo de tempo é o indicador mais confiável.

No nível de arquivo, arquivos de upload que contenham cabeçalho/marcadores de MVG ou SVG com URLs em atributos como fill, xlink:href, ou primitivas 'image'/'url' apontando para http://, https:// ou ftp:// são o artefato de exploração, independente da extensão declarada. Não há assinatura de rede única confiável porque o tráfego gerado é indistinguível de um request HTTP/FTP legítimo do ponto de vista do destino; a detecção depende de monitorar a origem (o próprio servidor de processamento de imagens) fazendo esse tipo de request, o que normalmente não deveria ocorrer.