Estrutura do repositório

Tudo sob src/ é código-fonte upstream verbatim, nunca reimplementado — o loader sobrepõe src/vuln ou src/patched sobre src/common.

1. Causa raiz

1a. Campo fallback → resolução de método padrão do graphql-ruby

Gitlab::Graphql::VersionFilter::FutureFieldFallback permite que uma consulta faça referência a um campo que ainda não existe em um tipo sem que a requisição falhe — pensado para implantações contínuas (rolling deploys), onde o schema de um nó antigo ainda não tem um campo que um nó mais novo já entrega. Sua sobrescrita de get_field verifica se o campo solicitado está ausente e se a requisição está sinalizada com contain_future_fields; se estiver, devolve um campo sintético em vez de lançar erro:

O problema: este GraphQL::Schema::Field é construído sem método resolver, sem classe resolver e sem bloco. Então a resolução de campo padrão do próprio graphql-ruby é aplicada (gem graphql 2.6.3, lib/graphql/schema/field.rb):

@method_sym é o nome do campo, em snake_case — ou seja, exatamente a string que o atacante colocou na consulta. Se o objeto por trás do tipo GraphQL (o modelo ActiveRecord) tiver um método público real, de zero argumentos, com esse nome, o graphql-ruby o chama e retorna seu resultado (coagido ao tipo). fallback_value: nil só se aplica quando o método realmente não existe — e não faz nada para impedir que um método real seja executado.

Então: basta consultar qualquer tipo por um campo com o nome de um método destrutivo real — por exemplo, destroy —, marcá-lo com @gl_introduced para que sobreviva até a execução, e o método será executado.

1b. Troca de documento entre operações

IntroducedTracer implementa o restante do recurso de filtro de versão em dois hooks de trace do graphql-ruby — parse (uma vez por operação) e execute_query (uma vez por operação). Na build vulnerável, ele guarda seu estado por operação em variáveis de instância simples no objeto de trace:

O problema: o graphql-ruby compartilha UMA única instância de trace entre todas as operações de uma requisição multiplexada e analisa todas elas antes de executar qualquer uma. Então, em um lote de duas operações:

1. parse(op1) → @original_query_document = op1_doc, @contain_future_fields = false
2. parse(op2) → @original_query_document = op2_doc, @contain_future_fields = true (op2 carrega um campo futuro @gl_introduced)

Após a análise, apenas o estado da última operação sobrevive. Então a execução roda:

3. execute_query(op1) → a flag é true, então o documento de op1 é sobrescrito com op2_doc e re-preparado → o slot de op1 executa a operação de op2.

op1 declarou uma leitura; ela executa a escrita de op2.

A correção

patch-19.2.2-to-19.2.4.diff corrige ambos:

2. Fluxo do exploit

2a. Campo fallback — requisição única, sem autenticação, sem lote

Nenhum cabeçalho Authorization. Uma operação, sem lote. destroy não é um campo real em Project — ele não existe no schema — mas a diretiva faz o FutureFieldFilter removê-lo antes da validação estática e arma contain_future_fields para a execução, onde get_field devolve um campo sem resolver chamado destroy e o graphql-ruby chama project.public_send(:destroy).

Verificado ao vivo (evidence/live_vuln_fallback_field.txt, reproduzido três vezes contra três projetos descartáveis separados): enviado contra um projeto público, a resposta foi {"data":{"project":{"id":"...","destroy":true}}}. Uma verificação REST autenticada de acompanhamento (GET /api/v4/projects/:id) retornou 404 — o projeto realmente tinha sido removido. O log da requisição dessa chamada mostra 9 gravações síncronas no banco e zero novas linhas de AuditEvent: a chamada ignora completamente o Projects::DestroyService (e com ele a trilha de auditoria, webhooks e notificações) — é uma cascata crua de ActiveRecord#destroy invocada diretamente por meio da resolução de campo padrão do GraphQL.

2b. Troca de documento entre operações — exige um lote

Payload da Op2 — a diretiva @gl_introduced só precisa estar em um campo real para que, no momento da análise, o FutureFieldFilter alterne contain_future_fields e arme a troca:

Verificado ao vivo (evidence/live_vuln.txt): o slot 1, que declarou query { currentUser { username } }, retorna {"data":{"starProject":{"count":"0"}}} e o contador de estrelas do projeto passa de 1 → 0.

3. Executando os PoCs

PoC #1 — exploit HTTP ao vivo, execução de método por campo fallback

O script cria um projeto público descartável por meio da API REST autenticada (apenas configuração), envia uma consulta GraphQL não autenticada nomeando um campo destroy marcado com @gl_introduced e depois verifica novamente o projeto via REST autenticado. Ele declara VULNERABLE se o projeto tiver sumido.

PoC #2 — exploit HTTP ao vivo, troca de documento entre operações

O script lê o estado inicial das estrelas, envia o lote de duas operações e declara VULNERABLE se o slot 1, que declarou leitura, retornar um payload de starProject (e/ou se o contador de estrelas mudar).

PoC #3 — causa raiz standalone, troca de documento (sem precisar de GitLab)

Isola Gitlab::Graphql::VersionFilter em um pequeno aplicativo graphql-ruby para que a troca fique visível sem nenhum ruído do GitLab. Carrega o código-fonte upstream real.

4. Impacto

Ambos os vetores foram confirmados ao vivo contra gitlab/gitlab-ce:19.2.2-ce.0. Eles têm diferentes superfícies de exposição de autorização porque atingem camadas diferentes da pilha do GitLab.

Campo fallback (1a): confirmado não autenticado e destrutivo

Sem token, sem lote, uma única consulta. A resposta retorna o resultado do método diretamente ("destroy": true), e o registro subjacente é de fato destruído — confirmado via REST autenticado (404) e por evidências no lado do servidor (zero linhas de AuditEvent, 9 gravações síncronas em uma única requisição), o que significa que ele ignora completamente o serviço normal de exclusão do GitLab. Reproduzido três vezes de forma independente, contra três projetos descartáveis separados. Qualquer tipo GraphQL cujo objeto subjacente exponha um método destrutivo real de zero argumentos é um candidato.

Troca entre operações (1b): confirmado autenticado; bloqueado quando anônimo

Com qualquer token que tenha escopo api, uma operação que declarou leitura executa uma escrita que nunca solicitou (contador de estrelas 1 → 0, dirigido por um slot tipado como query). Enviada sem token, a troca ainda dispara — o slot de leitura de fato alcança e resolve starProject — mas toda mutação do GitLab herda Mutations::BaseMutation, cujo portão self.authorized? é executado no momento da execução:

Para uma requisição anônima, current_user é nil, e GlobalPolicy faz rule { anonymous }.policy { prevent :execute_graphql_mutation }. Uma varredura de 10 arranjos de lote (ordem, diretiva em campo / subcampo / fragmento inline, lotes de 2 e 3 operações) sem autenticação: o slot sequestrado esbarra no portão todas as vezes e o contador de estrelas nunca muda.

Esse portão é específico de mutações — não tem efeito sobre 1a, que nunca toca Mutations::BaseMutation; o campo fallback resolve diretamente contra o modelo como um campo comum de tipo consulta, sem nenhuma verificação de autorização no caminho.

Por que o PoC standalone (#3) parece não autenticado para 1b

src/common/demo_app.rb não tem nenhuma camada de autorização — sua mutação apenas escreve. Portanto, o PoC #3 demonstra o mecanismo da troca (um slot de leitura executando uma escrita) em uma sandbox sem autenticação. O GitLab real aplica o portão execute_graphql_mutation que a demo omite — especificamente para 1b. Nesta build padrão, uma escrita orientada por mutação sem credenciais não é alcançável apenas via 1b; é alcançável via 1a, que não precisa de mutação alguma.

5. Mitigação

Atualize para 18.11.11 / 19.0.8 / 19.1.6 / 19.2.4 ou posterior. A correção (veja o diff) faz duas coisas: future_field_fallback.rb dá ao campo fallback um resolver explícito (Resolvers::NilResolver, que sempre retorna nil) em vez de depender do despacho de método padrão do graphql-ruby, fechando 1a; introduced_tracer.rb limita o estado por operação do tracer ao documento de cada operação em vez de uma variável de instância compartilhada, fechando 1b.