Pesquisadores de segurança da depthfirst publicaram em 24 de julho um código de exploit funcional (prova de conceito de exploração) para uma falha no GitLab que a própria plataforma havia corrigido seis semanas antes, em 10 de junho. A vulnerabilidade permite executar comandos como o usuário git em qualquer servidor auto-hospedado na versão 18.11.3 que não tenha aplicado a atualização.
Qualquer usuário autenticado com permissão de envio (push) em um projeto consegue explorá-la. O atacante envia um Jupyter notebook manipulado e abre o diff (comparativo de alterações) do commit, o que vaza um ponteiro de heap (região de memória dinâmica alocada em tempo de execução). Com uma quantidade suficiente desses vazamentos, uma sondagem automatizada consegue localizar as bibliotecas na memória. Mais dois notebooks então disparam o payload (carga maliciosa). Não são necessários privilégios de administrador, acesso a CI (Integração Contínua) ou runners (executores de tarefas automatizadas), interação da vítima nem acesso a projetos de outros usuários.
O GitLab não classificou a correção como uma correção de segurança. Uma análise do The Hacker News identificou a atualização do Oj 3.17.3 listada entre correções de bugs na versão de patch de 10 de junho, e não na tabela de correções de segurança. Não há CVE (Vulnerabilidades e Exposições Comuns, o catálogo público de falhas), nem pontuação CVSS (Sistema Comum de Pontuação de Vulnerabilidades), nem qualquer menção à cadeia de exploração via diff de notebook. Operadores que priorizaram aquela versão com base na tabela de segurança não tinham motivos para tratá-la como urgente.
Como a cadeia de exploração funciona
Duas falhas de corrupção de memória no Oj, um parser (analisador) JSON (formato leve de troca de dados) para Ruby implementado majoritariamente em C nativo, tornam a cadeia possível. A depthfirst afirma que seu sistema sinalizou as falhas de forma autônoma, e os pesquisadores as encadearam manualmente.
O renderizador de notebooks do GitLab, uma gem (pacote de código) interna chamada ipynbdiff, repassa o JSON controlado pelo repositório, proveniente de arquivos .ipynb, para o método Oj::Parser.usual.parse dentro de um processo Puma (servidor HTTP em Ruby) de longa duração, de modo que bytes sob controle do atacante alcançam a memória em C, gerenciada manualmente pelo Oj, dentro do processo da aplicação.
Uma das falhas escreve além de uma pilha de aninhamento fixa de 1.024 bytes até obter controle do callback (função de retorno) de inicialização do parser. A outra trunca uma chave de objeto de 65.565 bytes para 29 em um campo signed (com sinal) de 16 bits e retorna um ponteiro de heap válido, que o GitLab renderiza no diff. O vazamento localiza a libc (biblioteca padrão da linguagem C), e a escrita redireciona o callback para a função system().
Todas as camadas são afetadas, CE (Edição Comunitária) e EE (Edição Enterprise), da Free até a Ultimate. O próprio Ruby não é. A versão Oj 3.17.2 já trazia outras correções da mesma revisão, mas não estas duas.
Como se proteger
Atualize para as versões 18.10.8, 18.11.5 ou 19.0.2. Nem o GitLab nem a depthfirst oferecem uma mitigação alternativa para quem não puder atualizar.
Um detalhe importante está no Helm (gerenciador de pacotes para Kubernetes) e no Operator: verifique a versão do GitLab dentro da imagem do Webservice que executa o Puma, e não a versão do chart (pacote Helm) ou do Operator. Instalações nas versões 15.2 a 18.9 não receberão backport (retroportação de correções para versões anteriores), pois essas linhas estão fora dos trens de patch mantidos para segurança do GitLab, de modo que essas instalações precisam migrar para uma versão suportada.
Impacto e limitações do exploit
Os comandos são executados como git, a conta por trás do Puma. O quanto isso vai além depende de como a instalação está isolada. Dentro do alcance estão: código-fonte, segredos do Rails, credenciais de serviços, dados de CI/CD (Integração e Entrega Contínuas) e serviços internos com os quais a aplicação consegue se comunicar.
O exploit público foi construído para o GitLab 18.11.3 em x86-64. Os offsets de gadgets (trechos de código reutilizáveis na memória), o estado dos registradores e o comportamento do jemalloc (alocador de memória) vieram dessa imagem, e a base de biblioteca recuperada só permanece válida até o processo mestre do Puma ser reiniciado, portanto não é uma solução pronta para uso contra qualquer alvo.
As falhas no Oj são genéricas; portar o exploit, porém, dá trabalho. A depthfirst mediu de cinco a dez minutos para a busca em memória em uma instalação nova com dois workers (processos de trabalho do Puma) e projeta de uma a duas horas em instalações de longa execução. A análise técnica completa traz a cadeia inteira.
Cronologia e divulgação
A depthfirst reportou as falhas do Oj em 21 de maio; o mantenedor incorporou as correções em 27 de maio, e a versão Oj 3.17.3 foi publicada em 4 de junho. A cadeia contra o GitLab foi enviada ao GitLab em 5 de junho, confirmada em 8 de junho e corrigida em 10 de junho. A depthfirst afirma não ter conhecimento de exploração em ambiente real e que o GitLab reproduziu a RCE (Execução Remota de Código) de forma independente. Sua análise mais ampla do Oj produziu nove outros advisories (avisos) de CVE, nenhum deles correspondente a esta cadeia.
O The Hacker News perguntou ao GitLab por que a correção não foi classificada como um problema de segurança e se um CVE será atribuído, e também questionou a depthfirst sobre a portabilidade do exploit. As respostas estão pendentes.
