В новых версиях библиотеки libpng 1.0.64, 1.4.17, 1.2.54, 1.5.24 и 1.6.19 (http://sourceforge.net/p/png-mng/mailman/message/34615043/) устранена (http://www.openwall.com/lists/oss-security/2015/11/12/2) уязвимость (https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8126) (CVE-2015-8126), которая может привести к переполнению буфера при открытии специально оформленных PNG-файлов. Уязвимость может привести к краху приложений, использующих libpng, в том числе Firefox и Chrome.Проблема вызвана ошибкой сопоставления размера палитры с параметрами глубины цветности (bit_depth менее 8) в функциях png_set_tIME()/png_convert_to_rfc1123() и png_get_PLTE()/png_set_PLTE(), что можно использовать для чтения данных за пределами границы буфера и потенциально для записи вне буфера. Кроме того, приложения могут использовать данные о глубине цвета из блока IHDR для самостоятельного выделения памяти под палитру, в то время как libpng вернёт до 256 записей, даже если задана глубина цвета менее 8.
URL: http://www.openwall.com/lists/oss-security/2015/11/12/2
Новость: http://www.opennet.me/opennews/art.shtml?num=43330
Покажите рабочий пример этой уязвимости (эксплойт).
В любом hex-редакторе поправьте заголовок PNG файла с более-менее нормальной палитрой, выставив значение глубины цвета меньше 8.
> В любом hex-редакторе поправьте заголовок PNG файла с более-менее нормальной палитрой,
> выставив значение глубины цвета меньше 8.Повторяю просьбу: заделитесь готовым файлом, если у кого есть.
P.S.: Если я попрошу порно-фильм, ты тоже будешь советовать нарисовать его самостоятельно в hex-редакторе?
> P.S.: Если я попрошу порно-фильм, ты тоже будешь советовать нарисовать его самостоятельно в hex-редакторе?Если кто-то хочет есть, это не значит, что его должны кормить из ложки.
>> P.S.: Если я попрошу порно-фильм, ты тоже будешь советовать нарисовать его самостоятельно в hex-редакторе?
> Если кто-то хочет есть, это не значит, что его должны кормить из
> ложки.Порно-фильмы это не продукт питания. Ты что-то перепутал.
Работающий эксплоит свежей уязвимости - не предмет первой необходимости. Твоя аналогия хромает на обе ноги.
Порнофильм - не предмет первой необходимости.
А по никнейму и не скажешь
> Порнофильм - не предмет первой необходимости.А-а-а, вот они, те импотенты, которые голосуют за слежку в интернете!
А кому-то вполне достаточно своей второй половинки.
> А кому-то вполне достаточно своей второй половинки.(продолжу) Тем не менее, слежка не нужна.
> Работающий эксплоит свежей уязвимости - не предмет первой необходимости. Твоя аналогия
> хромает на обе ноги.Если бы работающий эксплойт был предметом первой необходимости, я бы вышел делать революцию. А так прошу по-хорошему: дай папиросочку, у тя брюки в полосочку.
> В любом hex-редакторе поправьте заголовок PNG файла с более-менее нормальной палитрой,
> выставив значение глубины цвета меньше 8.Простого PNG файла недостаточно, нужно еще приложение которое работает с палитрой, причем неосторожно.
К примеру, браузерам палитра не нужна, они запрашивают из libpng картинку сразу в RGB или RGBA так что там проблем нет, даже со старыми версиями libpng.
Он предложит тебе снять самому )))
>1.0.64, 1.4.17, 1.2.54, 1.5.24 и 1.6.19Ну ничего себе разброс поддерживаемых версий. Есть какие-то причины (ну кроме "так исторически сложилось") по которым нужно поддерживать столько разных версий, а не предложить ребятам с 1.0.х обновиться на версию из 21 века?
И это еще не все, уже готовят 1.7.x
Игого наблюдаем 6 активно обновляющихся веток:
https://sourceforge.net/projects/libpng/files/
>>1.0.64, 1.4.17, 1.2.54, 1.5.24 и 1.6.19
> Ну ничего себе разброс поддерживаемых версий. Есть какие-то причины (ну кроме "так
> исторически сложилось") по которым нужно поддерживать столько разных версий, а не
> предложить ребятам с 1.0.х обновиться на версию из 21 века?Потому что лицензия ZLIB, оттого libpng используют в каждом чайнике. Между версиями сильно ломалось API, поэтому приходится поддерживать версии для legacy.
Как ни крути, пять веток - от совсем запредельно.
Не поленись - сходи и сообщи им об этом. Вдруг они просто не догадываются, а тут ты весь такой в белом - придешь и всех их спасешь от сей злочастной судьбы.
>Как ни крути, пять веток - от совсем запредельно.[I] dev-db/postgresql
Available versions:
(9.0) 9.0.23-r1^t
(9.1) 9.1.19-r1^t
(9.2) 9.2.14-r1
(9.3) 9.3.10-r1
(9.4) 9.4.5-r1[I] dev-lang/python
Available versions:
(2.7) 2.7.10 ~2.7.10-r2 [M]~2.7.10-r3
(3.3) 3.3.5-r1 ~3.3.5-r2 [M]~3.3.5-r3(3.3/3.3m)
(3.4) 3.4.3 ~3.4.3-r2 [M]~3.4.3-r3(3.4/3.4m)
(3.5) ~3.5.0-r1 [M]~3.5.0-r2(3.5/3.5m)и на закуску
[I] sys-devel/automake
Available versions:
(1.4) 1.4_p6-r2
(1.5) 1.5-r2
(1.6) 1.6.3-r2
(1.7) 1.7.9-r3
(1.8) 1.8.5-r5
(1.9) 1.9.6-r4
(1.10) 1.10.3-r1
(1.11) 1.11.6-r1
(1.12) 1.12.6
(1.13) 1.13.4
(1.14) 1.14.1
(1.15) 1.15
В libpng бесит глобальный обработчик ошибок.
> В новых версиях библиотеки libpng 1.0.64, 1.4.17, 1.2.54, 1.5.24 и 1.6.19Обрубили бы ему лишние ветки, штоле...
>что можно использовать для чтения данных за пределами границы буфераПохожий баг я находил где-то в гноме (похоже что баг в gdk-pixbuf) https://bugzilla.gnome.org/show_bug.cgi?id=696331
Вот вам даже особая картинка для воспроизведения бага http://dump.bitcheese.net/files/yrufatu/bugtest2.png - 512 байт. Такой пнг файл можно легко из любой нормальной пнг картинки сделать, надо просто обрезать хвост этому файлу, например создать нормальный файл bugtest.png и потом dd if=bugtest.png of=bugtest2.png count=1
Засовываете эту png картинку в директорию с кучей других картинок, открываете каким-нибудь гномовским(гтк-шным) просмотрщиком картинок (eog, ristretto) и перелистываетесь между картинками в директории.
