В стандартной Си-библиотеке Glibc выявлена уязвимость (CVE-2024-2961), приводящая к переполнению буфера при преобразовании специально оформленных строк в кодировке ISO-2022-CN-EXT функцией iconv(). Выявивший проблему исследователь планирует 10 мая выступить на конференции OffensiveCon с докладом, в анонсе которого упоминается возможность эксплуатации уязвимости через приложения на языке PHP. Заявлено, что проблема затрагивает всю экосистему PHP и некоторые приложения...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61033
Си и PHP -- CVE-братья на век!
JS: Вы куда без меня? Нас же трое братьев!
Javascript is just C done well (c)
проблему изучал озабоченный php. если ты не озабочен, тебе волноваться не о чём
Самое смешное, что php тут вообще никаким боком, это просто удобный вектор атаки.
круто
Ну и почему нет расследования какой китаец на какой праздник что накоммитил? Где теории заговора где пяток новостей только про один этот случай с разными разборами и вычиткой каждого сообщения от автора коммита как в хз. Двойные стандарты и отрациние очевидного.
Очевидно, что iconv мало кто использует в php, а уж вместе с какойто конкретной экзотической кодировкой и подавно, так есть ли смысл в расследовании преступления которое случилось 20+ лет назад и заключалось в том, что в подвале не заперли на щеколду чулан
> Очевидно, что iconv мало кто использует в phpИ уж тем более очевидно, кто php-код НИКОГДА не работает с данными, которые ввёл пользователь.
ввел, а потом указал что ввел в какойто отличной от дефолтной кодировке, факт
Где вы берёте такую густую чушь?
Всё с вами пхпшниками ясно. И почему вас постоянно взламывают. Информационная безопасность и вы находитесь на разных полюсах.
Потому чтт если начать раскручивать, внезапно на серьёзных дядек моюно выйти и получить D-Notice?
Красивое.
>библиотека добавляет некоторые escape-символы, выделяющие части строки,Сомнительная функциональность, конечно, надо бы посмотреть, кто это добавлял, и не позаботился о сайд-эффектах.
Arch - https://security.archlinux.org/CVE-2024-2961 - "404: Not Found"
Пэхэпэ уже атакуют, не дождались?
В Arch'е CVE-2024-2961 пофиксили уже 3 дня назад: https://gitlab.archlinux.org/archlinux/packaging/packages/gl...
Проблема в том, что значительная часть пользователей Arch'а старается не обновлять систему, чтобы она не развалилась, а просто переставлять всё с нуля через какой-то период (что-то около полугода).
"Значительная часть" - это один ты и твой сосед?
"старается не обновлять систему, чтобы она не развалилась" РЖУ!!! :)))))
Это как же надо писать систему, чтобы вот так, от любого чиха....
Спроси виндузятников. У них каждая инструкция по исправлению проблем начинается с переустановки системы.
Когда сидел на Arch-е, обновлял постоянно, ничего не отваливалось. Ну один раз за 4 года отвалились иксы, поправил конфиг, всё ок.Переустанавливать линукс - это вообще что-то очень смешное, это надо быть совсем пользователем windows, чтобы до такого дойти. За 21 год на линуксе ни разу до такого не опускался :)
Было на работе пара любителей арча, раз в три месяца стабильно все нахер разваливалось, обновлялись раз в неделю. При у меня гента, с обновлениями раз в месяц мозги грела реже
Фиерический бред, вы там с вендой не перепутали?
Каждый день обновляюсь в течение десятков лет. Ничего не боюсь, ничего не разваливается.
> В Arch'е CVE-2024-2961 пофиксили уже 3 дня назад: https://gitlab.archlinux.org/archlinux/packaging/packages/gl...Допустим, из-за этого нужно сносить страницу? Это только в мире Арча видимо такое считается норм.
А она когдато была чтоб ее сносить?
Который раз уже замечаю, что в новостях о какой-то CVE, ссылка на федору ведёт на какую-то всратую страницу с рандомной свалкой всего что только можно, но не того что нужно.У Дебиана самая наглядная сводка статуса починки, сразу видно, что не инопланетные наркоты составляли.
> ссылка на федору ведёт на какую-то всратую страницу с рандомной свалкой всего что только можно, но не того что нужно.Федора — корпоративный продукт, соответственно, поиск по CVE в багзилле может быть ограничен, если этого пожелают сотрудники корпорации.
>> ссылка на федору ведёт на какую-то всратую страницу с рандомной свалкой всего что только можно, но не того что нужно.
> Федора — корпоративный продукт, соответственно, поиск по CVE в багзилле может
> быть ограничен, если этого пожелают сотрудники корпорации.Ага, а RHEL, у которой с сылкой всё нормально, стало быть не корпоративный продукт, а так, шляпа подзаборная, да?! ))
У Федоры ссылку хорошо б поправить на более детальный поиск https://bodhi.fedoraproject.org/updates/?search=Glibc&type=s...
Бхах! Сходил по ссылке :))) "Internal Server Error"
Какой дистрибутив - так и работает))))
Пробел и кавычки в конце ссылки лишние.
https://bodhi.fedoraproject.org/updates/?search=Glibc&type=s...
Ахаха, ой не могу!
+ if (outptr + 4 > outend) + {
+ result = __GCONV_FULL_OUTPUT;
+ break;
+ }
Дыряшечники опять не смогли посчитать размер буфера))
И получили "удалённой атаки на PHP-приложения, приводящей к выполнению кода."А прожила дырень с 2000 по 28 Mar 2024. Это 24 года!
Наверное популярность пыхи чуть подубавилась в пользу жс и го, вот и решили прикрыть.
Те, кому нужен правильный размер буфера, на Си не пишут.Достоинство Си — невероятная гибкость, позволяющая исполнять даже те области памяти, в которых изначально лежали данные.
> позволяющая исполнять даже те области памяти, в которых изначально лежали данные.О, так это же так называемое "динамическое расширение функционала программы".
Практически любая программа на си больше хеллоуволда может быть расширена выполнением стороннего кода.
Очень удобно, все радуются и пляшут.
Всё зависит от задачи. Иногда зайти в систему через "заднюю дверь" бывает полезно.Именно в таких случая целесообразно выставлять в сеть сервисы, написанные на Си и/или использующие сишные библиотеки.
То есть любой сетевой сервис на планете, получается. Потому что даже сервис на расте будет юзать сетевой стек, к-й написан на Си. Растофили, вы напишите уже наконец свой TCP/IP, да такой чтоб в линукс приняли и Линус средний палец не показал. Драйверы для все сетевых карт тоже придется напис^W переписать
Растофанатики напоминают борцов с изменением климата. Только говорят но реальной альтернативы предложить не могут.
Да написали уже давно. Но в Linux Линус его тащить не спешит.
> Да написали уже давно. Но в Linux Линус его тащить не спешит.даже целую ось, ресдох написали, только никто на нее бежать не спешит.
варвары.
Можно подумать хруст на этапе коньэпиляции узнает сколько данных прилетит в буфффер в _будущем_.
> Можно подумать хруст на этапе коньэпиляции узнает сколько данных прилетит в буфффер в _будущем_.Раст знает размер буфера. И при попытке записать больше программа упадет с логом.
Ситуация неприятная, т.к. может привести к DoS. Но не заметить ее невозможно.
И это намного лучше чем молча портить память 24 года.
> Раст знает размер буфера. И при попытке записать больше программа упадет с
> логом.угу, вот для примера CVE-2021-25900 (тысячи их), ржавый переписал память, и упал в SIGABRT. А уж какой там лог, ммм. Сразу видна рука безапастников.
> Ситуация неприятная, т.к. может привести к DoS. Но не заметить ее невозможно.
> И это намного лучше чем молча портить память 24 года.Как можно молча портить память и не крашнуться, если порча памяти крашит приложение?!
"An attacker could use this issue to cause the GNU C Library to crash, resulting in a denial of service, or possibly execute arbitrary code."
Впрочем, я разговариваю с растаманом. чой эт я.
> угу, вот для примера CVE-2021-25900 (тысячи их), ржавый переписал память, и упал в SIGABRT. А уж какой там лог, ммм. Сразу видна рука безапастников.Как то для других языков удается получить краш репорт с сигабртом, а тут не возможно?
Звучит слегка костыльно)> Как можно молча портить память и не крашнуться, если порча памяти крашит приложение?!
Неа, если бы ты был слегка умнее то знал, что в дыряше порча памяти может привести не только к крашу.
> or possibly execute arbitrary code."А вот и ответ!
Подумаешь, будет запуск кода, для любителей дыряшки это же не проблема.> Впрочем, я разговариваю с растаманом. чой эт я.
Да, чёй это ты? Показывал бы свою глупость хоть как-то получше, а то совсем скучно.
Все хоронят Пыху, а он живучий оказался. Если бы он не использовался, уязвимости бы не искали.
Хоронят программисты (так как что-то понимают),
а откапывают предприниматели (так как что-то понимают).Вот только одни понимают в программировании,
а другие понимают в экономике.Странно слушать мнение уборщицы о проведении полосных операций,
так что ну платят пока PHP-шникам за решение бизнес проблемы
и хорошо одни с решением, а другие с деньгами, но бегать и кричать
в грудь, что там все так прям хорошо я б не стал...
Он такой же живучий, как кувалда вместо шуруповёрта: есть тысячи леммингов, которые даже на 10% не смотрят вглубь - у них есть "простой инструмент" похапэха и желание на этом заработать. Остальные брезгливо смотрят на это трёхбуквенное недоразумение и не понимают, зачем эту плохо пахнущую кучу вообще касаться.
если приглядеться к ЯП и технологиям, применяемым в вебе, около него и во многом другом - то почти что угодно оказывается той самой кучей
Надо писать веб на языке Hack, как это делает Meta Platforms.
> Надо писать веб на языке Hack, как это делает Meta Platforms.это тот у которого реакт и реакт-натив ?
и это в стандартной либе, а что же творится в миллионах васянских либ
Да на тот же вордпресс посмотри и плагины к нему. Проще ssh порт оставить без пароля чем ставить все эти поделки.
> и это в стандартной либе, а что же творится в миллионах васянских либПроприетарный код недоступен для анализа.
>> и это в стандартной либе, а что же творится в миллионах васянских либ
> Проприетарный код недоступен для анализа.Доступен. Просто ты про не в курсе, какие варианты для этого возможны. А открытый код за тебя посмотрит Васян, да.
> Доступен.Варианты, которые не вписываются в экономику, существуют, в основном, лишь гипотетически, для победы в спорах в Интернетике.
Варианты, которые вписываются в жизнь, имеют ряд вопросов к надежности такого, поверхностного, анализа. Так как делают ряд серьезных допущений о предполагаемом поведении программ, например, о его постоянстве во времени или об его универсальности для любого окружения.> А открытый код за тебя посмотрит Васян
Кому платишь, тот и смотрит.
>> Доступен.
> Варианты, которые не вписываются в экономику, существуют, в основном, лишь гипотетически,
> для победы в спорах в Интернетике.Открытый код приведён в сообщении #103.
Вместо указания на очевидную ошибку, ты ответил демагогией.ЧИТД. Вариант "открыть сорцы и посмотреть глазами ... с этим может справиться даже студент" является гипотетическим.
> Проприетарный код недоступен для анализа.Любой бинарник доступен для анализа. Для этого даже код не нужен.
А вот сложность этого анализа для открытых и проприетарных приложений отличается на порядки.В первом случае тебе нужно просто открыть сорцы и посмотреть глазами, натравить на них анализаторы, можно скомпилять и запустить фаззинг. У тебя есть хоть какое-то описание логики в виде документации, комментариев и названий функций/переменных. С этим может справиться даже студент.
Во втором случае тебе нужно дизассемблить исполняемый файл и ковыряться в асме/байткоде. Дока будет в лучше случае в виде описания публичных функций библиотеки. И разбираться в логике уже самому.
Для этого нужно уже быть как минимум хорошим разработчиком с опытом в данной сфере.Уверен что у всех разведок мира (ну, серьезных), есть отделы, которые без особых сложностей анализируют и собирают дырени в опенсорсе. Но вот только никуда не репортит))
Можно конечно возразить, что некоторые проприетарщики тоже предоставляют код. Но это происходит.
>> Проприетарный код недоступен для анализа.
> Любой бинарник доступен для анализа.Защищённый DRM с SGX-аттестацией (заливается общий анклав, выполняющий произвольный код в анклаве, анклав аттестуется, после аттестации по сети в него передаётся бинарник, остальная система его читать не может, так как он расшифровывается только в самом процессоре, а в физической DDR-5-оперативе хранится в зашифрованном виде, ключ известен только процессору) - недоступен.
> Защищённый DRM с SGX-аттестациейСова просто лопается от ваших попыток натянуть ее на глобус.
Давайте тогда еще возьмем бинарник для закрыкой архитектуры проприетарного проца, который не доступен никому.
Тоже оооочень жизненный вариант.Но даже если взять ваш пример - то всё тоже возможно. Просто намного дороже))
en.wikipedia.org/wiki/Software_Guard_Extensions#List_of_SGX_vulnerabilities
> В первом случае тебе нужно просто открыть сорцы и посмотреть глазами, натравить
> на них анализаторы, можно скомпилять и запустить фаззинг. У тебя есть
> хоть какое-то описание логики в виде документации, комментариев и названий функций/переменных.
> С этим может справиться даже студент.Проверим гипотезу практикой?
Как раз из glibc
#define internal_syscall4(v0_init, input, number, arg1, arg2, arg3, \
arg4) \
({ \
long int _sys_result; \
\
{ \
__syscall_arg_t _arg1 = ARGIFY (arg1); \
__syscall_arg_t _arg2 = ARGIFY (arg2); \
__syscall_arg_t _arg3 = ARGIFY (arg3); \
__syscall_arg_t _arg4 = ARGIFY (arg4); \
register __syscall_arg_t __s0 asm ("$16") __attribute__ ((unused))\
= (number); \
register __syscall_arg_t __v0 asm ("$2"); \
register __syscall_arg_t __a0 asm ("$4") = _arg1; \
register __syscall_arg_t __a1 asm ("$5") = _arg2; \
register __syscall_arg_t __a2 asm ("$6") = _arg3; \
register __syscall_arg_t __a3 asm ("$7") = _arg4; \
__asm__ volatile ( \
".set\tnoreorder\n\t" \
v0_init \
"syscall\n\t" \
".set\treorder" \
: "=r" (__v0), "+r" (__a3) \
: input, "r" (__a0), "r" (__a1), "r" (__a2) \
: __SYSCALL_CLOBBERS); \
_sys_result = __a3 != 0 ? -__v0 : __v0; \
} \
_sys_result; \
})Ошибка очевидна и описана в книжках для студентов. Тысячеглаз смотрел лет 20, пока она кое-где не всплыла. Но тут то дажестуденты точно разглядят?
Куда же пропали эксперты? Если ответа не будет, на местом "сообществе" анализаторов следует ставить крест, а распространителей мантры про Тысячеглаза записать в пустозвоны.
#define internal_syscall4(v0_init, input, number, arg1, arg2, arg3, arg4) \
({ \
long int _sys_result; \
\
{ \
__syscall_arg_t _arg1 = ARGIFY(arg1); \
__syscall_arg_t _arg2 = ARGIFY(arg2); \
__syscall_arg_t _arg3 = ARGIFY(arg3); \
__syscall_arg_t _arg4 = ARGIFY(arg4); \
register __syscall_arg_t __s0 asm("$16") __attribute__((unused)) \
= (number); \
register __syscall_arg_t __v0 asm("$2"); \
register __syscall_arg_t __a0 asm("$4") = _arg1; \
register __syscall_arg_t __a1 asm("$5") = _arg2; \
register __syscall_arg_t __a2 asm("$6") = _arg3; \
register __syscall_arg_t __a3 asm("$7") = _arg4; \
__asm__ volatile(".set\tnoreorder\n\t" v0_init "syscall\n\t" \
".set\treorder" \
: "=r"(__v0), "+r"(__a3) \
: input, "r"(__a0), "r"(__a1), "r"(__a2) \
: __SYSCALL_CLOBBERS); \
_sys_result = __a3 != 0 ? -__v0 : __v0; \
} \
_sys_result; \
})
5.1.1.2 Translation phases2. Each instance of a backslash character (\ ) immediately followed by a new-line character is
deleted, splicing physical source lines to form logical source lines. [...]
> следует ставить крест, а распространителей мантры про ТысячеглазОднако, обсуждаемую уязвимость нашел не ты, а Тысячеглаз. 0:1 в его пользу.
Я понимаю, что ты не способен увидеть очевидную проблему с кодом выше, но оправдаться хоть как-то очень хочется - примечательно, что за чужой счёт.
Серьёзные ничего не анализируют. Серьёзные вставляют сразу в код всё что нужно. Посмотри то же последнее интервью Дурова.
А меня защищает SELinux.
Какие ещё приложения так можно поиметь? Firefox можно?
Прикольно.
23+ года в одной и самых распространенных и важных либ была дырка.
Но тыщщи глаз смотрели куда угодно, но только не туда куда нужно.
И потребовался целый security researcher, чтобы найти обычный классический buffer overflow.
Ну бесплатно работать не все любят. Особенно те, кто могут работать платно за большой прайс на АНБ.
Ты абсолютно не представляешь себе процесс поиска уязвимостей. Это сродни поиска клада - ищут сотни, находит один. Потом в новостях пишут только про того, который нашел, естественно не упоминая про остальных 99, которым не повезло.>Но тыщщи глаз смотрели куда угодно, но только не туда куда нужно
Если ты знаешь "куда нужно" смотреть, срочно иди в security researcher - станешь знаменитым и богатым.
> Ты абсолютно не представляешь себе процесс поиска уязвимостей.Ну да, ну да))
> Это сродни поиска клада
Скорее сродни ковырянию в большой зловонной куче.
> ищут сотни, находит один
Покажи, пожалуйста, какую из последних узявимостей нашел васян из "Сообщества", а не профи на зп у какой-то фирмы. Предыдущую благодарочку нужно сказать челу из майкрасофта.
Минтачку, а Вы думали что Васян и профи на зарплате - два разных человека??
>> ищут сотни, находит один
>нашел васян из "Сообщества", а не профи на зп у какой-то фирмыРазве я где-нибудь сказал, что сотни - это васяны из "Сообщества"? Я как раз имел ввиду сотни профессионалов.
>> Ты абсолютно не представляешь себе процесс поиска уязвимостей.
>Ну да, ну да))Ты еще раз подтвердил полную некомпетентность в вопросе.
> Разве я где-нибудь сказалКроме как говорить, нужно еще читать уметь. Перечитай первое сообщение треда
> Я как раз имел ввиду сотни профессионалов.
Сотни "профи" пока что программировали glibc.
> Ты еще раз подтвердил полную некомпетентность в вопросе.
Конечно!
А ты показываешь свою просто невероятною компетентность в этом вопросе))
Есть уязвимости, которые прям специально ищут (типа выход из контейнера), а есть на которые случайно натыкаются в малозначимых функциях (типа перевести число в строку). Так или иначе, FOSS просто априори кишит этими дырами.
порой дыры отыскивают, исследуя не совсем ожидаемое поведение кода, а то и вылет, хотя вроде бы вылетать не должно
Потому что код и алгоритмы были очень "хорошими", "простыми" и "не замороченными"
Да может этот код ВПЕРВЫЕ прогнали через какую-нть PVS-studio - вот и нашёлся кусочек халтуры.
Хорошо что есть PHP - есть на кого спихнуть проблемы в glibc и iconv
24 года уязвимости. А как же миллионы глаз, как же сообщество GNU-тых людей? Как же поклонение GPL и Столлману?
Так нашли же
Через 24 года? Я практически уверен, что товарищ майор нашёл это гораздо раньше сообщества.
Да не факт! Бывают же и "просто уязвимости" :))) Сам же понимаешь - FOSS - это на 90% дилетанты разного уровня и только 5% реальных профи, которым скучно "прибивать дома полочку" и они пишут для народа.
> Да не факт! Бывают же и "просто уязвимости" :)))Какая разница, просто не просто? В соответствующих органах такие "просто уязвимости" целенаправленно ищут и вовсе не для того чтобы их исправить или сообщить авторам.
> Сам же понимаешь - FOSS - это на 90% дилетанты разного уровня и только 5% реальных профи, которым скучно "прибивать дома полочку" и они пишут для народа.
Это уже давно не так. FOSS - это почти целиком и полностью корпоративная разработка профессионалами. Другое дело, что в FOSS может оставаться старый код, бородатых столлманутых времён. В частности GLIBC - это помойка старого плохо читаемого и поэтому трудно поддерживаемого кода.
Миллионы глаз только смотрят, чтобы софт был нахаляву :)) А код - ну кому интересно его проверять?! Тем более в таких "малоинтересных" вещах типа конвертеров. Такие уязвимости находят в очень маргинальных случаях, когда чел реально очень плотно работает с чем-то и натыкается на "странности", которые дилетант с лёгкой руки хардкодит в продакшен.
Я подготовил исправление для EL9 в рамках Rocky Linux SIG/Security:
https://sig-security.rocky.page/packages/glibc/
https://sig-security.rocky.page/issues/CVE-2024-2961/
О том как этот репозиторий подключить на Rocky Linux или других производных от RHEL9 дистрибутивах, написано на корневой странице этого wiki.
так что, теперь меня взломают? как от это защититься?
почему именно теперь?
Всегда!
Пользуйтесь дистрибутивами с SELinux.
Лучшая защита - это нападение