CVE-2021-22205

GitLab CE/EE, a partir da versão 11.9, permite execução remota de código não autenticada através do processamento de metadados de imagens enviadas via GitLab Workhorse. Qualquer usuário que consiga fazer upload de um arquivo — inclusive anônimo em instâncias que permitem criar snippets sem login — pode obter execução de comando no servidor. É CVE crítica de fato: CVSS 10.0, sem necessidade de autenticação, sem interação do usuário, com exploração massiva documentada e presença no catálogo KEV da CISA.

O GitLab Workhorse encaminha arquivos enviados com extensão jpg, jpeg ou tiff para o ExifTool, a fim de remover tags de metadados não permitidas antes de armazenar a imagem. O problema é que o ExifTool ignora a extensão declarada do arquivo e detecta o formato real pelo conteúdo — permitindo que qualquer um dos parsers internos suportados seja acionado, bastando renomear o arquivo malicioso com uma das extensões aceitas.

Um desses formatos é o DjVu. Ao processar anotações DjVu, o ExifTool avalia (eval) os tokens do campo de metadado para 'converter sequências de escape estilo C'. Existe validação para garantir que aspas e caracteres especiais estejam corretamente escapados, mas essa validação falha em um caso específico: uma barra invertida seguida de nova linha é tratada como escape válido, o que permite fechar a string entre aspas prematuramente e injetar código Perl arbitrário na expressão avaliada.

Em termos de CWE, isso é classificado tanto como CWE-20 (validação de entrada imprópria) quanto CWE-95 (avaliação de código sob controle do atacante — eval injection). O atacante controla integralmente o conteúdo do campo de metadado Copyright (ou outro campo de anotação DjVu) dentro de um arquivo que ele constrói, disfarçado com extensão de imagem comum.

A falha está no ExifTool em si (na forma como GitLab o invoca sobre arquivos não confiáveis), não em código exclusivo do GitLab — por isso o vetor de exploração é o pipeline de upload/remoção de metadados do Workhorse, presente em qualquer fluxo que aceite upload de imagem (issues, snippets, wikis, comentários, avatares).

O vetor é um upload de arquivo disfarçado de imagem (extensão .jpg/.jpeg/.tiff) cujo conteúdo real é um documento DjVu com um bloco de metadados malicioso. O relatório original (HackerOne #1154542, pesquisador vakzz) demonstrou o ataque criando um snippet público em uma instância GitLab.com e anexando o arquivo malicioso pelo campo de descrição — sem necessidade de autenticação, já que a criação de snippets estava disponível para usuários anônimos naquele fluxo. Ao processar o upload, o Workhorse chama o ExifTool para sanitizar metadados, o parser DjVu avalia o payload injetado e executa o comando arbitrário sob o usuário do processo GitLab (tipicamente 'git').

Os pré-requisitos reais são: (1) a instância expor algum ponto de upload de arquivo processado pelo Workhorse/ExifTool — issues, snippets, wikis, comentários de merge request, avatares de projeto/usuário; (2) esse ponto ser acessível ao atacante, o que em muitas instalações inclui usuários anônimos (snippets públicos, registro aberto) e em outras exige apenas uma conta de usuário comum, sem privilégio elevado. Não há necessidade de interação de outro usuário nem de configuração não padrão além do upload estar habilitado — o que é o padrão do produto.

A exploração está confirmada em massa: entrada no catálogo KEV da CISA (adicionada em 2021-11-03, prazo de correção 2021-11-17), existência de módulo Metasploit, template Nuclei e PoCs públicas tornaram o ataque trivial de automatizar contra instâncias GitLab expostas na internet e não corrigidas, resultando em varreduras e comprometimentos em massa meses após a divulgação.

A correção definitiva é atualizar o GitLab CE/EE para uma versão corrigida da série 13.8, 13.9 ou 13.10 (ou posterior). O fornecedor não expôs um workaround de configuração oficial amplamente documentado além de aplicar o patch — a ação recomendada registrada no catálogo KEV é 'aplicar atualizações conforme instrução do fornecedor', sem menção a mitigação alternativa formal.

Se a atualização imediata não for viável, o controle compensatório mais direto é restringir ou desabilitar temporariamente pontos de upload de arquivo acessíveis a usuários anônimos ou não confiáveis (criação pública de snippets, uploads em issues/wikis abertos), reduzindo a superfície até a atualização. Isso é paliativo parcial: qualquer usuário autenticado com permissão de upload ainda consegue explorar a falha, então não substitui o patch.

Não funciona como mitigação apenas bloquear extensões de arquivo no WAF ou validar extensão no cliente — a própria falha existe porque o ExifTool ignora a extensão declarada e detecta o formato pelo conteúdo, então filtros baseados em extensão não impedem o ataque.

Nos logs do GitLab Workhorse e do ExifTool, procure por chamadas ao processamento de metadados de arquivos com extensão .jpg/.jpeg/.tiff cujo conteúdo real seja um documento DjVu — isso é anômalo e um forte indicador de tentativa de exploração. Em nível de sistema, processos filhos inesperados gerados pelo usuário de execução do GitLab (comumente 'git') a partir do processo exiftool, ou artefatos de comando (arquivos criados, conexões de shell reversa) originados por esse usuário, são sinal de comprometimento.

Não há um padrão de tráfego HTTP único e confiável para identificar a tentativa apenas pela requisição, já que o upload malicioso se parece com um upload de imagem legítimo em qualquer endpoint que aceite anexos — a distinção só aparece na inspeção do conteúdo do arquivo (assinatura DjVu em vez de JPEG/TIFF real) ou no comportamento pós-exploração no servidor.