Представлен (http://www.graphicsmagick.org/NEWS.html#june-15-2019) новый выпуск пакета для обработки и преобразования изображений
GraphicsMagick 1.3.32 (http://www.graphicsmagick.org/), в котором устранены 52 потенциальные уязвимости, выявленные в ходе fuzzing-тестирования проектом OSS-Fuzz (https://www.opennet.me/opennews/art.shtml?num=45602).
Всего с февраля 2018 года при помощи OSS-Fuzz было выявлено 343 проблемы, из которых 331 уже устранены в GraphicsMagick (для оставшихся 12 пока не истёк 90-дневный срок, отводимый на исправление). Отдельно
отмечается (https://www.openwall.com/lists/oss-security/2019/06/15/2), что OSS-Fuzz также используется для проверки смежного проекта ImageMagick (https://imagemagick.org/), в котором в настоящее время остаются неустранёнными более 100 проблем, информация о которых уже доступна публично после истечения времени на исправление.Кроме потенциальных проблем, выявленных проектом OSS-Fuzz, в GraphicsMagick 1.3.32 также устранено 14 уязвимостей, которые могут привести к переполнению буфера при обработке специально оформленных изображений в форматах SVG, BMP, DIB, MIFF, MAT, MNG, TGA,
TIFF, WMF и XWD. Из не связанных с безопасностью улучшений выделяется расширение поддержки WebP и возможность записи изображений в формате Braille для просмотра незрячими.Также отмечается удаление из GraphicsMagick 1.3.32 возможности, которая может использоваться для организации утечки данных. Проблема касается обработки нотации "@имяфайла" для форматов SVG и WMF, позволяющей вывести поверх изображения или включить в состав метаданных текст, присутствующий в указанном файле. Потенциально при отсутствии в web-приложениях должной проверки входных параметров атакующие могут воспользоваться данной функцией для получения содержимого файлов с сервера, например, ключей доступа и сохранённых паролей. Проблема также проявляется в ImageMagick.
URL: https://www.openwall.com/lists/oss-security/2019/06/15/9
Новость: https://www.opennet.me/opennews/art.shtml?num=50876
Открыл первый попавшийся исходник https://gitlab.com/ImageMagick/ImageMagick/blob/master/Magic...: функция на 1200 строк, парсинг аргументов вперемешку с логикой, if внутри switch внутри switch, внутри else, внутри else. Никакой обфускатор так не сможет.Я не удивлён, что в *Magick столько уязвимостей, но я удивлён, что это всё вообще работает. Видимо название придумано не зря - именно на магии это всё и держится.
То что ImageMagick - свалка ископаемого г.внокода ни для кого не секрет.
Зато красивый комментарий в начале файла.
Когда твой красивый аккуратный код по всем бест практисам никому не сдался, и остаётся брызгать слюной на "уродливый", но намного более полезный
Вы просто не понимаете еще, опыта мало у вас. Когда такой гений-выскочка пишет код - ему хорошо. Когда он уходит из проекта - другим нужно полгода-год, чтобы разобраться, что он понаписал.Бест практисес не просто так же придумываются
Ни фига се уязвимости... в Win3.11+IE такого не было...
IE не было во времена Win3.x
Был.
https://en.wikipedia.org/wiki/Internet_ExplorerНе-а, не был.
> Version 2 was also the first release for Windows 3.1 and Macintosh System 7.0.1 (PPC or 68k),Спасибо, что приводишь ссылки, опровергающие твои слова.
Зато в XP было при просмотре jpg.
> Ни фига се уязвимости... в Win3.11+IE такого не было...на, скачай уже себе:
https://web.archive.org/web/20021001180626/http://download.m...
(будете смеяться, но он скачивается. не знаю, работает ли)
> 14 уязвимостей, которые могут привести к переполнению буфераКартина Репина "Си-программисты работают с буфером"
> Картина Репина "Веб-дизайнеры пишут на С"
Понизить их в должности до Бэйсик программиста, там явных буферов нет...
Если ваша позиция с том, что Си не нужен, или в том, что GraphicsMagick нужно было писать, например, на Java, то, конечно, удачи вам, когда будете делать аналогичный проект :)
Помнишь времена, когда через ИК-порт передавали друг другу мобильные Java-игры (J2ME)? Заметь, что на тех хилых девайсах это были именно Java-, а не си-игры, и с рисованием графики там проблем не было. В особенности не было переполнений буферов.
...и уж тем более красот вроде CVE-2008-3551 не было?
А вот и Шигорин с первым попавшимся результатом Гугла по запросу "J2ME уязвимости смотреть список бесплатно без регистрации"
Черт возьми, а ведь и впрямь линчуют негров... И [eq поспоришь блин...
Самсунги перешивали через уязвимость в ява-машине.
Вернее не самсунги, а сименсы.
О да, это одно и то же, что и скоростная обработка множества больших изображений :)
>переполнений буферовВаша фраза в таком виде может быть воспринята иначе, чем вы задумывали... ...или вы так и задумывали?
позиция в том, что ылитные сишники в большинстве своем - макаки не лучше вебмакак.
Твоя "позиция" - школотрон-бездельник на каникулах.
> в GraphicsMagick 1.3.32 также устранено 14 уязвимостей, которые могут привести к переполнению буфера при обработке специально оформленных изображений в форматах SVG, BMP, DIB, MIFF, MAT, MNG, TGA, TIFF, WMF и XWD.Какие же вы упортые, пользователи x86. Вот в процах от IBM на аппаратном уровне есть запрет выделения памяти в режиме WX (одновременно для изменения и исполнения).
Если сборщики дистров будут строго следовать главному правилу построения безопасных ОС: "все что исполняется не должно изменятся,а что изменяется исполнятся", то переполнения буфера перестанет быть потенциальной уязвимостью.
Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.
> Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.Ну убедимся, что весь JIT отвалится. Что дальше?
>> Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.
> Ну убедимся, что весь JIT отвалится.Не весь:
https://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in.../
Правильно настроение ядро Linux+PAX действительно отрубить весь код с JIT.Почти все программы сегодня поддерживают сборку без JIT. Так в Gentoo надо указать USE="-jit".
Лучше сразу при сборке пакетов оптимизировать под ваш проц! Зачем оптимизировать (изменять код) при исполнении?
Правильная разработка программы с JIT это ветвление на два кода с JIT и без с возможностью выбора ветки в опции configure --nojit при компиляции кода.
> Если сборщики дистров будут строго следовать главному правилу построения безопасных ОС:
> "все что исполняется не должно изменятся,а что изменяется исполнятся", то переполнения
> буфера перестанет быть потенциальной уязвимостью.Для начала им придется выкинуть питон, sh, перл.
Потому что у всех интерпретируемых ЯП с (разновидностью) eval это "не баг, а фича", совсем без переполнения буфера.
Интерпретируемые языки легко ограничить с помощью chmod, chown. Создать двух пользователей, одному разрешить использовать интерпретаторы, другому нет.Для работы в десктопе с бровзером интерпретаторы не нужны.
Скажи это половине инфраструктуры, обеспечивающей твой десктоп. Всякие firewalld, tuned, подозреваю, что и тот же gnome и энная часть утилит, которая работает "под капотом" для обеспечения приятного и уютного UX на вашем localhost-е.
> Какие же вы упортые, пользователи x86. Вот в процах от IBM напользователи фон-неймановской архитектуры, вы хотели сказать? Догадаетесь, где сейчас все остальные архитектуры?
Правильно - в музее, рядом с вычислительной машиной Бэбиджа и памятью с троичной системой.> аппаратном уровне есть запрет выделения памяти в режиме WX (одновременно для
очередной полуработающий костыль, это, конечно, прекрасно.