Критична вразливість GitLab: RCE через Jupyter Notebooks

Дослідники безпеки з depthfirst 24 липня опублікували робочий код експлойту (PoC) для вразливості GitLab, яку GitLab виправив шість тижнів тому, 10 червня.

Суть Вразливості

Ця вразливість дозволяє будь-якому автентифікованому користувачеві, який може робити push до проєкту, виконувати команди як користувач git на будь-якому self-managed сервері версії 18.11.3, який не був оновлений. Для експлуатації не потрібні права адміністратора, доступ до CI/runner, взаємодія з жертвою або доступ до чужих проєктів.

Механізм Експлуатації

Атака починається з того, що зловмисник комітить спеціально створений Jupyter Notebook і відкриває його diff. Це призводить до витоку вказівника на купу (heap pointer). Достатня кількість таких витоків дозволяє автоматизованому зонду визначити розташування бібліотек у пам'яті. Після цього два додаткові ноутбуки запускають корисне навантаження.

Технічно, вразливість полягає у двох помилках пошкодження пам'яті в Oj – Ruby JSON парсері, значною мірою реалізованому на C. Система depthfirst автономно виявила ці помилки, а дослідники вручну об'єднали їх у ланцюг. Рендерер ноутбуків GitLab, вбудований гем ipynbdiff, передає контрольований репозиторієм JSON файлів .ipynb до Oj::Parser.usual.parse всередині довгоживучого процесу Puma worker. Це дозволяє контрольованим зловмисником байтам досягти керованої вручну пам'яті C в Oj всередині процесу програми. Одна помилка записує дані за межі фіксованого 1024-байтового стеку вкладеності, доки не отримає контроль над callback-функцією парсера. Інша помилка обрізає 65565-байтовий ключ об'єкта до 29 байтів у 16-бітному полі зі знаком і повертає дійсний вказівник на купу, який GitLab рендерить у diff. Витік дозволяє знайти libc, а запис направляє callback-функцію на system().

Реакція GitLab та Класифікація

GitLab не класифікував виправлення цієї вразливості як безпекове. Огляд The Hacker News показав, що оновлення Oj до версії 3.17.3 було зазначено в патчі від 10 червня як виправлення помилок, а не в таблиці безпекових виправлень. Немає CVE, CVSS-оцінки та згадки про ланцюжок notebook-diff. Оператори, які перевіряли цей реліз за таблицею безпеки, не мали підстав вважати його терміновим.

Зачеплені Версії та Рекомендації

Зачеплені всі рівні GitLab (CE та EE, від Free до Ultimate). Ruby не зачеплений. Вразливість стосується таких версій GitLab CE/EE:

15.2.0 до 18.10.7 (виправлено у 18.10.8)
18.11.0 до 18.11.4 (виправлено у 18.11.5)
19.0.0 до 19.0.1 (виправлено у 19.0.2)

Також зачеплені версії Oj gem 3.13.0 до 3.17.1 (виправлено у 3.17.3).

Рекомендується оновитися до версій 18.10.8, 18.11.5 або 19.0.2. Для інсталяцій, що використовують Helm або Operator, важливо перевіряти версію GitLab всередині образу Webservice, що запускає Puma, а не версію chart або Operator. Версії від 15.2 до 18.9 не отримають backport-виправлень, оскільки вони знаходяться поза межами підтримуваних GitLab ліній безпекових патчів, тому ці інсталяції повинні перейти на підтримуваний реліз.

Потенційний Вплив Експлойту

Команди виконуються від імені облікового запису git, який стоїть за Puma. Це може надати доступ до вихідного коду, секретів Rails, облікових даних сервісів, даних CI/CD та внутрішніх сервісів, з якими може взаємодіяти програма.

Опублікований експлойт створений для GitLab 18.11.3 на x86-64. Він не є універсальним для довільних цілей через залежність від зміщень гаджетів, стану регістрів та поведінки jemalloc. Відновлена база бібліотек зберігається лише до перезапуску майстер-процесу Puma. Хоча помилки Oj є загальними, перенесення експлойту на інші системи вимагає значних зусиль. depthfirst виміряв час пошуку пам'яті: від п'яти до десяти хвилин на свіжій інсталяції з двома worker-процесами та від однієї до двох годин на довших інсталяціях.

Хронологія Подій

21 травня: depthfirst повідомив про помилки Oj.
27 травня: розробник Oj об'єднав виправлення.
4 червня: Oj 3.17.3 випущено.
5 червня: ланцюжок вразливості GitLab передано GitLab.
8 червня: GitLab підтвердив вразливість.
10 червня: GitLab випустив патч.
24 липня: depthfirst опублікував PoC.

Що це означає для розробників

Розробникам, які використовують self-managed інсталяції GitLab, необхідно терміново оновити свої системи до версій 18.10.8, 18.11.5 або 19.0.2, щоб уникнути RCE. Важливо перевіряти версію GitLab всередині образу Webservice (Puma), особливо при використанні Helm або Operator. Інсталяції на версіях 15.2-18.9 не отримають backport-виправлень і потребують переходу на підтримуваний реліз.

Ключові факти

Дослідники depthfirst опублікували робочий експлойт (PoC) для вразливості GitLab 24 липня.
GitLab виправив вразливість 10 червня, але не класифікував її як безпекову, не присвоївши CVE.
Вразливість дозволяє автентифікованим користувачам виконувати команди як git на не оновлених self-managed серверах.
Експлойт використовує спеціально створені Jupyter Notebooks та дві помилки пошкодження пам'яті в Ruby JSON парсері Oj.
Зачеплені версії GitLab CE/EE 15.2.0-18.10.7, 18.11.0-18.11.4, 19.0.0-19.0.1 та Oj gem 3.13.0-3.17.1.