Structure du dépôt

Tout ce qui se trouve sous src/ est du texte source amont verbatim, jamais réimplémenté — le chargeur superpose src/vuln ou src/patched sur src/common.

1. Cause racine

1a. Champ de repli → résolution de méthode par défaut de graphql-ruby

Gitlab::Graphql::VersionFilter::FutureFieldFallback permet à une requête de référencer un champ qui n'existe pas encore sur un type sans que la requête échoue — conçu pour les déploiements progressifs, où le schéma d'un ancien nœud ne possède pas encore un champ qu'un nœud plus récent fournit déjà. Son override get_field vérifie si le champ demandé est manquant et si la requête est marquée contain_future_fields ; si c'est le cas, il renvoie un champ synthétique au lieu de lever une exception :

Le problème : ce GraphQL::Schema::Field est construit sans méthode de résolution, sans classe de résolution, sans bloc. La résolution de champ par défaut de graphql-ruby s'applique alors (graphql gem 2.6.3, lib/graphql/schema/field.rb) :

@method_sym est le nom du champ, en snake_case — c'est-à-dire exactement la chaîne que l'attaquant a placée dans la requête. Si l'objet derrière le type GraphQL (le modèle ActiveRecord) possède par hasard une méthode publique réelle sans argument portant ce nom, graphql-ruby l'appelle et renvoie son résultat (converti au type attendu). fallback_value: nil ne s'applique que lorsque la méthode n'existe vraiment pas — il ne fait rien pour empêcher une méthode réelle de s'exécuter.

Donc : interrogez n'importe quel type pour un champ nommé d'après une méthode destructive réelle — destroy, par exemple — taguez-le @gl_introduced pour qu'il survive jusqu'à l'exécution, et la méthode s'exécute.

1b. Échange de document entre opérations

IntroducedTracer implémente le reste de la fonctionnalité de filtre de versions à travers deux hooks de trace graphql-ruby — parse (une fois par opération) et execute_query (une fois par opération). Dans la version vulnérable, il stocke son état par opération dans de simples variables d'instance sur l'objet de trace :

Le problème : graphql-ruby partage UNE seule instance de trace pour chaque opération d'une requête multiplexée, et les analyse toutes avant d'en exécuter une seule. Donc dans un lot de deux opérations :

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 porte un champ futur @gl_introduced)

Après l'analyse, seul l'état de la dernière opération survit. Puis l'exécution se déroule :

3. execute_query(op1) → le drapeau est true, donc le document d'op1 est écrasé avec op2_doc et ré-analysé → le slot d'op1 exécute l'opération d'op2.

op1 déclarait une lecture ; il exécute l'écriture d'op2.

Le correctif

patch-19.2.2-to-19.2.4.diff corrige les deux :

2. Déroulement de l'exploitation

2a. Champ de repli — requête unique, sans authentification, sans lot

Pas d'en-tête Authorization. Une seule opération, pas de lot. destroy n'est pas un vrai champ sur Project — il n'existe pas du tout dans le schéma — mais la directive fait que FutureFieldFilter le retire avant la validation statique et arme contain_future_fields pour l'exécution, où get_field renvoie un champ sans résolveur nommé destroy et graphql-ruby appelle project.public_send(:destroy).

Vérifié en conditions réelles (evidence/live_vuln_fallback_field.txt, reproduit trois fois contre trois projets jetables distincts) : envoyée contre un projet public, la réponse était {"data":{"project":{"id":"...","destroy":true}}}. Un contrôle REST authentifié de suivi (GET /api/v4/projects/:id) a renvoyé 404 — le projet avait réellement disparu. Le journal des requêtes pour cet appel montre 9 écritures de base de données synchrones et zéro nouvelle ligne AuditEvent : l'appel contourne entièrement Projects::DestroyService (et avec lui la piste d'audit, les webhooks et les notifications) — c'est une cascade ActiveRecord#destroy brute invoquée directement via la résolution de champ par défaut de GraphQL.

2b. Échange de document entre opérations — nécessite un lot

Charge utile op2 — la directive @gl_introduced n'a qu'à se trouver sur un champ réel pour qu'au moment de l'analyse, FutureFieldFilter bascule contain_future_fields et arme l'échange :

Vérifié en conditions réelles (evidence/live_vuln.txt) : le slot 1, qui déclarait query { currentUser { username } }, renvoie {"data":{"starProject":{"count":"0"}}} et le compteur d'étoiles du projet passe de 1 → 0.

3. Exécution des PoC

PoC #1 — exploitation HTTP en conditions réelles, exécution de méthode par champ de repli

Le script crée un projet public jetable via l'API REST authentifiée (uniquement pour la configuration), envoie une seule requête GraphQL non authentifiée nommant un champ destroy tagué @gl_introduced, puis revérifie le projet via REST authentifié. Il déclare VULNERABLE si le projet a disparu.

PoC #2 — exploitation HTTP en conditions réelles, échange de document entre opérations

Le script lit l'état de base des étoiles, envoie le lot de deux opérations et déclare VULNERABLE si le slot 1 déclaré comme lecture renvoie une charge utile starProject (et/ou si le compteur d'étoiles change).

PoC #3 — cause racine autonome, échange de document (sans GitLab)

Isole Gitlab::Graphql::VersionFilter dans une petite application graphql-ruby afin que l'échange soit visible sans aucun bruit GitLab. Charge la vraie source amont.

4. Impact

Les deux vecteurs sont confirmés en conditions réelles contre gitlab/gitlab-ce:19.2.2-ce.0. Ils présentent des expositions d'autorisation différentes car ils frappent différentes couches de la pile GitLab.

Champ de repli (1a) : non authentifié confirmé, destructif

Aucun jeton, pas de lot, une seule requête. La réponse renvoie directement le résultat de la méthode ("destroy": true), et l'enregistrement sous-jacent est réellement détruit — confirmé via REST authentifié (404) et via des preuves côté serveur (zéro ligne AuditEvent, 9 écritures synchrones en une seule requête), ce qui signifie que cela contourne entièrement le service de suppression normal de GitLab. Reproduit trois fois indépendamment, contre trois projets jetables distincts. Tout type GraphQL dont l'objet sous-jacent expose une méthode destructive réelle sans argument est un candidat.

Échange entre opérations (1b) : authentifié confirmé ; bloqué quand anonyme

Avec n'importe quel jeton possédant le scope api, une opération qui déclarait une lecture exécute une écriture qu'elle n'a jamais demandée (compteur d'étoiles 1 → 0, piloté par un slot de type query). Envoyé sans jeton, l'échange se déclenche quand même — le slot de lecture atteint et résout bien starProject — mais chaque mutation GitLab hérite de Mutations::BaseMutation, dont la barrière self.authorized? s'exécute au moment de l'exécution :

Pour une requête anonyme, current_user est nil, et GlobalPolicy fait rule { anonymous }.policy { prevent :execute_graphql_mutation }. Un balayage de 10 agencements de lots (ordre, directive sur champ / sous-champ / fragment en ligne, lots de 2 et 3 opérations) sans authentification : le slot détourné heurte la barrière à chaque fois et le compteur d'étoiles ne bouge jamais.

Cette barrière est spécifique aux mutations — elle n'a aucune incidence sur 1a, qui ne touche jamais Mutations::BaseMutation ; le champ de repli se résout directement contre le modèle comme un simple champ de type query, sans aucun contrôle d'autorisation dans le chemin.

Pourquoi le PoC autonome (#3) semble non authentifié pour 1b

src/common/demo_app.rb n'a aucune couche d'autorisation — sa mutation écrit simplement. Donc le PoC #3 démontre le mécanisme d'échange (un slot de lecture effectuant une écriture) dans un bac à sable sans authentification. Le vrai GitLab applique la barrière execute_graphql_mutation que la démo omet — spécifiquement pour 1b. Sur ce build standard, une écriture pilotée par mutation sans identifiants n'est pas atteignable via 1b seul ; elle est atteignable via 1a, qui n'a besoin d'aucune mutation.

5. Atténuation

Mettez à jour vers 18.11.11 / 19.0.8 / 19.1.6 / 19.2.4 ou ultérieur. Le correctif (voir le diff) fait deux choses : future_field_fallback.rb donne au champ de repli un résolveur explicite (Resolvers::NilResolver, qui renvoie toujours nil) au lieu de s'appuyer sur la résolution de méthode par défaut de graphql-ruby, fermant 1a ; introduced_tracer.rb limite l'état par opération du traceur au document de chaque opération au lieu d'une variable d'instance partagée, fermant 1b.