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

"Уязвимость в GitLab, позволяющая записать файлы в произвольный каталог на сервере"	+/–
Сообщение от opennews (?), 26-Янв-24, 10:06
Опубликованы корректирующие обновления платформы для организации совместной разработки - GitLab 16.8.1, 16.7.4, 16.6.6 и 16.5.8, в которых устранены 5 уязвимостей. Одной из проблем (CVE-2024-0402), которая проявляется начиная с выпуска GitLab 16.0, присвоен критический уровень опасности. Уязвимость позволяет аутентифицированному пользователю записать  файлы в любой каталог на сервере, насколько это позволяют права доступа, под которыми выполняется web-интерфейс GitLab... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60498
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Адмирал Майк Роджерс (?), 26-Янв-24, 10:06	–4 +/–
Tor Project просто молодцы, что перешли на это заведомое рeшето.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22

2. Сообщение от Бывалый смузихлёб (?), 26-Янв-24, 10:16	+4 +/–
> проблема решена преобразованием YAML в JSON > и проверкой наличия конструкций, корректных в YAML, > но недопустимых в JSON из-за использования > определённых Unicode-символов Гениально! Что ни день - то патчи продуктов всё лучше и лучше
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #30, #39

5. Сообщение от Аноним (5), 26-Янв-24, 10:31	+3 +/–
это же классика (NSFW контент далее): ``` $data = json_decode($data); if (is_null($data) && JSON_ERROR_NONE !== json_last_error_msg()) {     // ошибка =) } ```
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #13, #38

8. Сообщение от Аноним (8), 26-Янв-24, 11:38	+2 +/–
>в патче проблема решена преобразованием YAML в JSON и проверкой наличия конструкций, корректных в YAML, но недопустимых в JSON Надо YAML->JSON->XML, так ещё вероятнее обнаружение некорректных конструкций. Так надёжнее! ;)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

9. Сообщение от YetAnotherOnanym (ok), 26-Янв-24, 12:06	+1 +/–
То есть, ни подобрать с самого начала, ни перейти сейчас на нормальную либу для парсинга ямла, оказалось задачей непосильной.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

10. Сообщение от anonymous (??), 26-Янв-24, 12:07	+2 +/–
У XML хоть DTD есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #19, #20

11. Сообщение от anonymous (??), 26-Янв-24, 12:08	+4 +/–
Ямл и нормално в одном предложении ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

13. Сообщение от penetrator (?), 26-Янв-24, 12:34	+1 +/–
что за мерзкий язык похожий на JS, и почему там не "или"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #14

14. Сообщение от Аноним (5), 26-Янв-24, 12:53	+1 +/–
Рядом, это пыха) А почему "И", потому что до сих пор в пыхе (да и в js) "null" - это валидный json равный NULL. И это не считается ошибкой, хотя json_decode при ошибке вернет именно NULL. ❯ php83 -r 'var_dump(json_validate("null"), json_decode("null", true), json_last_error_msg());' Command line code:1: bool(true) Command line code:1: NULL Command line code:1: string(8) "No error"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #23, #34, #41

16. Сообщение от anonymous (??), 26-Янв-24, 13:28	+/–
А в чём уязвимость-то? "Отдай свои ценные файлы гитлабу бесплатно"?
Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от hshhhhh (ok), 26-Янв-24, 14:46	+/–
Вот бы люди изобрели json schema!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

20. Сообщение от Аноним (20), 26-Янв-24, 14:56	+/–
У JSON хоть JSON Schema есть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #29

21. Сообщение от Пряник (?), 26-Янв-24, 15:06	+/–
> насколько это позволяют права доступа, под которыми выполняется web-интерфейс GitLab бесполезная уязвимость
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

22. Сообщение от scriptkiddis (?), 26-Янв-24, 15:48	–1 +/–
Критикуешь предлагай. Какие альтернативы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #26, #31, #32, #33

23. Сообщение от Аноним (23), 26-Янв-24, 15:50	+1 +/–
Стоит отметить, что json_decode поддерживает флаг JSON_THROW_ON_ERROR начиная где-то с 7.3, который помогает убрать немного костылирования вокруг этой функциональности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

24. Сообщение от scriptkiddis (?), 26-Янв-24, 15:51	+/–
Получение доступа к любому файлу в /var/opt/gitlab такое себе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от Аноним (25), 26-Янв-24, 16:09	+4 +/–
> в патче проблема решена преобразованием YAML в JSON и проверкой наличия конструкций, корректных в YAML, но недопустимых в JSON из-за использования определённых Unicode-символов Это какое-то зумерское "исправление". Я сейчас пытаюсь осознать, что зумеры чтобы проверить на наличие определённых символов перегоняют один смузи-формат в другой... Наверняка с гигабайтами задействованных фреймворков. Это какая-то странная квази-айтишная эволюция пост-советских офисных тётенек, зачем-то перегонявших документ в .jpeg  с помощью принтера и сканера. Что дальше, для тупого сравнения строк будет запускаться нейросеть в облаке? Мозги, для чего они?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #35

26. Сообщение от Аноним (26), 26-Янв-24, 16:15	+2 +/–
trac, который был до перехода на GitLab.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #37

27. Сообщение от Аноним (-), 26-Янв-24, 17:02	+/–
> Что дальше, для тупого сравнения строк К сожалению со сравнением строк тоже не все хорошо. Вон недавно в GNU split не смогли строку на две части разделить. И получили уязвимость...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

29. Сообщение от Аноним (29), 26-Янв-24, 18:53	+1 +/–
…но её никто не использует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

30. Сообщение от Аноньимъ (ok), 26-Янв-24, 19:05	+/–
Это вообще жесть. А проверить строку на левые юникод символы это типо слишком сложно уже?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

31. Сообщение от Аноним (31), 26-Янв-24, 19:15	+/–
Вообще непонятно, почему многие когда-то туда ломанулись. Gitea же намного лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

32. Сообщение от лютый жабби.... (?), 26-Янв-24, 20:11	+1 +/–
>Какие альтернативы? внизапна просто git
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

33. Сообщение от Аноним (-), 26-Янв-24, 20:52	+/–
> Критикуешь предлагай. Какие альтернативы? Gitea или как там ее. То что используют codeberg и notabug. В цать раз менее монструозное нечто, и дыр соответственно - тоже! А gitlab - это монструозный лагучий спагетти-монстр. В котором - вот - по вулну каждый месяц, если не больше. Штуки типа tor - заманаются руткиты с серваков вынимать потом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

34. Сообщение от Аноним (-), 26-Янв-24, 20:54	+/–
> Рядом, это пыха) А та байда на ruby, чтоли, накорябана. При чем тут пыха то вообще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #36

35. Сообщение от Аноним (-), 26-Янв-24, 20:55	+/–
> Это какая-то странная квази-айтишная эволюция пост-советских офисных тётенек, > зачем-то перегонявших документ в .jpeg  с помощью принтера и сканера. Это тебе еще повезло. А то могут и при помощи камеры на мобильнике. Ну подумаешь, не в фокусе немного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

36. Сообщение от Аноним (5), 26-Янв-24, 22:39	+/–
>> Рядом, это пыха) > А та байда на ruby, чтоли, накорябана. При чем тут пыха то > вообще? Это бы ответ на вопрос про мерзкий язык, похожий на js. На руби не пишу, но, судя по новости, весь серверный веб на интерпритируемых языках "на уровне".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

37. Сообщение от jkkj (?), 27-Янв-24, 01:54	+/–
Который в стагнации уже очень давно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

38. Сообщение от qwe (??), 27-Янв-24, 02:22	+/–
То есть вторая часть условия никогда не сработает, потому что json_last_error_msg никогда не вернет JSON_ERROR_NONE. Там должна быть функция json_last_error.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #40

39. Сообщение от Аноним (39), 27-Янв-24, 11:33	+/–
Эти упражнения с юникодом будут вечны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

40. Сообщение от Аноним (5), 27-Янв-24, 22:22	+/–
> То есть вторая часть условия никогда не сработает, потому что json_last_error_msg никогда > не вернет JSON_ERROR_NONE. Там должна быть функция json_last_error. Yep, лоханулся =( Хорошо что это не стек) отсюда не скопируют)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

41. Сообщение от penetrator (?), 28-Янв-24, 04:29	+/–
> Рядом, это пыха) > А почему "И", потому что до сих пор в пыхе (да и > в js) "null" - это валидный json равный NULL. И это > не считается ошибкой, хотя json_decode при ошибке вернет именно NULL. ОК, допустим, мы такие а вдруг распарсит без ошибок и вернет нул из json_decode, в этом случае отработает правая часть: JSON_ERROR_NONE !== json_last_error_msg() т.е. корректность парсинга определяется только этой правой частью, а значит нам нет никакого смысла делать ненужную проверку слева от И независимо от того, что у нас в data ты можешь сказать, что если нул вернулся, то не должна программа продолжится, ну тогда не нужна правая часть, а только левая, потому что проверять надо на нул - вернулся нул - шлем нафиг, и все равно по какой причине, ошибка парсинга или нулевой жсон или я какой-то пых финт упускаю?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #42

42. Сообщение от Аноним (5), 28-Янв-24, 14:19	+/–
> или я какой-то пых финт упускаю? не, все так
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

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

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