CEVIU Logo
Voltar
Execução Remota de Código no GitLab por Duas Vulnerabilidades de Corrupção de Memória em Ruby

Vulnerabilidades Críticas no GitLab Permitem Execução Remota de Código Via Corrupção de Memória em Ruby

Aprofundamento CEVIU

Aprofundamento

A vulnerabilidade crítica no GitLab, que permite a execução remota de código (RCE) por meio de corrupção de memória em Ruby, é um exemplo clássico de como falhas em dependências de baixo nível podem comprometer sistemas complexos. A exploração, detalhada pelos pesquisadores da DepthFirst, começou com o encadeamento de dois bugs no parser Oj JSON, amplamente utilizado em aplicações Ruby, incluindo o GitLab. Uma gravação não verificada na pilha de aninhamento (nesting-stack) e um truncamento inseguro de chaves de 16 bits criaram as condições para manipular ponteiros de memória.

O ataque se concretizou quando um usuário autenticado, com acesso de 'push', enviou um Jupyter notebook manipulado para o repositório e visualizou seu 'diff' renderizado. Esse processo ativou a cadeia de falhas, comprometendo o processo do worker Puma. A exploração conseguiu contornar o ASLR (Address Space Layout Randomization) e executar comandos como o usuário 'git', utilizando 'gadgets' de 'libruby/libc' para invocar a função 'system()'. Isso demonstra que, apesar de Ruby ser uma linguagem geralmente considerada 'memory-safe', extensões em C, como o Oj, reintroduzem riscos de corrupção de memória, pois lidam diretamente com ponteiros e alocação manual.

O que mudou

Em 26 de junho de 2026, o CEVIU News noticiou a correção de múltiplas vulnerabilidades pelo GitLab, incluindo falhas de alta gravidade. A notícia de hoje aprofunda este cenário ao detalhar a vulnerabilidade mais crítica, que permite a execução remota de código via corrupção de memória em Ruby, presente em instâncias do GitLab por quase quatro anos. Enquanto a cobertura anterior informou sobre o lançamento dos patches de segurança, esta reportagem do CEVIU News explora os detalhes técnicos da exploração, a mecânica da cadeia de bugs e o impacto específico do parser Oj JSON. Mostramos o 'como' por trás do 'o quê' já divulgado.

Por que isso importa

Esta RCE no GitLab é um alerta crucial para a segurança da cadeia de suprimentos de software. A dependência em bibliotecas de terceiros, mesmo que amplamente testadas, pode introduzir vulnerabilidades profundas. A falha no parser Oj, que permaneceu por quase cinco anos antes de ser descoberta, sublinha a dificuldade de detectar problemas em componentes de baixo nível escritos em C, mesmo em linguagens como Ruby, consideradas seguras. Para as empresas que utilizam instâncias auto-gerenciadas do GitLab, a atualização imediata é vital, pois a RCE permite que um atacante obtenha controle total sobre o servidor, expondo dados sensíveis e a integridade do código-fonte.

Linha do tempo

  1. Código vulnerável do parser Oj 3.13.0 é incluído no projeto Oj.

  2. GitLab 15.2.0 torna o caminho vulnerável acessível em instâncias auto-gerenciadas.

  3. Correções para as vulnerabilidades são mescladas upstream no projeto Oj.

  4. Oj 3.17.3, contendo as correções, é publicado.

  5. Pesquisadores da DepthFirst relatam as falhas ao GitLab.

  6. GitLab lança atualizações de segurança contendo as correções para as vulnerabilidades.

  7. CEVIU News publica sobre correção de vulnerabilidades gerais no GitLab.

  8. CEVIU News aprofunda sobre a RCE via corrupção de memória no GitLab.

Perguntas frequentes

O que significa 'corrupção de memória' no contexto desta falha?

Corrupção de memória ocorre quando um programa escreve ou lê dados em uma área da memória que não deveria. Neste caso, o parser Oj JSON, por ser implementado em C, permitia que dados controlados pelo atacante sobrescrevessem estruturas de dados internas, como ponteiros, desviando o fluxo de execução para código malicioso.

Como um Jupyter notebook contribuiu para a exploração da vulnerabilidade?

Jupyter notebooks são arquivos JSON. Ao comitar um notebook manipulado e visualizar seu 'diff' renderizado no GitLab, o processo forçava o parser Oj a processar um JSON especialmente elaborado. Este JSON malicioso ativava os bugs de corrupção de memória, desencadeando a cadeia de exploração.

Qual o risco para instâncias auto-gerenciadas do GitLab?

Instâncias auto-gerenciadas correm o maior risco, especialmente aquelas que não foram atualizadas para a versão corrigida do Oj 3.17.3 ou para as versões mais recentes do GitLab. A falta de 'backports' para versões mais antigas do GitLab (15.2 a 18.9) significa que administradores devem atualizar para trilhas de patch mantidas ou realizar a atualização do Oj manualmente, se aplicável, para mitigar a RCE.

Por que a 'memória-segurança' do Ruby não impediu esta falha?

Embora Ruby seja 'memory-safe' em seu código nativo, ele permite a integração de extensões escritas em C para performance. O parser Oj é uma dessas extensões. Essas porções de código em C não herdam a segurança de memória do Ruby e podem introduzir vulnerabilidades como as de corrupção de memória, que são então exploradas através da interface Ruby.

Fontes

Avalie este artigo:
Compartilhar:
Categoria
CEVIU Segurança da Informação
Publicado
27 de julho de 2026
Editoria
CEVIU Segurança da Informação

Quer receber mais sobre CEVIU Segurança da Informação?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser