URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 132669
[ Назад ]
Исходное сообщение
"Уязвимость в 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.dev/opennews/art.shtml?num=60498

Содержание
Сообщения в этом обсуждении
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Адмирал Майк Роджерс , 26-Янв-24 10:06 
Tor Project просто молодцы, что перешли на это заведомое рeшето.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено scriptkiddis , 26-Янв-24 15:48 
Критикуешь предлагай. Какие альтернативы?
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 16:15 
trac, который был до перехода на GitLab.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено jkkj , 27-Янв-24 01:54 
Который в стагнации уже очень давно.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 19:15 
Вообще непонятно, почему многие когда-то туда ломанулись. Gitea же намного лучше.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено лютый жабби.... , 26-Янв-24 20:11 
>Какие альтернативы?

внизапна просто git

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 20:52 
> Критикуешь предлагай. Какие альтернативы?

Gitea или как там ее. То что используют codeberg и notabug. В цать раз менее монструозное нечто, и дыр соответственно - тоже!

А gitlab - это монструозный лагучий спагетти-монстр. В котором - вот - по вулну каждый месяц, если не больше. Штуки типа tor - заманаются руткиты с серваков вынимать потом.

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Бывалый смузихлёб , 26-Янв-24 10:16 
> проблема решена преобразованием YAML в JSON
> и проверкой наличия конструкций, корректных в YAML,
> но недопустимых в JSON из-за использования
> определённых Unicode-символов

Гениально! Что ни день - то патчи продуктов всё лучше и лучше

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 10:31 
это же классика (NSFW контент далее):

```
$data = json_decode($data);
if (is_null($data) && JSON_ERROR_NONE !== json_last_error_msg()) {
    // ошибка =)
}
```

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено penetrator , 26-Янв-24 12:34 
что за мерзкий язык похожий на JS, и почему там не "или"?
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 12:53 
Рядом, это пыха)

А почему "И", потому что до сих пор в пыхе (да и в 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"

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 15:50 
Стоит отметить, что json_decode поддерживает флаг JSON_THROW_ON_ERROR начиная где-то с 7.3, который помогает убрать немного костылирования вокруг этой функциональности
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 20:54 
> Рядом, это пыха)

А та байда на ruby, чтоли, накорябана. При чем тут пыха то вообще?

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 22:39 
>> Рядом, это пыха)
> А та байда на ruby, чтоли, накорябана. При чем тут пыха то
> вообще?

Это бы ответ на вопрос про мерзкий язык, похожий на js. На руби не пишу, но, судя по новости, весь серверный веб на интерпритируемых языках "на уровне".

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено penetrator , 28-Янв-24 04:29 
> Рядом, это пыха)
> А почему "И", потому что до сих пор в пыхе (да и
> в js) "null" - это валидный json равный NULL. И это
> не считается ошибкой, хотя json_decode при ошибке вернет именно NULL.

ОК, допустим, мы такие а вдруг распарсит без ошибок и вернет нул из json_decode, в этом случае отработает правая часть: JSON_ERROR_NONE !== json_last_error_msg()

т.е. корректность парсинга определяется только этой правой частью, а значит нам нет никакого смысла делать ненужную проверку слева от И независимо от того, что у нас в data

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

или я какой-то пых финт упускаю?

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 28-Янв-24 14:19 
> или я какой-то пых финт упускаю?

не, все так

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено qwe , 27-Янв-24 02:22 
То есть вторая часть условия никогда не сработает, потому что json_last_error_msg никогда не вернет JSON_ERROR_NONE. Там должна быть функция json_last_error.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 27-Янв-24 22:22 
> То есть вторая часть условия никогда не сработает, потому что json_last_error_msg никогда
> не вернет JSON_ERROR_NONE. Там должна быть функция json_last_error.

Yep, лоханулся =(

Хорошо что это не стек) отсюда не скопируют)

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноньимъ , 26-Янв-24 19:05 
Это вообще жесть.
А проверить строку на левые юникод символы это типо слишком сложно уже?
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 27-Янв-24 11:33 
Эти упражнения с юникодом будут вечны.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 11:38 
>в патче проблема решена преобразованием YAML в JSON и проверкой наличия конструкций, корректных в YAML, но недопустимых в JSON

Надо YAML->JSON->XML, так ещё вероятнее обнаружение некорректных конструкций. Так надёжнее! ;)

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено anonymous , 26-Янв-24 12:07 
У XML хоть DTD есть.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено hshhhhh , 26-Янв-24 14:46 
Вот бы люди изобрели json schema!
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 14:56 
У JSON хоть JSON Schema есть
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 18:53 
…но её никто не использует.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено YetAnotherOnanym , 26-Янв-24 12:06 
То есть, ни подобрать с самого начала, ни перейти сейчас на нормальную либу для парсинга ямла, оказалось задачей непосильной.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено anonymous , 26-Янв-24 12:08 
Ямл и нормално в одном предложении ?
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено anonymous , 26-Янв-24 13:28 
А в чём уязвимость-то? "Отдай свои ценные файлы гитлабу бесплатно"?
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Пряник , 26-Янв-24 15:06 
> насколько это позволяют права доступа, под которыми выполняется web-интерфейс GitLab

бесполезная уязвимость

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено scriptkiddis , 26-Янв-24 15:51 
Получение доступа к любому файлу в /var/opt/gitlab такое себе.
"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 16:09 
> в патче проблема решена преобразованием YAML в JSON и проверкой наличия конструкций, корректных в YAML, но недопустимых в JSON из-за использования определённых Unicode-символов

Это какое-то зумерское "исправление". Я сейчас пытаюсь осознать, что зумеры чтобы проверить на наличие определённых символов перегоняют один смузи-формат в другой... Наверняка с гигабайтами задействованных фреймворков.

Это какая-то странная квази-айтишная эволюция пост-советских офисных тётенек, зачем-то перегонявших документ в .jpeg  с помощью принтера и сканера.

Что дальше, для тупого сравнения строк будет запускаться нейросеть в облаке? Мозги, для чего они?

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 17:02 
> Что дальше, для тупого сравнения строк

К сожалению со сравнением строк тоже не все хорошо.
Вон недавно в GNU split не смогли строку на две части разделить.
И получили уязвимость...

"Уязвимость в GitLab, позволяющая записать файлы в произвольн..."
Отправлено Аноним , 26-Янв-24 20:55 
> Это какая-то странная квази-айтишная эволюция пост-советских офисных тётенек,
> зачем-то перегонявших документ в .jpeg  с помощью принтера и сканера.

Это тебе еще повезло. А то могут и при помощи камеры на мобильнике. Ну подумаешь, не в фокусе немного.