В библиотеке GDK-PixBuf (https://developer.gnome.org/gdk-pixbuf/), применяемой в GTK+ и Clutter для загрузки и обработки различных типов изображений, выявлены (http://blog.talosintelligence.com/2017/08/vuln-spotlight-mul...) две уязвимости, позволяющие организовать выполнение кода злоумышленника с правами текущего пользователя при обработке специально оформленных файлов в форматах TIFF (https://www.talosintelligence.com/vulnerability_reports/TALO...) (CVE-2017-2870 (https://security-tracker.debian.org/tracker/CVE-2017-2870)) и JPEG (https://www.talosintelligence.com/vulnerability_reports/TALO...) (CVE-2017-2862 (https://security-tracker.debian.org/tracker/CVE-2017-2862)).
Уязвимости в GDK-Pixbuf позволяют атаковать систему через такие приложения, как Chromium, Firefox, VLC и GNOME thumbnailer. Более того, применение GDK-Pixbuf в GNOME thumbnailer позволяет выполнить код в процессе автоматического построения пиктограмм с эскизами для новых файлов, т.е. для эксплуатации достаточно просмотреть список файлов в файловом менеджере GNOME, без явного открытия файлов пользователем. Также имеется возможность свершить атаку (https://www.opennet.me/opennews/art.shtml?num=45543) при открытии специально оформленной web-страницы в браузерах.
Первая уязвимость вызвана (https://www.talosintelligence.com/vulnerability_reports/TALO...) целочисленным переполнением в функции tiff_image_parse, которое при обработке специально оформленного файла в формате TIFF может привести к переполнению кучи. Опасность проблемы смягчает то, что она проявляется только при сборке библиотеки с флагом оптимизации "-O3", который редко применяется для финальных сборок.
Примечательно, что в коде библиотеки есть проверки на переполнение, но при использовании флага "-O3" компилятор (проверено в clang) относит (https://bugzilla.gnome.org/show_bug.cgi?id=770986) их к коду с неопределённым поведением ("Undefined Behavior") и удаляет как излишний код.
Вторая уязвимость связана (https://www.talosintelligence.com/vulnerability_reports/TALO...) возможностью инициирования переполнения кучи в функции gdk_pixbuf__jpeg_image_load_increment в процессе разбора некорректного JPEG-изображения. Проблема вызвана неправильным расчётом размера выходного буфера, который в дальнейшем используется при выполнении преобразования null_convert в libjpeg.Уязвимости устранены (https://git.gnome.org/browse/gdk-pixbuf/commit/?id=31a6cff) в выпуске GDK-Pixbuf 2.36.7 (https://ftp.gnome.org/pub/gnome/sources/gdk-pixbuf/2.36/). Уязвимости пока остаются неисправленными в Debian (https://security-tracker.debian.org/tracker/CVE-2017-2870), Ubuntu (https://usn.ubuntu.com/usn/), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2870), SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-2870), openSUSE (https://lists.opensuse.org/opensuse-security-announce/2017-08/), FreeBSD (http://www.vuxml.org/freebsd/), Fedora (https://bodhi.fedoraproject.org/updates/?releases=F26&type=s...).
URL: http://blog.talosintelligence.com/2017/08/vuln-spotlight-mul...
Новость: http://www.opennet.me/opennews/art.shtml?num=47104
> в коде библиотеки есть проверки на переполнение, но при использовании флага "-O3" компилятор (проверено в clang) относит их к коду с неопределённым поведением ("Undefined Behavior") и удаляет как излишний код.Шикарный баг! Небось signed/unsigned намешали в кучу...
Ну, примерно. Тащат то, что заведомо unsigned, в int.
> относит их к коду с неопределённым поведением ("Undefined Behavior") и удаляет как излишний код.Эпично. Что-то даже такого сходу таких уязвимостей и не припомню сходу.
> Эпично. Что-то даже такого сходу таких уязвимостей и не припомню сходу.просто до них редко доходят руки у исследователей и еще реже это выносят на свет.
См. сравнительно недавнее "исправление" в nginx, не решившее до конца проблему.
http://www.opennet.me/openforum/vsluhforumID3/111703.html#10
заметьте - Дюнин о нем не в курсе по сей день.в конце-концов, бестолковые любители -O6 должны страдать.
> бестолковые любители -O6 должны страдать.что же, как не pixbuf, стоит собираться с -O3 ? Риторический вопрос, но может у тебя на него есть ответ.
> что же, как не pixbuf, стоит собираться с -O3только то, что проверено разработчиком именно на такую сборку - -O3 может ломать и не только проверки переполнения.
> но может у тебя на него есть ответ.
ну вот ffdk-aac, помнится, утверждали что им - можно (хз только, сколько лет никто не трогал этот код и можно ли с современными компиляторами ;-) x264 - your mileage may vary ;-)
в общем-то выгоды от O3 обычному коду нет, но тут, каэцца, ломалось и при -O2, а это гораздо забавнее, учитывая что у многих систем это дефолтны
> и при -O2, а это гораздо забавнее, учитывая что у многих
> систем это дефолтнысорри, убежало недописанным- что у многих систем это дефолтный CFLAGS, с которым собирается все, где не указано специально.
> сравнительно недавнее "исправление" в nginx, не решившее до конца проблемуиспользование "++" внутри выражений - прерогатива мамкиных какеров, с ущемленным чувством собственного достоинства.
> start = start * 10 + *p++ - '0';
это же так по-хакерски! все пацаны обзавидутся. И не важно, что пацанам и какеру уже пятый десяток пошел, на самом деле, даже если и так.
> использование "++" внутри выражений - прерогатива мамкиных какеров, с ущемленным чувством
> собственного достоинства.Ну почему же? Можно использовать ++ внутри выражений:
main = do
putStrLn $ "Hello " ++ "world!"
В mainline исправлено, скобки добавили.
wow, Comdiv молодец, значит. Или кто-то еще, кто не поленился донести до разработчиков.
> бестолковые любители -O6 должны страдатьВозьмём это самое слово -O5.
Зачем мы его произносим,
Когда мы свободно могли бы сказать
“-O6”, и “-O7”, и “-O8”?
(c) Винни-Пух и Джи-Си-Си. Глава 12-я, в которой Хромик очень занят и мы впервые встречаемся с Пятнистым GDK-Pixbuf'ом
> Что-то даже такого сходу таких уязвимостей и не припомню сходу.Потому что очень мало кто использует clang с -O3. Практически все основные дистрибутивы GNU/Linux собираются gcc с -O2.
это ж как надо было написать проверки, чтобы компилятор их как UB распознал
Интереснее как можно так написать компилятор, что он выкидывает значащий код работающий с int.
> Эпично. Что-то даже такого сходу таких уязвимостей и не припомню сходу.Почитай рассылки ядра линукс и коменты Торвальдса о подобных оптимизациях. Торвальдс и его шайка все это заметили наверное еще год назад.
А не в clang все нормально?
В дельфи еще лучше - он при таких UB в рантайме exception'ы генерирует (ну при определенных настройках).
> А не в clang все нормально?"When this code is compiled with GCC 6.1 or Clang 3.8 with "-O2" flag, the
overflow check (rowstride / channels != width) is eliminated completely by the
compiler." --https://bugzilla.gnome.org/show_bug.cgi?id=770986#c0
А в тикете написаноWhen this code is compiled with GCC 6.1 or Clang 3.8 with "-O2" flag, the
overflow check (rowstride / channels != width) is eliminated completely by the
compiler.
А ещё интересно то, что он открыт уже год...
> А в тикете написано
> When this code is compiled with GCC 6.1 or Clang 3.8 with
> "-O2" flag, theо, занятненько. Кстати, и пофкисить у них получилось со второй попытки:
https://bugzilla.gnome.org/show_bug.cgi?id=770986#c3
https://bugzilla.gnome.org/show_bug.cgi?id=780269
причем в этой второй - сохранена возможность вторично наступить на грабли int/unsignedчем меньше в твоей программе и твоей системе кода, начинающегося на g*, тем спокойнее спишь.
"Опасность проблемы смягчает то, что она проявляется только при сборке библиотеки с флагом оптимизации "-O3", который редко применяется для финальных сборок."Так большинство использует -O2, так что и исправлять нечего.
Ага, там потому нормальный список дистров
и что? они используют -O2, а значит проблеме не подвержены.
Без разницы:
https://godbolt.org/g/Prpbrv
Может не надо ничего из кода удалять компиляторам? Развели ИИ в переводчике, а теперь страдаем что неверно нас понимает комп ...
> Может не надо ничего из кода удалять компиляторам? Развели ИИ в переводчике,
> а теперь страдаем что неверно нас понимает комп ...Я вот тоже не пойму косяк компилятора, а баг а либе
>> Может не надо ничего из кода удалять компиляторам? Развели ИИ в переводчике,
>> а теперь страдаем что неверно нас понимает комп ...
> Я вот тоже не пойму косяк компилятора, а баг а либеЖена Це ^W^W Стандарт компилятооа вне подозрений.
Тогда половина нагoвнoкоженного вообще перестанет собираться.
Без проблем. Собирай всё с -O0, расскажешь нам о результатах. Особенно о производительности. По моим наблюдениям - снизится раза в 2.
> Может не надо ничего из кода удалять компиляторам? Развели ИИ в переводчике,
> а теперь страдаем что неверно нас понимает комп ...Компилятор делает всё правильно. Если поведение не определено, может творить что хочет. Разумеется, не забывая плюнуть варнинг.
Ага. Выполнять rm -rf / . А чо, по стандарту же !
И никаких warning's Настоящие погроммисты погроммируют согласно стандрту и безошибочно , аки Папа Римский .
Может проще перейти на Qt?
Вряд ли.
https://access.redhat.com/security/cve/CVE-2015-1858
https://access.redhat.com/security/cve/CVE-2015-0295
https://access.redhat.com/security/cve/CVE-2015-1860
> Может проще перейти на Qt?На Rust же, в этом году модно переходить на Rust
Под Qt готовые графические библиотеки и вообще всё вылизывается силами KDE.
А Rust пишется под Firefox, вот когда перейдут тогда и посмотрим.
И снова дырявые GTK с гнумом
Да, что характерно, про кде-софт не появляется новостей о закрытии уязвимости.
Ну так потому что оно не особо кому надо.
А так https://www.kde.org/info/security/PS: и естественно, если приложение падает и глючит (как раз КДЕ вспоминается), то это как раз говорит о том, что не очень хорошая обработка различных ситуаций, что и значит хорошие шансы на поиск уязвимостей.
Хи-хи.... Буквально позавчера местные сишные эксперты уверяли, что в си всё под контролем, а -O3 и "Undefined Behavior это фантастика и кривые руки".
Так и есть. Если не читаешь документацию к любому компилятору - ССЗБ.
> "Undefined Behavior это фантастика и кривые руки".Это не фантастика, но да, кривые руки.
Ага ага
70-е
Языки и компилляторы не виноваты, что программисты путаются скача с goto по меткам в спагетти коде . Нафих структурное программирование.
90-е.
Сборщик мусора нужен тем программистам, которым нужны костыли для мозгов, нафиг java
10-е
Всем программистам вот нефиг делать,кроме ошибок в алгоритмах, также отлавливать undefined behaivour по стандартам на 700 страниц. Надо весь код с дизасемблером проверять, но gcc - лучший !!
Чтобы ты понимал, что там произошло: программер проявил некомпетентность, проверяя УБ уже после УБ, вместо того, чтобы его не допустить. Это либо закладка (что скорее всего), либо кривые руки, и да, компилятор тут абсолютно ни при чём.
>Это либо закладка (что скорее всего)Мне ситуация напоминает когда кто-то из доблестных органов портачит, его увольняют вчерашним днём, делают покерфэйс и говорят, что "а он не из органов".
Итого: си клёвый, могучие сишники не ошибаются, а это был не сишник, а какой-то агент АНБ, вставляющий закладки в опенсорсное ПО.
Компилер не виноват в том, что кто-то там решил, что перегружать 32-битное число допустимо.
Это не ошибка из серии "не заметил", типаif (a = b) {
..
}, грязный хак из серии "проверил - работает".
-----------
П.С: как думаешь, жабиные гуи используют GdkPixBuf ? А Сишарповские ? А питоновские?
Обновление : gdk-pixbuf2-2.36.9-1.fc25.x86_64 в fedora25 исправлено
Да, чего-то автор наврал про fedora. И ссылка левая. У меня тоже: gdk-pixbuf2-2.36.9-1.fc26
Действительно. Оставались неисправленными где-то с месяц назад:https://bodhi.fedoraproject.org/updates/?packages=gdk-pixbuf2
Наверное, это потому, что в Fedora gdk-pixbuf бывает только mingw-)https://bodhi.fedoraproject.org/updates/FEDORA-2017-69f35f32f5
А можно в Debian, Ubuntu, RHEL, SUSE, openSUSE, FreeBSD и Fedora GTK будет собран без поддержки TIFF? Никто же не использует текстурки TIFF в своих программах. Пусть Глаз Гнома вызывает напрямую libtiff.
% pkg info -r tiff
tiff-4.0.8:
sane-backends-1.0.27
lcms2-2.8
webp-0.6.0_3
ghostscript9-agpl-base-9.16_5
netpbm-10.35.98
djvulibre-3.5.27_1
openjpeg15-1.5.2_1
mtpaint-3.40_8
libgxps-0.2.5
sdl_image-1.2.12_10
wx30-gtk2-3.0.2_6
imlib2-1.4.9,2
openjpeg-2.2.0
py27-pillow-3.4.2_1
poppler-0.57.0
poppler-glib-0.57.0
vigra-1.11.0_11
gdk-pixbuf2-2.36.9- всё равно по зависимостям TIFF будет присутствовать в системе.
"Сенсация! Канпелятор создает уязвимости при помощи определенных флагов!" :D
> Уязвимости устранены в выпуске GDK-Pixbuf 2.36.7. Уязвимости пока остаются неисправленными в Debian, Ubuntu, RHEL, SUSE, openSUSE, FreeBSD, Fedora.А релиз 2.36.7 был 18 июля, т.е. уже полтора месяца назад всё исправлено и пылится в архивах. А дистрибутивам плевать на обновления. А тут ещё оказывается, что один фикс как раз привлёк внимание хакеров (и, наверняка, крэкеров тоже). Просто замечательно :( Придётся пересобирать дебиан-пакет самому, ведь так просто. Но неужели каждый должен это делать сам вручную, не для этого ли существуют дистрибутивы?
>> Уязвимости устранены в выпуске GDK-Pixbuf 2.36.7. Уязвимости пока остаются
>> неисправленными в Debian, Ubuntu, RHEL, SUSE, openSUSE, FreeBSD, Fedora.
> А релиз 2.36.7 был 18 июля, т.е. уже полтора месяца назад всё
> исправлено и пылится в архивах. А дистрибутивам плевать на обновления.Вот не надо обобщать: https://packages.altlinux.org/ru/p8/srpms/libgdk-pixbuf/chan...
ArchLinux и вот AltLinux - это просто исключения.
> для этого ли существуют дистрибутивы?И для этого тоже. Дистрибутивам потенциальных контрибъюторов стимулировать как-то ж надо :)
Если бы Дебиан что-то github'а/gitlab'а настроили, а то в https://anonscm.debian.org/git/ ничего кроме как почитать или клонировать не сделаешь. Разве что патчи слать, что иногда делаю. Но когда один раз кучу работы просто "не заметили", а потом сделали "сами" те же изменения, то это хорошенько демотивировало. Или когда шлёшь патч, а они да, говорят или не даже не говорят спасибо, и комитят под своим именем. Как такое называется!?
Единственный баг, для которого Дебиан накладывает патч, потому что апстрим сказал, что не баг, а ядро со своим OOM виновато....The test fails because it can't allocate 5.7 gigs of RAM...
https://bugzilla.gnome.org/show_bug.cgi?id=765094Опубликовано было в апреле 2016.
А проблема оказалась таки не в ядре, а как раз связана с rowstride.
% pkg info -x pixbuf
gdk-pixbuf2-2.36.9