Repository-Struktur

Alles unter src/ ist wörtlicher Upstream-Quellcode, nie neu implementiert — der Loader legt src/vuln oder src/patched über src/common.

1. Grundursache

1a. Fallback-Feld → Standard-Methodenauflösung von graphql-ruby

Gitlab::Graphql::VersionFilter::FutureFieldFallback ermöglicht es einer Abfrage, ein Feld zu referenzieren, das in einem Typ noch nicht existiert, ohne dass die Anfrage fehlschlägt — gedacht für rollierende Deployments, bei denen das Schema eines alten Knotens ein Feld noch nicht hat, das ein neuerer Knoten bereits ausliefert. Sein get_field-Override prüft, ob das angeforderte Feld fehlt und die Anfrage mit contain_future_fields markiert ist, und liefert in diesem Fall ein synthetisches Feld zurück, anstatt eine Ausnahme auszulösen:

Das Problem: Dieses GraphQL::Schema::Field wird ohne Resolver-Methode, ohne Resolver-Klasse und ohne Block erstellt. Dann greift die eigene Standard-Feldauflösung von graphql-ruby (graphql-Gem 2.6.3, lib/graphql/schema/field.rb):

@method_sym ist der Name des Feldes, unterstrichen — also genau die Zeichenkette, die der Angreifer in die Abfrage gesetzt hat. Wenn das Objekt hinter dem GraphQL-Typ (das ActiveRecord-Modell) zufällig eine echte öffentliche Methode ohne Argumente mit diesem Namen besitzt, ruft graphql-ruby sie auf und gibt ihr (typkonvertiertes) Ergebnis zurück. fallback_value: nil greift nur, wenn die Methode wirklich nicht existiert — es verhindert nicht, dass eine echte Methode ausgeführt wird.

Also: Fragt man einen beliebigen Typ nach einem Feld ab, das nach einer echten destruktiven Methode benannt ist — zum Beispiel destroy — und markiert es mit @gl_introduced, damit es bis zur Ausführung überlebt, wird die Methode ausgeführt.

1b. Dokumenttausch zwischen Operationen

IntroducedTracer implementiert den Rest der Version-Filter-Funktion über zwei graphql-ruby-Trace-Hooks — parse (einmal pro Operation) und execute_query (einmal pro Operation). Im verwundbaren Build verstaut es seinen Zustand pro Operation in einfachen Instanzvariablen auf dem Trace-Objekt:

Das Problem: graphql-ruby teilt EINE Trace-Instanz über alle Operationen einer Multiplex-Anfrage und parst sie alle, bevor eine davon ausgeführt wird. In einem Batch mit zwei Operationen gilt also:

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 trägt ein @gl_introduced-Zukunftsfeld)

Nach dem Parsen überlebt nur der Zustand der letzten Operation. Dann läuft die Ausführung:

3. execute_query(op1) → Flag ist true, also wird op1s Dokument mit op2_doc überschrieben und neu vorbereitet → op1s Slot führt op2s Operation aus.

op1 hat eine Leseoperation deklariert; es führt den Schreibvorgang von op2 aus.

Der Fix

patch-19.2.2-to-19.2.4.diff behebt beides:

2. Exploit-Ablauf

2a. Fallback-Feld — einzelne Anfrage, ohne Authentifizierung, ohne Batching

Kein Authorization-Header. Eine Operation, kein Batch. destroy ist kein echtes Feld auf Project — es existiert im Schema überhaupt nicht — aber die Direktive veranlasst FutureFieldFilter, es vor der statischen Validierung zu entfernen, und aktiviert contain_future_fields für die Ausführung. Dort gibt get_field ein resolverloses Feld namens destroy zurück, und graphql-ruby ruft project.public_send(:destroy) auf.

Live verifiziert (evidence/live_vuln_fallback_field.txt, dreimal gegen drei separate Wegwerfprojekte reproduziert): Gegen ein öffentliches Projekt gesendet, war die Antwort {"data":{"project":{"id":"...","destroy":true}}}. Eine anschließende authentifizierte REST-Prüfung (GET /api/v4/projects/:id) gab 404 zurück — das Projekt war tatsächlich weg. Das Anfrageprotokoll für diesen Aufruf zeigt 9 synchrone Datenbankschreibvorgänge und null neue AuditEvent-Zeilen: Der Aufruf umgeht Projects::DestroyService vollständig (und damit den Prüfpfad, Webhooks und Benachrichtigungen) — es ist eine rohe ActiveRecord#destroy-Kaskade, die direkt über die Standard-Feldauflösung von GraphQL aufgerufen wird.

2b. Dokumenttausch zwischen Operationen — benötigt einen Batch

Op2-Nutzlast — die @gl_introduced-Direktive muss nur auf einem echten Feld sitzen, damit FutureFieldFilter zum Parse-Zeitpunkt contain_future_fields umschaltet und den Tausch aktiviert:

Live verifiziert (evidence/live_vuln.txt): Slot 1, der query { currentUser { username } } deklariert hatte, gibt {"data":{"starProject":{"count":"0"}}} zurück, und die Stern-Anzahl des Projekts wechselt von 1 → 0.

3. Ausführen der PoCs

PoC #1 — Live-HTTP-Exploit, Ausführung von Fallback-Feld-Methoden

Das Skript erstellt über die authentifizierte REST-API ein Wegwerfprojekt (nur Einrichtung), sendet eine nicht authentifizierte GraphQL-Abfrage, die ein mit @gl_introduced markiertes destroy-Feld benennt, und prüft das Projekt anschließend erneut über authentifiziertes REST. Es meldet VULNERABLE, wenn das Projekt weg ist.

PoC #2 — Live-HTTP-Exploit, Dokumenttausch zwischen Operationen

Das Skript liest den Ausgangszustand der Sterne, sendet den Batch mit zwei Operationen und meldet VULNERABLE, wenn der als Leseoperation deklarierte Slot 1 eine starProject-Nutzlast zurückgibt (und/oder sich die Stern-Anzahl ändert).

PoC #3 — Eigenständige Grundursache, Dokumenttausch (kein GitLab erforderlich)

Isoliert Gitlab::Graphql::VersionFilter in einer winzigen graphql-ruby-App, sodass der Tausch ohne GitLab-Rauschen sichtbar ist. Lädt den echten Upstream-Quellcode.

4. Auswirkungen

Beide Vektoren wurden live gegen gitlab/gitlab-ce:19.2.2-ce.0 bestätigt. Sie haben unterschiedliche Autorisierungs-Exposition, da sie verschiedene Ebenen des GitLab-Stacks treffen.

Fallback-Feld (1a): bestätigt nicht authentifiziert, destruktiv

Kein Token, kein Batching, eine Abfrage. Die Antwort gibt das Ergebnis der Methode direkt zurück ("destroy": true), und der zugrunde liegende Datensatz wird tatsächlich gelöscht — bestätigt über authentifiziertes REST (404) und über serverseitige Beweise (null AuditEvent-Zeilen, 9 synchrone Schreibvorgänge in einer Anfrage), was bedeutet, dass der normale Löschdienst von GitLab vollständig umgangen wird. Dreimal unabhängig gegen drei separate Wegwerfprojekte reproduziert. Jeder GraphQL-Typ, dessen zugrunde liegendes Objekt eine echte destruktive Methode ohne Argumente bereitstellt, ist ein Kandidat.

Operationstausch (1b): bestätigt authentifiziert; bei anonymem Zugriff gesperrt

Mit einem beliebigen Token mit api-Bereich führt eine Operation, die eine Leseoperation deklariert hat, einen Schreibvorgang aus, den sie nie angefordert hat (Stern-Anzahl 1 → 0, angetrieben durch einen query-typisierten Slot). Ohne Token ausgelöst, greift der Tausch weiterhin — der Lese-Slot erreicht und löst starProject tatsächlich auf — aber jede GitLab-Mutation erbt von Mutations::BaseMutation, dessen self.authorized?-Gate zur Ausführungszeit läuft:

Bei einer anonymen Anfrage ist current_user gleich nil, und GlobalPolicy führt rule { anonymous }.policy { prevent :execute_graphql_mutation } aus. Ein Durchlauf mit 10 Batch-Anordnungen (Reihenfolge, Direktive auf Feld / Unterfeld / Inline-Fragment, Batches mit 2 und 3 Operationen) ohne Authentifizierung: Der gekaperte Slot läuft jedes Mal in das Gate, und die Stern-Anzahl bewegt sich nie.

Dieses Gate ist spezifisch für Mutationen — es hat keine Auswirkung auf 1a, das Mutations::BaseMutation überhaupt nicht berührt; das Fallback-Feld wird direkt gegen das Modell als einfaches Feld vom Typ query aufgelöst, ohne jegliche Autorisierungsprüfung im Pfad.

Warum der eigenständige PoC (#3) für 1b wie nicht authentifiziert aussieht

src/common/demo_app.rb hat überhaupt keine Autorisierungsschicht — seine Mutation schreibt einfach. PoC #3 demonstriert also den Tausch-Mechanismus (ein Lese-Slot führt einen Schreibvorgang aus) in einer Sandbox ohne Authentifizierung. Echtes GitLab erzwingt das execute_graphql_mutation-Gate, das die Demo weglässt — speziell für 1b. Bei diesem Standard-Build ist ein durch eine Mutation ausgelöster Schreibvorgang ohne Anmeldedaten nicht allein über 1b erreichbar; er ist über 1a erreichbar, das überhaupt keine Mutation benötigt.

5. Gegenmaßnahmen

Aktualisieren Sie auf 18.11.11 / 19.0.8 / 19.1.6 / 19.2.4 oder neuer. Der Fix (siehe Diff) bewirkt zwei Dinge: future_field_fallback.rb gibt dem Fallback-Feld einen expliziten Resolver (Resolvers::NilResolver, der immer nil zurückgibt), anstatt sich auf den Standard-Methodendispatch von graphql-ruby zu verlassen, was 1a behebt; introduced_tracer.rb begrenzt den Zustand des Tracers pro Operation auf das eigene Dokument der jeweiligen Operation anstelle einer gemeinsamen Instanzvariable, was 1b behebt.