- 28,589
- 46
- 8 Ноя 2022
GitLab полтора месяца скрывал дыру в безопасности под видом рядового апдейта.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1024/572;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Критическая уязвимость GitLab почти полтора месяца скрывалась на виду. Компания закрыла возможность удалённого выполнения кода ещё 10 июня, но указала исправление лишь как рядовое обновление зависимости. Теперь исследователи depthfirst опубликовали рабочий эксплойт, который позволяет обычному пользователю захватить сервер через специально подготовленный файл Jupyter Notebook.
Для атаки не нужны права администратора, доступ к GitLab Runner или помощь другого пользователя. Достаточно войти в учётную запись с правом записи хотя бы в один проект, загрузить вредоносный файл формата .ipynb и открыть страницу с изменениями. Уязвимость затрагивает собственные серверы GitLab, на которых установлены версии с небезопасной библиотекой Oj.
Oj представляет собой быстрый JSON-парсер для Ruby, значительная часть которого написана на языке C. Исследователи обнаружили в библиотеке две ошибки управления памятью. Одна позволяла выйти за границы выделенного буфера, другая раскрывала адрес в памяти и помогала обойти защиту ASLR. Вместе уязвимости давали атакующему возможность выполнить произвольную команду от имени системного пользователя git.
GitLab использовал Oj при отображении различий между версиями Jupyter Notebook. Сервер передавал содержимое загруженного файла непосредственно нативному парсеру внутри рабочего процесса Puma. Специально сформированные данные нарушали структуру памяти и перенаправляли выполнение программы на выбранную злоумышленником команду.
Полученный доступ может оказаться значительно опаснее обычного взлома одного проекта. Пользователь git способен читать исходный код, секреты Rails, данные CI/CD, учётные данные, материалы для подписи токенов и обращаться к внутренним сервисам, доступным серверу GitLab. Масштаб последствий зависит от конфигурации конкретной установки и прав системного пользователя.
Проблема затрагивает GitLab Community Edition и Enterprise Edition всех тарифов. Уязвимы версии с 15.2.0 по 18.10.7, с 18.11.0 по 18.11.4, а также 19.0.0 и 19.0.1. Исправления впервые появились в выпусках 18.10.8, 18.11.5 и 19.0.2, которые включают безопасную версию Oj 3.17.3. Облачный сервис GitLab.com обновили к моменту выхода патча, поэтому действия требуются прежде всего владельцам самостоятельно развёрнутых серверов.
Главная претензия исследователей связана не со скоростью исправления, а с тем, как GitLab сообщил о риске администраторам. В релизных заметках от 10 июня обновление Oj до версии 3.17.3 попало в раздел обычных исправлений. GitLab не присвоил цепочке отдельный идентификатор CVE, не указал оценку CVSS и не предупредил, что обновление закрывает удалённое выполнение кода. При этом в том же бюллетене компания подробно перечислила другие уязвимости в отдельной таблице безопасности.
Администраторы, которые изучали только раздел с исправлениями безопасности, могли не увидеть причин срочно устанавливать обновление зависимости. Публичный эксплойт появился 24 июля, спустя шесть недель после выпуска патча, и заметно повысил риск атак на серверы, которые до сих пор работают на старых версиях.
depthfirst сообщила об ошибках разработчику Oj 21 мая. Исправления вошли в код 27 мая, а Oj 3.17.3 вышел 4 июня. Исследователи передали GitLab готовую цепочку атаки 5 июня, компания подтвердила проблему через три дня и выпустила обновления 10 июня. Сведений о реальных атаках пока нет, однако после публикации PoC рассчитывать на длительное отсутствие эксплуатации уже не стоит.
Владельцам собственных серверов GitLab рекомендуется установить актуальную поддерживаемую версию. Отдельного способа заблокировать атаку без обновления GitLab или Oj исследователи не предложили.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1024/572;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Критическая уязвимость GitLab почти полтора месяца скрывалась на виду. Компания закрыла возможность удалённого выполнения кода ещё 10 июня, но указала исправление лишь как рядовое обновление зависимости. Теперь исследователи depthfirst опубликовали рабочий эксплойт, который позволяет обычному пользователю захватить сервер через специально подготовленный файл Jupyter Notebook.
Для атаки не нужны права администратора, доступ к GitLab Runner или помощь другого пользователя. Достаточно войти в учётную запись с правом записи хотя бы в один проект, загрузить вредоносный файл формата .ipynb и открыть страницу с изменениями. Уязвимость затрагивает собственные серверы GitLab, на которых установлены версии с небезопасной библиотекой Oj.
Oj представляет собой быстрый JSON-парсер для Ruby, значительная часть которого написана на языке C. Исследователи обнаружили в библиотеке две ошибки управления памятью. Одна позволяла выйти за границы выделенного буфера, другая раскрывала адрес в памяти и помогала обойти защиту ASLR. Вместе уязвимости давали атакующему возможность выполнить произвольную команду от имени системного пользователя git.
GitLab использовал Oj при отображении различий между версиями Jupyter Notebook. Сервер передавал содержимое загруженного файла непосредственно нативному парсеру внутри рабочего процесса Puma. Специально сформированные данные нарушали структуру памяти и перенаправляли выполнение программы на выбранную злоумышленником команду.
Полученный доступ может оказаться значительно опаснее обычного взлома одного проекта. Пользователь git способен читать исходный код, секреты Rails, данные CI/CD, учётные данные, материалы для подписи токенов и обращаться к внутренним сервисам, доступным серверу GitLab. Масштаб последствий зависит от конфигурации конкретной установки и прав системного пользователя.
Проблема затрагивает GitLab Community Edition и Enterprise Edition всех тарифов. Уязвимы версии с 15.2.0 по 18.10.7, с 18.11.0 по 18.11.4, а также 19.0.0 и 19.0.1. Исправления впервые появились в выпусках 18.10.8, 18.11.5 и 19.0.2, которые включают безопасную версию Oj 3.17.3. Облачный сервис GitLab.com обновили к моменту выхода патча, поэтому действия требуются прежде всего владельцам самостоятельно развёрнутых серверов.
Главная претензия исследователей связана не со скоростью исправления, а с тем, как GitLab сообщил о риске администраторам. В релизных заметках от 10 июня обновление Oj до версии 3.17.3 попало в раздел обычных исправлений. GitLab не присвоил цепочке отдельный идентификатор CVE, не указал оценку CVSS и не предупредил, что обновление закрывает удалённое выполнение кода. При этом в том же бюллетене компания подробно перечислила другие уязвимости в отдельной таблице безопасности.
Администраторы, которые изучали только раздел с исправлениями безопасности, могли не увидеть причин срочно устанавливать обновление зависимости. Публичный эксплойт появился 24 июля, спустя шесть недель после выпуска патча, и заметно повысил риск атак на серверы, которые до сих пор работают на старых версиях.
depthfirst сообщила об ошибках разработчику Oj 21 мая. Исправления вошли в код 27 мая, а Oj 3.17.3 вышел 4 июня. Исследователи передали GitLab готовую цепочку атаки 5 июня, компания подтвердила проблему через три дня и выпустила обновления 10 июня. Сведений о реальных атаках пока нет, однако после публикации PoC рассчитывать на длительное отсутствие эксплуатации уже не стоит.
Владельцам собственных серверов GitLab рекомендуется установить актуальную поддерживаемую версию. Отдельного способа заблокировать атаку без обновления GitLab или Oj исследователи не предложили.
- Источник новости
- www.securitylab.ru
