forum.opennet.ru - "Уязвимость в libpng, приводящая к переполнению буфера при обработке PNG-изображений" (28)

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

Изначальное сообщение

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

"Уязвимость в 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ообщить модератору

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


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

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


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


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


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


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


	77. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Медведь (ok), 22-Ноя-25, 16:23
	> Историческая безграмотность это настоящая беда современной молодежи! Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было. Беда! > Язык программирования Си разрабатывался в период с 1969 по 1973 Ой, беда! > Бейсик был придуман в 1964 году преподавателями Дартмутского Колледжа Джоном Кемени и Томасом Курцем, и под их руководством был реализован командой студентов колледжа Ой, беда-беда! > Язык программирования Pascal был создан в 1970 году на основе языка Алгол-60. Беда, однозначно!
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору

19. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+3 +/–
Сообщение от Аноним (-), 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ообщить модератору

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


	52. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+1 +/–
	Сообщение от Аноним (-), 22-Ноя-25, 14:49
	> Никак язык это не характеризует. Ещё как! Идеальный инструмент для сокрытия бэкдоров. И, как показывает коммит, бэкдор из новости добавили, когда прятали предыдущий бэкдор. Цирк, да и только. А те, кто защищает этот макроассемблер - или сознательные саботажники, или полезные иди от ы.
	Ответить \| Правка \| К родителю #33 \| Наверх \| 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 +/–
	Сообщение от Аноним (87), 22-Ноя-25, 16:43
	>Но что-то не сильно помогает))) Я задавал вопрос, а как в сишке проверить отсутствие разыменноывания нулевого указателя. Мне дали аж целых два флага для gcc, и ни один из них не заработал. >Но используются ли они на постоянку при разработке на офф сайте и в README не сказано. Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют.
	Ответить \| Правка \| Наверх \| Cообщить модератору

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


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

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


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


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


	81. "Уязвимость в libpng, приводящая к переполнению буфера при об..."	+/–
	Сообщение от Аноним (87), 22-Ноя-25, 16:40
	Кошкажена - вот возьмите и как настоящий апологет сишки возьмите и посмотрите.
	Ответить \| Правка \| К родителю #49 \| Наверх \| Cообщить модератору


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


	91. Скрыто модератором	+/–
	Сообщение от Анонимусс (?), 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ообщить модератору

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

90. Скрыто модератором	+/–
Сообщение от Аноним (90), 22-Ноя-25, 18:30
Помянем арчеводов
Ответить \| Правка \| Наверх \| Cообщить модератору