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

"Уязвимость в libpng, приводящая к переполнению буфера при обработке PNG-изображений"	+/–
Сообщение от opennews (??), 22-Ноя-25, 11:12
В корректирующем выпуске библиотеки libpng 1.6.51, применяемой в качестве прямой зависимости у около 600 пакетов в Ubuntu, устранены 4 уязвимости, одна из которых (CVE-2025-65018) приводит к записи за границу буфера. Потенциально данная уязвимость позволяет добиться выполнения своего кода при обработке специально оформленных файлов в формате PNG... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64305
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+2 +/–
Сообщение от Аноним (1), 22-Ноя-25, 11:12
Обещали же в файрфоксе все эти парсеры в васм скомпилровать. RLBox.
Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–3 +/–
	Сообщение от Аноним (-), 22-Ноя-25, 16:27
	> Обещали же в файрфоксе все эти парсеры в васм скомпилровать. Чтобы тормозило и жрало память еще и это? Файрфокс и так после открытия нескольких вкладок начинает дико якорить уже.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–2 +/–
	Сообщение от Аноним (111), 23-Ноя-25, 01:51
	Да, тут писали. Вейланд так течёт, что там не только Фаерфокс, а даже курсор через некоторое время якорить начинает.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (132), 23-Ноя-25, 18:21
	>Вейланд так течёт Опять ыксперды лгут.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от morphe (?), 22-Ноя-25, 19:59
	RLBox сложнее Код сначала компилируют в WASM, а затем WASM превращают в C код с сохранением гарантий безопасности, проверок и изоляции WASM рантайма
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	128. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+2 +/–
	Сообщение от Смузихлеб забывший пароль (?), 23-Ноя-25, 14:06
	Васм в сишку не превращают ибо сие глупость. Вот наоборот - вполне > Механизм работы RLBox сводится к компиляции C/C++ кода изолируемой библиотеки > в низкоуровневый промежуточный код WebAssembly, который затем оформляется > в виде WebAssembly-модуля, полномочия которого задаются в привязке > только к этому модулю > Преобразование кода C/C++ в WebAssembly осуществляется при помощи wasi-sdk. > Для непосредственного выполнения WebAssembly-модуль компилируется в машинный код > при помощи компилятора Lucet и выполняется в отдельном "нанопроцессе", > изолированном от остальной памяти приложения. > Компилятор Lucet основан на том же коде, что и JIT-движок Cranelift, > применяемый в Firefox для выполнения WebAssembly. https://www.opennet.dev/opennews/art.shtml?num=52440
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от morphe (?), 23-Ноя-25, 21:29
	> https://www.opennet.dev/opennews/art.shtml?num=52440 Не используется для rlbox jit, у него есть несколько бекендов, и в лисе применяется бекенд wasm2c, который именно что компилирует wasm в C: https://rlbox.dev/chapters/tutorial/wasm-sandbox.html
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Смузихлеб забывший пароль (?), 24-Ноя-25, 07:07
	т.е они преобразуют Си в васм, потом преобразуют васм в Си и потом... потом компилируют ?) Хоспаде, как же хорошо, что свалил с лисы. У них столько всего недоделано или могло бы быть сделано, вместо этого - они, при сильно ограниченных ресурсах, занимаются "вот этим вот" Хотя, покопаться на досуге в сабже было бы интересно
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от morphe (?), 24-Ноя-25, 10:56
	> т.е они преобразуют Си в васм, потом преобразуют васм в Си и > потом... потом компилируют ?) И это получается намного надёжнее всех имеющихся санитайзеров, да. Сам такое применяю в Rust проекте использующем xmlsec. Производительность затрагивает незначительно, однако больше не нужно доверять коду этой библиотеки, который далеко не лучшего качества и плохо документирован После перевода в rlbox даже обнаружил что я неправильно понял работу пары методов и получал use after free, с которыми сишная версия чудесным образом продолжала работать, а rlbox ловил ошибку
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от morphe (?), 23-Ноя-25, 21:32
	> при помощи компилятора Lucet и выполняется в отдельном "нанопроцессе", С момента публикации новости прошло 5 лет, никакой lucet в rlbox давно не применяется, да и вообще он мёртвый > Lucet has reached end-of-life, and maintence has ceased. All Lucet users should transition to Wasmtime.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	94. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (-), 22-Ноя-25, 20:01
	Зачем кому-то переполнять чужой буфер? Вот в чем вопрос...
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

6. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–15 +/–
Сообщение от Аноним (6), 22-Ноя-25, 11:41
Эти ошибки - результат эры PC. До PC все писали на басике и паскале и не парились. Потом пришли ребята, которые сказали, надоело системые проги на асме катать. Давайте изобретем си. Вот и изобрели себе на голову. А писали бы на басике, проблем бы не знали.
Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Аноним (12), 22-Ноя-25, 12:18
	так современный аналог бейсика это питон/js
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–4 +/–
	Сообщение от Аноним (35), 22-Ноя-25, 13:57
	Историческая безграмотность это настоящая беда современной молодежи! Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	43. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+11 +/–
	Сообщение от Аноним (43), 22-Ноя-25, 14:28
	> Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было. Тем временем в нашей вселенной: язык программирования Pascal был создан в 1970.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+7 +/–
	Сообщение от Аноним (68), 22-Ноя-25, 15:40
	Про бейсик даже упоминать боязно, но всё же — 1964 год.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от 1 (??), 22-Ноя-25, 21:52
	ну если под PC понимать IBM PC -- то это 1981 года, а если более широкое толкование The personal computer (PC) era began in the mid-1970s with the invention of the microprocessor, leading to the first commercially successful personal computers like the Altair 8800 in 1974. Mass production of pre-assembled PCs started in 1977 with the introduction of the Apple II, Tandy TRS-80, and Commodore PET. The industry then flourished in the 1980s with the launch of machines like the IBM PC and Apple Macintosh, making computers accessible to individuals and businesses.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	107. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (107), 22-Ноя-25, 23:31
	Так разве проблема не возникнет и при написании на ассемблере? Так же возникнет. Проблему тут решит язык в котором работа к буфером возможна только по средствам API, который проверяет границы. На сколько я знаю только два языка такое могут и не поддерживают в чистом виде указатели.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

19. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+7 +/–
Сообщение от Аноним (-), 22-Ноя-25, 12:51
Шикарная новость! С одной стороны ничего нового, типиkaл си код. Но один пикантный момент в новости упустили - этой dыpeни уже почти десять лет :) Была добавлена в январе 2016 в коммите Simplified API: write-to-memory, overflow handling [1], в котором исправляли ДРУГИЕ проблемы с переполнениями при обработке изображений. /* Now check for overflow of the image buffer calculation; this * limits the whole image size to 32 bits for API compatibility with * the current, 32-bit, PNG_IMAGE_BUFFER_SIZE macro. */ Pathetic)) И почти десять лет выполнения стороннего кода при обработке специально оформленных файлов в огромном количестве пакетов! Все это время проблема оставалась незамеченной. Тыщща глаз смотрела куда-то не туда. Добавил это в уточнение в новость, но не уверен что пропустят. Поэтому продублирую тут чтобы порадовать всех)) [1] github.com/pnggroup/libpng/commit/175a126a1a9ecb8ffb26882f5fc0b509fecc656a
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
Сообщение от Аноним (22), 22-Ноя-25, 13:04
Странная ошибка. Попытка заюзать такую в реале должна быть винда на экране: либо будет специально-скрафченный корявый ввод при просмотре 16-RGB, либо получится корявый вывод 8-RGBA. Ну или забыли только про это одно место, а вывод трансформируется где-то ещё (и тогда вопрос - а было ли переполнение)
Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Анонимусс (-), 22-Ноя-25, 15:38
	> либо будет специально-скрафченный корявый ввод при просмотре 16-RGB, > либо получится корявый вывод 8-RGBA. А уже не важно что будет на экране - подумаешь, битое изображение - главное что сторонний код уже успеет выполниться. И выполнится он с правами процесса запустившего либу. Рута там надеюсь не будет, но прошерстить и отправить все что нужно куда нужно оно вполне сможет.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (121), 23-Ноя-25, 06:39
	>сторонний код уже успеет выполниться. Ничего там не выполнится, просто данные запортятся.
	Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
Сообщение от бсдшник (-), 22-Ноя-25, 13:12
Кстати забавно, если открыть страничку FreeBSD из новости (vuxml.org/freebsd/pkg-png.html), то там есть очень классная табличка 2015-11-15     libpng buffer overflow in png_set_PLTE 2015-01-05     png -- heap overflow for 32-bit builds 2012-04-08     png -- memory corruption/possible remote code execution 2010-06-28     png -- libpng decompression buffer overflow 2010-04-20     png -- libpng decompression denial of service 2008-04-25     png -- unknown chunk processing uninitialized memory access 2007-10-11     png -- multiple vulnerabilities 2007-05-16     png -- DoS crash vulnerability 2004-08-04     libpng stack-based buffer overflow and other code concerns 2004-05-02     libpng denial-of-service Что какбЭ в полной мере характеризует качество кода этой либы и йазычка, на которой она написана.
Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+2 +/–
	Сообщение от Аноним (33), 22-Ноя-25, 13:54
	Никак язык это не характеризует.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (43), 22-Ноя-25, 14:32
	В любой более-менее популярной софтине на Си постоянно находят десятки CVE из-за ошибок с памятью, что как бы намекает на качество языка.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Аноним (115), 23-Ноя-25, 04:42
	Как наличие ошибок в коде влияет на качество языка? Где ты здесь нашел прямую зависимость?
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (132), 23-Ноя-25, 18:32
	>Как наличие ошибок в коде влияет на качество языка? Где ты здесь нашел прямую зависимость? Зависимость строго обратная: качество языка влияет на количество ошибок.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (122), 23-Ноя-25, 07:48
	может не языка, а архитектуры неймана?
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	127. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Мемоним (?), 23-Ноя-25, 12:18
	Языка, слишком буквально реализующего архитектуру Неймана
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (132), 23-Ноя-25, 18:31
	Языка. Других архитектур мы как-то не наблюдаем.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	52. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+3 +/–
	Сообщение от Аноним (-), 22-Ноя-25, 14:49
	> Никак язык это не характеризует. Ещё как! Идеальный инструмент для сокрытия бэкдоров. И, как показывает коммит, бэкдор из новости добавили, когда прятали предыдущий бэкдор. Цирк, да и только. А те, кто защищает этот макроассемблер - или сознательные саботажники, или полезные иди от ы.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	92. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Советский инженер (ok), 22-Ноя-25, 19:44
	зато компилируется быстро. что еще надо !?
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+3 +/–
	Сообщение от Аноним (132), 22-Ноя-25, 21:32
	Не надо на си наговаривать, компиляция на си прекрасно затягивается https://www.opennet.dev/opennews/art.shtml?num=56449 Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (103), 22-Ноя-25, 22:27
	В расте и медленно компилироваться будет, и память жрать, и бэкдор из cargo прилетит. Если бы было по-другому, то закопали бы не просто язык, а его авторов живьём.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	116. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+2 +/–
	Сообщение от Аноним (115), 23-Ноя-25, 04:44
	Забыл написать про человеческий фактор, что большинство растеров постоянно расчитывают на волшебный компилятор, который должен за них ошибки ловить, ибо своей головы, как правило, у растеров нет.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-25, 08:08
	> большинство растеров постоянно расчитывают на волшебный компилятор, который должен за них ошибки ловить, ибо своей головы, как правило, у растеров нет. Почему вы пользуетесь транспортом - своих ног у вас нет? Почему вы пользуетесь вилкой и ложкой - у вас нет рук? А ногти как укорачиваете - зубами грызёте или используете ножницы/книпсеры? Может у растохейтеров и есть голова, но такое впечатление, что логике вас обучало стадо бабуинов.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-25, 17:13
	> ибо своей головы, как правило, у растеров нет. Ну так выкинь компьютер и считай в уме. А тексты пиши ручками на бумажке, принтер "не нужон". Подозреваю что подобные в 80х так же бухтели "зачем вам СИ?! настоящий программист пишет на ассемблере".
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	138. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Советский инженер (ok), 23-Ноя-25, 21:00
	> Подозреваю что подобные в 80х так же бухтели "зачем вам СИ?! настоящий > программист пишет на ассемблере". в контексте бареметал ємбеда я такое слышал и 2005
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Дед100лет (?), 24-Ноя-25, 11:46
	Насколько я помню, в начале тех самых 80х, когда я писал код для БЭСМ6, был совершенно другой контекст. Компьютеры считались большими числодробилками. Потому код писали или на макроассемблере, или на Фортране. Потом еще появился FOREX, который на самом деле был Fortran 77. Все остальное: Альфа, Алголы-Паскали и прочее - считались второстепенными и никто на них не обращал серьезное внимание. Системный код писался на макроассемблере, а прикладой код в основном писали сами пользователи - даже самый бородатый физик или инженер шел и учил Фортран, потом учился собирать колоду перфокарт, потом гонял своего Рунге-Кутта. Так что появление C на горизонте никого не впечатлило ни разу. Кстати, первый компилятор C для не-PDP и который мог выдавать что-то, что после дизассемблирования не вызывало тошноты, был TopSpeed C. А к тому моменту поезд давно ушел и бухтеть было уже некому. Вот переход с FoxPro и Clarion на SQL - вот тут да, народ по курилкам страдал и возмущался. Типа "это же лишняя прослойка! будет медленно!", или "как я буду чинить сломанную базу? кто там разберет, что и как оно пишет!" (тогда было модно выделять целый диск под базу и файлового доступа просто не было). Очень похоже на битву йокодзун Rust vs С++
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	119. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Аноним (119), 23-Ноя-25, 06:13
	> В расте и медленно компилироваться будет, и память жрать, и бэкдор из cargo прилетит. Ложь по каждому пункту. > Если бы было по-другому, то закопали бы не просто язык, а его авторов живьём. Уууу, какой ты грозный закапыватель.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	149. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Bottle (?), 24-Ноя-25, 14:23
	Самое смешное, что этот макроассемблер обладает неопределённым поведением, то есть он не является по-настоящему низкоуровневым. Никакое действие не гарантирует точный результат, в отличие от машинных кодов.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	87. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (132), 22-Ноя-25, 17:09
	>https://repology.org/project/libpng/cves >Too many CVEs found for this project, limiting to latest 200. Так что список будет куда обширние.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	97. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (97), 22-Ноя-25, 21:24
	В других либах на Си такой фигни нет, просто libpng пишут индусы.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	99. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–2 +/–
	Сообщение от Аноним (132), 22-Ноя-25, 21:33
	Главное в новости про libpng не вспоминать про xorg, в новости про xrog не вспоминать про линукс, и так далее.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (-), 22-Ноя-25, 23:25
	> В других либах на Си такой фигни нет Ну да, ну да, "это просто неправильная либа попалась" (с) А потом куда не ткни - одни и те же дыpы))) И примера правильной никто упорно предоставить не хочет. Или не может?
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	124. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (-), 23-Ноя-25, 10:10
	Есть и массово. Даже на opennet большинство новостей о уязвимостях - проблемы с памятью связанные с си. Корпорации не просто так переходят массово на rust.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	117. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Аноним (115), 23-Ноя-25, 04:46
	А ты не знал, что исправление одной ошибки может привести к другим ошибкам?
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

49. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
Сообщение от Кошкажена (?), 22-Ноя-25, 14:42
В разработке этой библиотеки используются статические анализаторы и санитайзеры?
Ответить | Правка | Наверх | Cообщить модератору

	55. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Анонимусс (-), 22-Ноя-25, 14:56
	> В разработке этой библиотеки используются статические анализаторы Используют. "A Coverity project for libpng is at scan.coverity.com/projects/4061. The project is set up to scan the head of each of the libpng10 through libpng17 branches" [1] И текущая libpng16 в него включена. Но что-то не сильно помогает))) > и санитайзеры Как минимум часть багов нашли с из помощь [2]. Но используются ли они на постоянку при разработке на офф сайте  и в README не сказано. Скорее всего нет, патамушта диды и так пишут код на отлично! [1] libpng.sourceforge.io [2] github.com/pnggroup/libpng/issues/275
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (132), 22-Ноя-25, 16:43
	>Но что-то не сильно помогает))) Я задавал вопрос, а как в сишке проверить отсутствие разыменноывания нулевого указателя. Мне дали аж целых два флага для gcc, и ни один из них не заработал. >Но используются ли они на постоянку при разработке на офф сайте  и в README не сказано. Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 22-Ноя-25, 17:49
	> Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют. Если хлеб в магазине не прикручен скотчем к колбасе, бутерброд ты никогда не сделаешь. Инфа сотка!
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (132), 22-Ноя-25, 18:16
	Ну вот покажите мне, где в libpng используется этот самый анализатор. И да, почему сишные проверки ломаются от рефакторинга?
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (-), 22-Ноя-25, 23:04
	>> Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют. > Если хлеб в магазине не прикручен скотчем к колбасе, бутерброд ты никогда не сделаешь. Отличная анал-огия! Почти такая же крутая как котенок с дверцей. Еще раз по буквам "если статический анализатор не включён в обязательные сборочные зависимости" значит: - его использование не обязательно и какой-то процент программеров просто не будет заморачиваться - каждый будет лепить свой анализатор с уникальными настройками - спрашивать "а проходить ли CI перед коммитов" думаю бесполезно))
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	108. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 22-Ноя-25, 23:37
	Очень непохоже, чтоб использовали. CppCheck нашел вот такой забавный код, к примеру (pngimage.c:787): static void display_cache_file(struct display *dp, const char *filename)    /* Does the initial cache of the file. */ {    FILE *fp;    int ret;    dp->filename = filename;    if (filename != NULL)    {       fp = fopen(filename, "rb");       if (fp == NULL)          display_log(dp, USER_ERROR, "open failed: %s", strerror(errno));    }    else       fp = stdin;    ret = buffer_from_file(&dp->original_file, fp);    fclose(fp);    if (ret != 0)       display_log(dp, APP_ERROR, "read failed: %s", strerror(ret)); } Тут сразу несколько явных глюков, имхо, и я в шоке от качества кода, будто школьник писал %)
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	109. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (109), 23-Ноя-25, 00:59
	> CppCheck нашел А что говорит? fclose(stdin)? В display_log там longjmp.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Медведь (ok), 23-Ноя-25, 02:11
	Куда конкретно ткнул cppcheck, я честно говоря, пребывая в восторге от кода, не запомнил :) Я не рыл display_log, но подозревал нечто этакое, хотя такой способ аварийного выхода, мягко говоря, неочевиден, деятель хотя бы функцию назвал подобающе. Но да, fclose(stdin) -- отличный косяк! Да и засовывание filename в dp->filename вызывает вопросы... P.S. Да, ткнул вот сюда: else       fp = stdin;    ret = buffer_from_file(&dp->original_file, fp);    fclose(fp);
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (132), 23-Ноя-25, 18:26
	>Куда конкретно ткнул cppcheck, я честно говоря, пребывая в восторге от кода, не запомнил :) Ну так ещё раз запусти >но подозревал нечто этакое, хотя такой способ аварийного выхода, мягко говоря, неочевиден Это логирование, как очевидно из названия >Но да, fclose(stdin) -- отличный косяк! В чём проблема? >Да и засовывание filename в dp->filename вызывает вопросы... А куда засовывать?
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 24-Ноя-25, 16:01
	> Это логирование, как очевидно из названия А вот хренушки там. > В чём проблема? Ну, погугли хотя бы, что ли.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (132), 24-Ноя-25, 17:37
	>Ну, погугли хотя бы, что ли. Что именно? Насколько мне известно, те же демоны спокойно закрывают свои потоки ввода-вывода, для того, чтобы не зависить от терминала.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 24-Ноя-25, 19:25
	>>Ну, погугли хотя бы, что ли. > Что именно? Насколько мне известно, те же демоны спокойно закрывают свои потоки > ввода-вывода, для того, чтобы не зависить от терминала. А это разве демон? Тут как минимум нужна железная уверенность, что stdin не дернется нигде и никем после этого.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (132), 23-Ноя-25, 01:02
	>CppCheck нашел вот такой забавный код, к примеру (pngimage.c:787): Вы неправильно вставили ссылку, нужно и коммит и полный путь к файлу https://github.com/pnggroup/libpng/blob/1ebf432e85b53bf111a4... >Очень непохоже, чтоб использовали. Вам говорили, что 99.99% проектов его не используют, а вы не верили. Ну что, убедились? >CppCheck нашел вот такой забавный код Забавный чем? Во-первых у сишников абсолютно весь код забавный, а во-вторых даже документация не позволяет определить, что будет, если функции передать null. >Тут сразу несколько явных глюков А вот и не факт. Вы в своё время усердно меня убеждали, что возможность разыменнования нулевого указателя - это хорошо, и что с этим ничего делать не надо. >и я в шоке от качества кода, будто школьник писал Писал настоящий сишник, сишнее не бывает. И в отличии от вас, его код не просто попал в репозиторий но ещё и используется. И да, вы уже отправили патч?
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	112. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 23-Ноя-25, 01:59
	> Вы неправильно вставили ссылку, нужно и коммит и полный путь к файлу https://github.com/pnggroup/libpng/blob/1ebf432e85b53bf111a4... Это в contrib, не критично > Вам говорили, что 99.99% проектов его не используют, а вы не верили. Ну что, убедились? Безосновательное обобщение, пока что подтвержден 1 проект ) > А вот и не факт. Вы в своё время усердно меня убеждали, что возможность разыменнования нулевого указателя - это хорошо, и что с этим ничего делать не надо. Всё понимаю, поздно, выходные, но это галлюцинации, я такого не говорил. И там далеко не только с нулевым FILE* проблема. > Писал настоящий сишник, сишнее не бывает. Не знал, что говорю с экспертом по сишникам )) А вдруг он поддельный?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (132), 23-Ноя-25, 18:30
	>Безосновательное обобщение, пока что подтвержден 1 проект ) Продолжайте наблюдение, будут дальнейшие подтверждения >И там далеко не только с нулевым FILE* проблема. Постойте, но ведь алгебраические типы же нинужны, ровно как и ненулевые указатели! И потом, в сишке же исключений нет, и если fread не спровоцирует UB, то всё будет работать. >А вдруг он поддельный? Любой, кто пишет на си - настоящий сишник. Только вот тех, кто пишет на си без багов как-то подозрительно мало.
	Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
Сообщение от Аноним (132), 22-Ноя-25, 16:08
Дыроделы, ваше оправдание? Почему заведомо уязвимый код скомпилировался? Я конечно понимаю, что раст ненужон и всецело это поддерживаю, но почему это вы до сих пор, за более чем пятьдесят лет до сих пор не ввели нормальную проверку исходников во все свои дырочные проекты? Давайте подумаем, а как можно без ненжного раста превратить дырочные проекты в недырочные? >В 2006 году началась разработка микроядра третьего поколения, получившего название «seL4» >Верификация выполнялась с помощью языка Haskell https://ru.wikipedia.org/wiki/L4_(%D0%BC%D0&#...) Вы представляете, верификацию можно было делать ещё до появления ненужнораста! Ну что, дыркоделы, поднимайте руки, кто из вас может написать верификацию? Кто из вас знает хаскель, окамл, или любой другой пригодный для цели верификации язык?
Ответить | Правка | Наверх | Cообщить модератору

	85. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+3 +/–
	Сообщение от Анонимусс (-), 22-Ноя-25, 16:47
	> Вы представляете, верификацию можно было делать ещё до появления ненужнораста! А вы знаете сколько времени и денег потратили на эту верификацию? Скорее всего нет, раз пишите такое. Ядро L4 это 8,700 строк C и 600 строк ассемблера. В статье "seL4: Formal Verification of an OS Kernel" есть детали как проходила верификация. Она состояла из трех фаз: 1) упрощенная версия ядра дизайнилась и имплементилась на Хаскеле + писался фреймворк для верификации 2) написали abstract spec 3) имплементировали все ядро и провалидировали Общий размер пруфа - 200,000 строк Isabelle script - примерно в 20 раз больше чем кода на дыpяxe и асме. Теперь по времени - написание abstract заняло примерно 4 человеко-месяца - два человеко-года ушло на весь Haskell прототип (design, documentation, coding, testing) - на executable spec потратили всего лишь 2 человеко-месяца - начальная трансляция в С заняла 3 недели, а полная C implementation - 2 человеко-месяца - общие затраты на seL4-specific proof 11 человеко-лет При этом в процессе разработки и верификации было внесено около 300 изменений в abstract spec и 200 в executable spec. Около 50% изменений были из-за багов в алгоритмах или архитектуре. При этом оценка доказательства аналогичного ядра по такой же методологии - 6-8 человеко-лет. > Кто из вас знает хаскель, окамл, или любой другой пригодный для цели верификации язык? А кто из вас умеет проводить формальную верификацию?)) Вы даже правильно посчитать размер буфера, чтобы за границы не выходить, не в состоянии. ---------------------------------------------------------- Источник sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Аноним (132), 22-Ноя-25, 16:55
	>При этом оценка доказательства аналогичного ядра по такой же методологии - 6-8 человеко-лет. А куда спешим? Выше приводили, небольшой срез из freebsd >2004-05-02 Я думаю, что за более чем двадцать лет как-то бы уже успели. Особенно, если местные експерты бы вместо того, чтобы здесь строчить комметарии о ненужно раста взяли бы и все вместе принялись писать.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Анонимусс (?), 22-Ноя-25, 19:00
	> А куда спешим? В libpng v1.6.37 около 20K строк кода. Это больше чем в два раза чем SLOC в SE4L. Даже если предположить, что сложность верификации линейная (а это вот совсем не так в общем случае), то это 22+ человеко-года верификации)) Это раз. А два - сомневаюсь что в опенсорсе достаточно компетентных людей, чтобы ее провести. Это довольно редкие специалисты и чаще всего они заняты чем-то более полезным. Три - в статье выше приводились стоимость Common Criteria EAL6 certification - $10k за сточку кода, это примерно 200 лямов за декодинг только PNG картинок, для "6omжей из сообщества" неподъемная цена. И это по расценкам 2009го года! Поэтому мой вердикт - "без шансов")) > Особенно, если местные експерты бы вместо того, чтобы здесь строчить > комметарии о ненужно раста взяли бы и все вместе принялись писать. Редкий местный кексперт даже на си писать может. Основа местной тусовки это всякие oдmинчeги-башпортянщики.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (109), 22-Ноя-25, 20:49
	wuffs png уже есть. https://habr.com/ru/articles/751462 "Wuffs' assertion and bounds checking system is a proof checker"
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Кошкажена (?), 23-Ноя-25, 18:51
	> В libpng v1.6.37 около 20K строк кода. Это больше чем в два раза чем SLOC в SE4L. Зачем все верифицировать? Достаточно верифицировать алгоритм, думаю там сильно меньше кода. Хотя, конечно, времени тоже много займет.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	141. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-25, 21:57
	> Достаточно верифицировать алгоритм А почему достаточно верифицировать алгоритм? Разве где-то в алгоритме сказано что можно писать за границы буфера?)) Нет, это так сказать "маленький нюанс" реализации. > Хотя, конечно, времени тоже много займет. Фиг с ним с временем. Требования к надежности seL4 на порядкИ выше чем для декодера png. Да и не нужна такая надежность в прикладном софте. Если бы либа хотя бы падала при открытии "специально оформленных файлов" то этого уже было бы достаточно. Во-первых это бы сразу заметили - сложно не заметить что софтина упала)) Во-вторых это бы быстро исправили, потому что нормальная проверка что-то в логи бы записала (а не "приложение Х обратилось по адресу 0xC492B1" и было убито). И такого лога и возможно образце файла было бы более чем достаточно.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Кошкажена (?), 24-Ноя-25, 10:32
	> Да и не нужна такая надежность в прикладном софте. Ну да, именно поэтому в питон добавили hacl*.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (-), 24-Ноя-25, 11:47
	Вы реально сравниваете криптографию hacl с декодингом картиночек?)) Ну... тогда как бы вопросов больше нет. ЗЫ: забавно что работы над этим hacl были начаты после очередной уязвимости в SHA-3 opennet.ru/opennews/art.shtml?num=57953
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Кошкажена (?), 24-Ноя-25, 16:25
	> Вы реально сравниваете криптографию hacl с декодингом картиночек?)) > Ну... тогда как бы вопросов больше нет. Криптография - не прикладной софт?
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–2 +/–
	Сообщение от Аноним (132), 24-Ноя-25, 00:56
	>Достаточно верифицировать алгоритм Разрешаю, приступай. >Зачем все верифицировать? Всё - это что? Какую именно часть можно не верифицировать?
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	101. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–2 +/–
	Сообщение от Аноним (132), 22-Ноя-25, 21:43
	>Даже если предположить, что сложность верификации линейная (а это вот совсем не так в общем случае), то это 22+ человеко-года верификации)) А она там вообще хоть в каком-то виде есть? Хотя-бы в виде сегодняшнего коммита с самым-самым началом? >А два - сомневаюсь что в опенсорсе достаточно компетентных людей, чтобы ее провести. Вопрос не в компетентости, этому можно научится, вопрос в желании. Дыряшечники в первую очередь не желают. >$10k за сточку кода, это примерно 200 лямов за декодинг только PNG картинок Это если нанимать человека за зарплату. А если борцуны с растом соберутся хотя-бы со всего рунета, то могут написать это совершенно бесплатно. Вот задонатить аналогичную сумму точно не смогут, а написать - запросто. >Редкий местный кексперт даже на си писать может. Как минимум ProfessorNavigator скидывал свою поделку на крестах. И полезным делом бы занялся, и дурацких комментов тут меньше бы писал.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	118. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (115), 23-Ноя-25, 04:49
	Компилятор не может знать что хочет сделать программист. С чего ты взял, что компилятор должен все это фильтровать?
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	120. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-25, 06:21
	> Компилятор не может знать что хочет сделать программист. А зачем ты пользуешься таким глупым компилятором? Почему не взять тот, который хотя бы в 96% случаев понимает, чего хочет программист? > С чего ты взял, что компилятор должен все это фильтровать? С чего ты взял, что нет?
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 23-Ноя-25, 12:14
	> Почему не взять тот, который хотя бы в 96% случаев понимает, чего хочет программист? Это какой же?
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
	Сообщение от 1 (??), 24-Ноя-25, 14:56
	copilot
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 24-Ноя-25, 15:49
	> Компилятор не может знать что хочет сделать программист > Почему не взять тот, который хотя бы в 96% случаев понимает, чего хочет программист? > Это какой же? > copilot Внимание, copilot внезапно стал компилятором. Ну-ну... Ещё откровения будут сегодня?
	Ответить | Правка | Наверх | Cообщить модератору

76. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
Сообщение от Аноним (76), 22-Ноя-25, 16:19
А что в Андроиде?
Ответить | Правка | Наверх | Cообщить модератору

129. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	–1 +/–
Сообщение от Аноним (-), 23-Ноя-25, 16:38
github.com/pnggroup/libpng/security/advisories/GHSA-7wv6-48j4-hj3g > Attack Vector >   ... >   Application processes untrusted PNG files. В переводе на русский, сишные библиотеки не годятся для использования в реальном мире. github.com/pnggroup/libpng/issues/755 > Fixed in PR #757 ... > Crediting Claude Sonnet 4.5 by Anthropic Язычок настолько простой и понятный, что даже лучшие из сишников не могут исправить ошибку без помощи ИИ.
Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (-), 23-Ноя-25, 16:59
	> не могут исправить ошибку без помощи ИИ. А сам ИИ обучили на аналогичном открытом овнокоде. И будет он бракоделить также как и диды.
	Ответить | Правка | Наверх | Cообщить модератору

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

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