Gitea 28.3 закрывает ошибки OAuth, токенов и доступа к секретам Actions
В обслуживающем выпуске исправлены несколько разных границ доступа. Условия эксплуатации зависят от настроек входа, владельца токена и наличия CI-раннера.
Обновление касается не одной уязвимости
1 ноября разработчики Gitea выпустили 28.3.0 — третье обслуживающее обновление серии 28. В официальном объявлении перечислены исправления безопасности, а также изменения Actions, задач, запросов на слияние и пакетов. Команда рекомендует пользователям обновиться как можно скорее. Это выпуск самой платформы для совместной работы с кодом, а не отдельного CI-раннера.
За похожими формулировками о правах скрываются разные сценарии. В одном случае важна автоматическая привязка внешней учётной записи, в другом — обработка workflow, в третьем — ограничение уже выданного административного токена. По одному заголовку нельзя заключить, что каждый сервер уязвим одинаковым способом.
OAuth: откуда берётся имя связываемой учётной записи
Бюллетень GHSA-8p3x-w464-4g6v описывает захват аккаунта при включённом ACCOUNT_LINKING = auto. Эта настройка не является значением по умолчанию. Участник, вошедший через настроенного OAuth2-провайдера, мог передать через форму привязки имя или почту существующего пользователя, после чего внешняя идентичность связывалась с чужой записью.
Ошибка состояла не просто в доверии к корпоративному провайдеру: общий обработчик принимал значения из пользовательской формы за основание для поиска аккаунта. Поэтому даже провайдер, корректно проверявший собственные данные, не устранял этот путь. Advisory указывает версии до 28.2.0 включительно и исправление в 28.3.0. Это не утверждение о том, что обычный вход по паролю на любом экземпляре позволяет такой же захват.
Actions: чтение репозитория не должно давать его секреты
В GHSA-32h8-5xqg-h466 разобран другой механизм. Пользователь с правом чтения мог указать собственный коммит в отзыве к pull request. Файлы workflow выбирались по этому коммиту, а решение о доверии — по рассматриваемому запросу на слияние. В результате чужой workflow получал режим выполнения, не соответствующий происхождению кода.
Для описанного сценария нужны аккаунт, обслуживающий репозиторий раннер и pull request с веткой внутри того же репозитория. Выполнение могло получить Actions-секреты и GITEA_TOKEN с правом записи. В бюллетене отмечено, что одного запрета форков недостаточно. Затронут диапазон от 1.19.0 до 28.2.0 включительно; исправленная версия — 28.3.0. Сам отчёт не доказывает, что конкретный сервер уже был атакован.
Public-only токен администратора оставался слишком широким
GHSA-37xv-m4w7-j2fh касается административного API. Ограничение public-only не применялось к этой группе маршрутов. Такой токен мог раскрывать закрытые организации и адреса пользователей, а также выполнять административные операции, включая создание новой учётной записи администратора.
Существенная деталь: токен должен был принадлежать администратору сайта. Проверка административной роли оставалась на месте; обычный пользователь с произвольно выбранным scope не превращался в администратора. Это ошибка сужения полномочий токена, а не снятие всех проверок авторизации. Авторы отчёта отдельно указывают, что отзыв токена не удаляет созданный с его помощью новый аккаунт. Поэтому установка исправления и проверка уже произошедших изменений — разные действия.
Не только безопасность, но и поведение очереди
В обычной части release notes отмечено, что раннеры больше не подбирают задания репозиториев с выключенными Actions. Также исправлены индексы и лишняя работа SQLite при просмотре очереди заданий. Для обсуждений и запросов на слияние скорректированы проверки блокировки и синхронизация текста отзыва.
Это перечисление подтверждённых изменений, а не результат нагрузочного теста ЭРИТКОМ. В объявлении нет универсального процента ускорения для любой установки, и версии серверного приложения не следует смешивать с версиями подключённых раннеров.
