The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Вторая за неделю критическая уязвимость в GitLab "
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от opennews (??), 31-Авг-22, 08:24 
Компания GitLab опубликовала очередную серию корректирующих обновлений своей платформы для организации совместной разработки -  15.3.2, 15.2.4 и 15.1.6, в которых устранена критическая уязвимость (CVE-2022-2992), позволяющая аутентифицированному пользователю удалённо выполнить код на сервере. Как и уязвимость CVE-2022-2884, исправленная неделю назад, новая проблема присутствует в API для импорта данных из сервиса GitHub. Уязвимость проявляется в том числе в выпусках 15.3.1, 15.2.3 и 15.1.5, в которых была исправлена первая уязвимость в коде импорта из GitHub...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57704

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


3. Скрыто модератором  –9 +/
Сообщение от Иваня (?), 31-Авг-22, 08:36 
Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором  +/
Сообщение от Минона (ok), 31-Авг-22, 09:18 
Ответить | Правка | Наверх | Cообщить модератору

8. "Вторая за неделю критическая уязвимость в GitLab "  +3 +/
Сообщение от Аноним (8), 31-Авг-22, 09:31 
дружно переходим на Gitea
Ответить | Правка | Наверх | Cообщить модератору

9. "Вторая за неделю критическая уязвимость в GitLab "  –2 +/
Сообщение от YetAnotherOnanym (ok), 31-Авг-22, 09:39 
Ты что? Он же на Си! Там же дырени!
Ответить | Правка | Наверх | Cообщить модератору

13. "Вторая за неделю критическая уязвимость в GitLab "  +5 +/
Сообщение от Аноним (13), 31-Авг-22, 10:34 
Разве Gitea не на Go?
Ответить | Правка | Наверх | Cообщить модератору

14. "Вторая за неделю критическая уязвимость в GitLab "  +5 +/
Сообщение от anonymous (??), 31-Авг-22, 11:02 
главное что не на расте
Ответить | Правка | Наверх | Cообщить модератору

16. "Вторая за неделю критическая уязвимость в GitLab "  +1 +/
Сообщение от YetAnotherOnanym (ok), 31-Авг-22, 11:07 
> Разве Gitea не на Go?

А, блин, перепутал, сорри.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

23. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от Владимир (??), 31-Авг-22, 19:16 
>А, блин, перепутал, сорри.

Фрактал простит ...

Ответить | Правка | Наверх | Cообщить модератору

30. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от InuYasha (??), 01-Сен-22, 00:14 
CGit на C.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

36. "Вторая за неделю критическая уязвимость в GitLab "  +1 +/
Сообщение от Аноним (36), 01-Сен-22, 16:00 
> CGit на C.

И кстати не замечен в приколах вида "вторая за неделю критическая уязвимость". Наверное потому что не пытается быть энтерпрайзным монстром пытающимся решать все проблемы человечества, вместо того чтобы быть интерфейсом к DVCS.

Ответить | Правка | Наверх | Cообщить модератору

19. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от Аноним (19), 31-Авг-22, 13:11 
Давно было пора.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

22. "Вторая за неделю критическая уязвимость в GitLab "  +6 +/
Сообщение от Аноним (-), 31-Авг-22, 16:54 
Вроде Blender недавно перешел на Gitea. А это уже весомый аргумент.

А чем Gitea так крут? Кто пользовался?

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

24. "Вторая за неделю критическая уязвимость в GitLab "  +1 +/
Сообщение от Аноним (24), 31-Авг-22, 20:18 
просто гитлаб крут, пока не начинаешь его использовать.
Нужны зеркала репозиториев (pull)? — плати деньги. А в gitea они "бесплатные"
Ты прикрутил линтер/etc… и оно в MR сгенерировало много коментариев? — больше ты не видишь коментариев в этом MR
Тебе захотелось вынести часть CI в репозиторий доступный только безопасникам (для их нужд)? А все, CI работать не будет, т.к. для запуска нужны права девелопера в репозитории безопасников. Решил хотя бы использовать защищенную ветку? А теперь давай всем права мэнтейнера
Хочешь скрыть в CI пароль? — Используй только буквенно-цифровые комбинации.
И т.д. И баги висят годами

В случае гитлаба, если не готов платить деньги, то костылишь некоторые возможности, если готов, то все равно костылишь.

Ответить | Правка | Наверх | Cообщить модератору

26. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от freehckemail (ok), 31-Авг-22, 21:40 
> Нужны зеркала репозиториев (pull)? — плати деньги. А в gitea они "бесплатные"

Давно уже в Community Edition, то есть бесплатно. Правда, я не понимаю, зачем они вообще там нужны, ибо развернуть свой docker registry mirror -- блин, ну просто контейнер поднять. Было бы зачем огород городить.

> Тебе захотелось вынести часть CI в репозиторий доступный только безопасникам (для их нужд)? А все, CI работать не будет, т.к. для запуска нужны права девелопера в репозитории безопасников.

Создайте в проекте безопасников токен с минимальным набором нужных привилегий и триггерите пайплайн этого проекта через него.

> Ты прикрутил линтер/etc… и оно в MR сгенерировало много коментариев? — больше ты не видишь коментариев в этом MR

Понимаю, о чём вы. Да, бага с просмотром тестов висела очень долго. Но в конечном итоге её ж пофиксили.

> Хочешь скрыть в CI пароль? — Используй только буквенно-цифровые комбинации.

Ну не только буквенно-циферные. Там есть некоторое количество спецсимволов:
https://git.docrobot.ru/help/ci/variables/index#mask-a-cicd-...

В любом случае mask -- это не 100% защита, и это надо понимать.

Ответить | Правка | Наверх | Cообщить модератору

28. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от Аноним (28), 31-Авг-22, 22:32 
> Давно уже в Community Edition, то есть бесплатно.

а гитлабовцы пишут, что премиум https://docs.gitlab.com/ee/user/project/repository/mirror/pu...

> Создайте в проекте безопасников токен с минимальным набором нужных привилегий и триггерите пайплайн этого проекта через него.

курлом что ли? тогда между пайплайнами нет связи и, если пайплайн безопасников выполнился не успешно, то пайплайн разработчиков об этом никак не узнает. Я нашел только открытые тикеты на эту тему

> Но в конечном итоге её ж пофиксили.

мы уже извернулись через отправку почты и чаты. Криво, но три года ждать не могли.

> В любом случае mask -- это не 100% защита, и это надо понимать.

да это понятно, учитывая, в т.ч. и доступ к .gitlab-ci. Но к примеру тот же дженкинс не позволяет просматривать или редактировать секреты после сохранения, генерирует +/- случайные пути к файлам и т.д.

Просто в случае gitea знаешь на что подписался: она идет бесплатно и нужное приходится доделывать самому. А тут вроде деньги заплатил, а нужное приходится доделывать самому :)

Ответить | Правка | Наверх | Cообщить модератору

29. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от freehckemail (ok), 31-Авг-22, 23:44 
>> Давно уже в Community Edition, то есть бесплатно.
> а гитлабовцы пишут, что премиум

А, эти зеркала. Пардон. Я подумал, что речь про registry mirror. Да, эти -- пока только в премиуме. Но у меня для этого shell-скрипт есть. Наваял буквально за час, там ведь надо по сути всего-ничего: git clone --mirror / git push --mirror. Само собой, что покупать ради этого премиум -- нонсенс.

>> Создайте в проекте безопасников токен с минимальным набором нужных привилегий и триггерите пайплайн этого проекта через него.
> курлом что ли? тогда между пайплайнами нет связи и, если пайплайн безопасников выполнился не успешно, то пайплайн разработчиков об этом никак не узнает. Я нашел только открытые тикеты на эту тему

Держи: https://gitlab.com/almaops/gitlab-trigger-deploy
Я этот скрипт написал лет пять назад, когда впервые столкнулся с данным вопросом.
Используем для деплоев в основном, но по сути он триггерит пайплайн другого проекта, дожидается его завершения и наследует его статус. Спецом для делплоев обернул полгода назад в контейнер, ибо это применение триггера -- самое частое.

>> Но в конечном итоге её ж пофиксили.
> мы уже извернулись через отправку почты и чаты. Криво, но три года ждать не могли.

А мы -- через allure и pages. Старый проверенный надёжный инструмент.

>> В любом случае mask -- это не 100% защита, и это надо понимать.
> да это понятно, учитывая, в т.ч. и доступ к .gitlab-ci.

Доступ в .gitlab-ci.yml тут не при чём, ибо что тебе толку от возможности его поправить, если пароль от волта с реквизитами прода доступен только в protected-бранче.

> Но к примеру тот же дженкинс не позволяет просматривать или редактировать секреты после сохранения, генерирует +/- случайные пути к файлам и т.д.

Ну, при наличии доступа к скрипту пайплайна -- это что в дженкинсе, что в гитлабе обходится на раз-два. Тут не о чем спорить. Суть в том, что маскировка переменных -- не более чем защита на случай, если сам ошибёшься где-то. Для защиты секретов нужен protected-бранч с ответственным мейнтейнером во-первых, во-вторых vault как второй уровень защиты, и в-третьих строго прописанные регламенты гитфлоу, в которых зафиксирована ответственность мейнтейнера в случае компрометирующих секреты правок в пайплайн.

> Просто в случае gitea знаешь на что подписался: она идет бесплатно и нужное приходится доделывать самому. А тут вроде деньги заплатил, а нужное приходится доделывать самому :)

Понимаю, но у меня с gitlab ровно та же песня: подавляющее большинство инсталляций -- именно community edition. А нужный платный функционал реализован своими скриптами. Большинству клиентов это как раз очень нравится: то, что можно обойтись бесплатной версией гитлаба, но за счёт нашей экспертизы использовать его на полную мощность. Я ничего не имею против gitea, однако gitlab допиливать нужно кратно меньше: а подавляющему большинству и вовсе хватает бесплатной версии "как она есть".

Ответить | Правка | Наверх | Cообщить модератору

31. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от Аноним (24), 01-Сен-22, 00:55 
> Доступ в .gitlab-ci.yml тут не при чём, ибо что тебе толку от возможности его поправить, если пароль от волта с реквизитами прода доступен только в protected-бранче.

ну вот либо используешь возможности гитлаба и живешь без protected-бранчей или с лишними мэнтейнерами, либо подставляешь костыли
Вроде у них в планах есть переделка прав и ролей, но неизвестно когда

спасибо за скрипт. Я вспомнил, что находил уже подобное https://gitlab.com/finestructure/pipeline-trigger
только не помню, почему не использовали

Ответить | Правка | Наверх | Cообщить модератору

34. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от freehckemail (ok), 01-Сен-22, 10:47 
>> Доступ в .gitlab-ci.yml тут не при чём, ибо что тебе толку от возможности его поправить, если пароль от волта с реквизитами прода доступен только в protected-бранче.
> ну вот либо используешь возможности гитлаба и живешь без protected-бранчей
> или с лишними мэнтейнерами, либо подставляешь костыли

Ну я бы не сказал, что это прям костыли. Я видел много систем CI/CD. И везде приходилось что-то допиливать. В gitlab приходилось допиливать меньше всего. Где-то у меня был драфт заметки о недостатках скриптования пайплайнов в разных CI/CD системах, можно было бы её поднять и актуализировать. Я в итоге пришёл к тому, что gitlab меня устраивает куда больше всех прочих, и последний год я сижу исключительно на нём. А так-то, если подумать, мог бы написать сравнение с jenkins, travis, circle, codefresh, drone, teamcity и gitea. Благо, опыт имеется.

Справедливости ради, в некоторых из них есть фишки, которых в gitlab нету, в том же teamcity или travis например. Некоторые предоставляют больше возможностей сделать что-то нестандартное, хоть тот же jenkins. Правда, в его случае начинает играть человеческий фактор, и люди начинают повально велосипедить, так что ещё не факт, плюс ли это.

> Вроде у них в планах есть переделка прав и ролей, но неизвестно когда

По опыту скажу: вряд ли этого стоит ждать когда-либо. Очень вряд ли.

> спасибо за скрипт. Я вспомнил, что находил уже подобное https://gitlab.com/finestructure/pipeline-trigger
> только не помню, почему не использовали

Посмотрел на скрипт. Догадываюсь, почему его не хотелось использовать. Впрочем, если иных обходных решений не было, не могу понять, почему не использовали, даже если не хотелось. Вполне сошёл бы за основу.

Ответить | Правка | Наверх | Cообщить модератору

25. "Вторая за неделю критическая уязвимость в GitLab "  +3 +/
Сообщение от freehckemail (ok), 31-Авг-22, 21:17 
Как раз недавно писал на эту тему: https://www.opennet.dev/openforum/vsluhforumID3/128263.html#42

Распишу чуть более подробно именно в плане сравнения.

Gitea может быть крута, если ты умеешь её готовить. А готовить её надо уметь. Она из коробки предоставляет только минимально необходимый функционал, всё прочее необходимое для функционирования IT-производства реализуется сторонним софтом и интеграциями. Так, например, изначально в Gitea нет даже пайплайнов. Но вы можете поднять Drone и настроить интеграцию с Gitea. И вот, какие-то пайплайны у вас есть. Но вот допустим хотите вы собрать контейнер. Заюзали вы Drone с плагином для докера, собрали, надо запушить. А куда? Нужен docker registry. Извольте поднять самостоятельно. Ну и собственно додумайте сами ответ на впоросы "а что если мы собираем не докер имидж, а иные артефакты?" или "а что там c кэшированием?". Всё это потребует вашего времени. Тем не менее, если вы всё-таки его потратите на Gitea, то вы сможете её довести до состояния конфетки, которая будет делать ровно то, что вам нужно.

С другой стороны есть Gitlab. Он крут прямо из коробки, ибо предоставляет весь необходимый функционал сразу. То есть вместе с гитлабом у вас также будет установлен сервер хранения артефактов, container registry, сбор метрик, мониторинг, пайплайны (только подними раннеры, а сам сервер уже подготовлен), и всё это заинтегрировано друг с другом и готово к работе вот прямо сразу после установки. За это вы расплатитесь повышенным потреблением ресурсов, что вероятно не так уж хорошо для маленьких проектов. Но честно говоря, когда я смотрел в последний раз, в том же яндексе виртуалка с минимальной конфигурацией для гитлаба стоила что-то около трёх тысяч в месяц, так что это насколько ж бизнес должен быть мелким, чтобы не потянуть 3 косаря.

В общем, я при прочих равных выбираю Gitlab именно потому, что он не конструктор, а сразу решает задачи бизнеса.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

27. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от лютый ж.... (?), 31-Авг-22, 21:41 
>в том же яндексе виртуалка с минимальной конфигурацией
>насколько ж бизнес должен быть мелким

насколько мозг должен быть мелким, чтобы использовать виртуалки шындекса? в том же селектеле
за 5 тыр в месяц получаешь i7-3.4ГГц/32GB/2×240GBSSD
а за 6 тыр i7-3.4ГГц/64ГБ/2×480ГБSSD

Ответить | Правка | Наверх | Cообщить модератору

35. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от freehckemail (ok), 01-Сен-22, 13:36 
>>в том же яндексе виртуалка с минимальной конфигурацией
>>насколько ж бизнес должен быть мелким
> насколько мозг должен быть мелким, чтобы использовать виртуалки шындекса?

Дорогой. Прежде, чем рассуждать об интеллектуальных качествах собеседника, подумай о следующем: вот пришёл к тебе клиент, у которого уже есть инфраструктура, купленная у конкретного вендора, и она его устраивает; ты будешь ему вендора менять только потому, что текущий -- неправославный? Или всё-таки выполнишь только ту работу, на которую подрядился?

Ответить | Правка | Наверх | Cообщить модератору

38. "Вторая за неделю критическая уязвимость в GitLab "  –1 +/
Сообщение от Аноним (-), 01-Сен-22, 17:23 
> насколько мозг должен быть мелким, чтобы использовать виртуалки шындекса?

Это freehck, он давно себя гением мысли зарекомендовал. На аву посмотри, лол.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

10. "Вторая за неделю критическая уязвимость в GitLab "  +2 +/
Сообщение от YetAnotherOnanym (ok), 31-Авг-22, 09:41 
Но как же так? Ведь Руби - безопасный язык, в нём нет работы с памятью напрямую!
Ответить | Правка | Наверх | Cообщить модератору

11. "Вторая за неделю критическая уязвимость в GitLab "  +3 +/
Сообщение от Аноним (-), 31-Авг-22, 09:54 
но это ничего не гарантирует ☝️
Ответить | Правка | Наверх | Cообщить модератору

17. "Вторая за неделю критическая уязвимость в GitLab "  –1 +/
Сообщение от Аноним (17), 31-Авг-22, 12:12 
Что же это тогда получается, раст тоже небезопасны язык?
Ответить | Правка | Наверх | Cообщить модератору

20. "Вторая за неделю критическая уязвимость в GitLab "  +1 +/
Сообщение от Аноним (20), 31-Авг-22, 13:15 
никогда им не был
Ответить | Правка | Наверх | Cообщить модератору

18. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от Аноним (17), 31-Авг-22, 12:12 
Программисты на Руби уже давно редкий вид, который редко встречается в природе. Баги фиксить некому.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

21. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от лютый ж.... (?), 31-Авг-22, 13:53 
Какая-то хэрня... у любого девелопера всё равно есть права в .gitlab-ci.yml прописать любую команду и runner её выполнит )
Ответить | Правка | Наверх | Cообщить модератору

32. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от Ананоним (?), 01-Сен-22, 01:56 
Тссссссс! Не пали фичу!
Ответить | Правка | Наверх | Cообщить модератору

37. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от Аноним (-), 01-Сен-22, 17:20 
> Какая-то хэрня... у любого девелопера всё равно есть права в .gitlab-ci.yml прописать
> любую команду и runner её выполнит )

На третий день Зоркий Глаз заметил что вебмакаки не умеют в безопасность систем.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

39. "Вторая за неделю критическая уязвимость в GitLab "  +/
Сообщение от VitalyE (?), 04-Сен-22, 00:51 
а если я вынесу в отдельную репу .gitlab-ci.yml и не дам права - сможешь прописать что-то на выполнение?)
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру