PoC-эксплойт для GitLab: авторизованный пользователь получает выполнение команд от имени git

Исследователь Yuhang Wu из depthfirst опубликовал рабочий proof-of-concept, позволяющий выполнять команды от имени пользователя git на непропатченном self-managed сервере GitLab 18.11.3. Для запуска цепочки достаточно обычного авторизованного пользователя: он коммитит два специально подготовленных Jupyter-ноутбука и запрашивает их diff. Ни прав администратора, ни доступа к CI-раннерам, ни участия жертвы, ни доступа к чужому проекту не требуется.

Где корень проблемы

Уязвимости кроются не в самом GitLab, а в Oj — высокопроизводительном JSON-парсере для Ruby с большим объёмом нативного C-кода. Рендерер ноутбуков передаёт содержимое .ipynb (то есть данные, контролируемые репозиторием) прямо в Oj::Parser.usual.parse внутри долгоживущего Puma-воркера. Так атакующие данные попадают в нативное состояние парсера внутри процесса приложения.

Один баг позволяет контролировать указатель на callback, второй — утечь адрес из кучи, необходимый, чтобы сузить перебор при обходе ASLR. Oj хранит состояние вложенности в фиксированном буфере на 1024 байта, но не проверяет переполнение: глубоко вложенные массивы позволяют портить соседнее состояние парсера. Два лексикографически упорядоченных файла в одном запросе diffs_stream удерживают обе стадии внутри одного воркера, который переиспользует глобальный парсер Oj. Первый файл портит указатель, второй разбор вызывает его — и через специфичную для сборки последовательность гаджетов достигает system().

На профилированной установке с двумя воркерами перебор обычно занимал от пяти до десяти минут; для более широкого диапазона исследователи оценили время в один-два часа.

Кого затрагивает

Под удар попадают GitLab CE и EE версий 15.2.0–18.10.7, 18.11.0–18.11.4 и 19.0.0–19.0.1, а также редакции Free, Premium и Ultimate. Первые исправленные релизы — 18.10.8, 18.11.5 и 19.0.2. Уязвимы гемы Oj с 3.13.0 по 3.17.1; первый релиз с обоими исправлениями — 3.17.3. Сам Ruby не затронут.

Успешная эксплуатация даёт выполнение от имени git, а реальный охват зависит от изоляции развёртывания: под угрозой могут оказаться исходный код, секреты Rails, учётные данные сервисов, данные CI/CD и внутренние сервисы, доступные из приложения. GitLab.com был исправлен ещё 10 июня. Self-managed операторам рекомендуют обновиться до поддерживаемой версии; пользователям Helm и Operator стоит проверять версию GitLab внутри образа Webservice, а не только версию чарта или оператора. Временного обходного пути ни depthfirst, ни GitLab не предлагают.

Любопытная деталь: ни в раскрытии depthfirst, ни в июньских release notes GitLab для двух багов цепочки не приведены ни идентификаторы CVE, ни оценки CVSS. Более того, GitLab перечислил обновление Oj до 3.17.3 в разделе исправления багов, а не в таблице security-fix, и не описал сам RCE-механизм через diff ноутбуков. По состоянию на 24 июля depthfirst не располагает сведениями об атаках в реальных условиях.

Источник: The Hacker News