Структура репозитория

Всё в src/ — дословный апстрим-исходный код, ничего не переписано: загрузчик накладывает src/vuln или src/patched поверх src/common.

1. Корневая причина

1a. Fallback-поле → разрешение методов по умолчанию в graphql-ruby

Gitlab::Graphql::VersionFilter::FutureFieldFallback позволяет запросу ссылаться на поле, которого ещё нет в типе, не вызывая ошибку запроса — это предназначено для rolling-деплоев, когда схема старого узла ещё не содержит поле, которое уже поставляет более новый узел. Его переопределение get_field проверяет, отсутствует ли запрошенное поле и помечен ли запрос флагом contain_future_fields, и если да, то вместо исключения возвращает синтетическое поле:

Проблема: этот GraphQL::Schema::Field создаётся без метода-резолвера, без класса-резолвера, без блока. Затем применяется стандартное разрешение полей самого graphql-ruby (gem graphql 2.6.3, lib/graphql/schema/field.rb):

@method_sym — это имя поля в snake_case, то есть ровно та строка, которую атакующий указал в запросе. Если объект за GraphQL-типом (модель ActiveRecord) случайно имеет реальный публичный метод без аргументов с таким именем, graphql-ruby вызывает его и возвращает его результат (приведённый к типу). fallback_value: nil применяется только когда метода действительно не существует — он никак не мешает выполнению реального метода.

Итак: запросите у любого типа поле, названное в честь реального деструктивного метода — например, destroy — пометьте его @gl_introduced, чтобы оно дошло до выполнения, и метод выполнится.

1b. Подмена документа между операциями

IntroducedTracer реализует остальную часть функции фильтра версий через два trace-хука graphql-ruby — parse (один раз на операцию) и execute_query (один раз на операцию). В уязвимой сборке он сохраняет состояние для каждой операции в обычных переменных экземпляра объекта trace:

Проблема: graphql-ruby использует ОДИН экземпляр trace для всех операций в multiplexed-запросе и разбирает их все до выполнения любой из них. Поэтому в пакете из двух операций:

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 несёт future-поле @gl_introduced)

После разбора сохраняется состояние только последней операции. Затем начинается выполнение:

3. execute_query(op1) → флаг равен true, поэтому документ op1 перезаписывается на op2_doc и заново подготавливается → слот op1 выполняет операцию op2.

op1 объявил чтение; он выполняет запись из op2.

Исправление

patch-19.2.2-to-19.2.4.diff закрывает обе:

2. Схема эксплуатации

2a. Fallback-поле — один запрос, без авторизации, без пакетирования

Без заголовка Authorization. Одна операция, без пакета. destroy — не настоящее поле Project; его вообще нет в схеме, — но директива заставляет FutureFieldFilter удалить его до статической валидации и взводит contain_future_fields для этапа выполнения, где get_field возвращает поле без резолвера с именем destroy, и graphql-ruby вызывает project.public_send(:destroy).

Подтверждено на живом экземпляре (evidence/live_vuln_fallback_field.txt, воспроизведено три раза на трёх отдельных одноразовых проектах): при отправке против публичного проекта ответ был {"data":{"project":{"id":"...","destroy":true}}}. Последующая аутентифицированная проверка через REST (GET /api/v4/projects/:id) вернула 404 — проект действительно исчез. Журнал запроса для этого вызова показывает 9 синхронных записей в БД и ноль новых строк AuditEvent: вызов полностью обходит Projects::DestroyService (а вместе с ним журнал аудита, вебхуки и уведомления) — это сырой каскад ActiveRecord#destroy, вызванный напрямую через стандартное разрешение полей GraphQL.

2b. Подмена документа между операциями — требуется пакет

Полезная нагрузка Op2 — директива @gl_introduced должна находиться только на реальном поле, чтобы на этапе разбора FutureFieldFilter переключил contain_future_fields и взвёл подмену:

Подтверждено на живом экземпляре (evidence/live_vuln.txt): слот 1, объявивший query { currentUser { username } }, возвращает {"data":{"starProject":{"count":"0"}}} и счётчик звёзд проекта меняется с 1 на 0.

3. Запуск PoC

PoC #1 — живой HTTP-эксплойт: выполнение метода через fallback-поле

Скрипт создаёт одноразовый публичный проект через аутентифицированный REST API (только для подготовки), отправляет один неаутентифицированный GraphQL-запрос с полем destroy, помеченным @gl_introduced, затем повторно проверяет проект через аутентифицированный REST. Он объявляет VULNERABLE, если проект исчез.

PoC #2 — живой HTTP-эксплойт, подмена документа между операциями

Скрипт считывает базовое состояние звёзд, отправляет пакет из двух операций и объявляет VULNERABLE, если слот 1, объявивший чтение, возвращает полезную нагрузку starProject (и/или счётчик звёзд меняется).

PoC #3 — автономная проверка корневой причины, подмена документа (без GitLab)

Изолирует Gitlab::Graphql::VersionFilter в крошечном приложении на graphql-ruby, чтобы подмена была видна без лишнего шума GitLab. Загружает настоящий апстрим-исходный код.

4. Влияние

Оба вектора подтверждены на живом экземпляре gitlab/gitlab-ce:19.2.2-ce.0. Они несут разную степень авторизационной экспозиции, поскольку затрагивают разные уровни стека GitLab.

Fallback-поле (1a): подтверждено, неаутентифицированно, деструктивно

Без токена, без пакетирования, один запрос. Ответ напрямую возвращает результат метода ("destroy": true), а сам объект реально уничтожается — подтверждено через аутентифицированный REST (404) и серверными свидетельствами (ноль строк AuditEvent, 9 синхронных записей за один запрос), то есть вызов полностью обходит обычный сервис удаления GitLab. Воспроизведено независимо три раза на трёх отдельных одноразовых проектах. Любой GraphQL-тип, чей базовый объект предоставляет реальный публичный деструктивный метод без аргументов, — кандидат.

Подмена документа между операциями (1b): подтверждено при аутентификации; для анонимов — ограничено

С любым токеном, имеющим область api, операция, которая объявила чтение, выполняет запись, которую она не запрашивала (счётчик звёзд 1 → 0, инициируется слотом с типом query). При отправке без токена подмена всё равно срабатывает — слот чтения действительно доходит до starProject и резолвит его, — но каждая мутация GitLab наследует Mutations::BaseMutation, чей шлюз self.authorized? выполняется на этапе выполнения:

Для анонимного запроса current_user равен nil, и GlobalPolicy выполняет rule { anonymous }.policy { prevent :execute_graphql_mutation }. При неаутентифицированном переборе 10 вариантов пакетов (порядок, директива на поле / подполе / инлайн-фрагмент, пакеты из 2 и 3 операций): перехваченный слот каждый раз упирается в шлюз, и счётчик звёзд не меняется.

Этот шлюз относится только к мутациям — он не влияет на 1a, которая вообще не касается Mutations::BaseMutation; fallback-поле резолвится напрямую против модели как обычное поле типа query, и в этом пути вообще нет проверки авторизации.

Почему автономный PoC (#3) выглядит неаутентифицированным для 1b

src/common/demo_app.rb вообще не имеет слоя авторизации — его мутация просто пишет. Поэтому PoC #3 демонстрирует механизм подмены (слот чтения выполняет запись) в песочнице без авторизации. Настоящий GitLab применяет шлюз execute_graphql_mutation, который демо-приложение опускает — в частности для 1b. На этой стандартной сборке запись, инициированная мутацией без учётных данных, недостижима через одну лишь 1b; она достижима через 1a, которой мутация вообще не нужна.

5. Устранение

Обновитесь до 18.11.11 / 19.0.8 / 19.1.6 / 19.2.4 или новее. Исправление (см. diff) делает две вещи: future_field_fallback.rb даёт fallback-полю явный резолвер (Resolvers::NilResolver, который всегда возвращает nil) вместо того, чтобы полагаться на стандартную диспетчеризацию методов graphql-ruby, закрывая 1a; introduced_tracer.rb ограничивает состояние трейсера для каждой операции её собственным документом вместо общей переменной экземпляра, закрывая 1b.