The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Обновление GraphicsMagick 1.3.32 с устранением уязвимостей

16.06.2019 11:01

Представлен новый выпуск пакета для обработки и преобразования изображений GraphicsMagick 1.3.32, в котором устранены 52 потенциальные уязвимости, выявленные в ходе fuzzing-тестирования проектом OSS-Fuzz.

Всего с февраля 2018 года при помощи OSS-Fuzz было выявлено 343 проблемы, из которых 331 уже устранены в GraphicsMagick (для оставшихся 12 пока не истёк 90-дневный срок, отводимый на исправление). Отдельно отмечается, что OSS-Fuzz также используется для проверки смежного проекта ImageMagick, в котором в настоящее время остаются неустранёнными 38 проблем, информация о которых уже доступна публично после истечения времени на исправление.

Кроме потенциальных проблем, выявленных проектом 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.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Критическая уязвимость в пакете ImageMagick, используемом на многих сайтах
  3. OpenNews: Уязвимость в ImageMagick, позволившая получить доступ к чужим вложениям в почте Yahoo
  4. OpenNews: В рамках проекта ImageFlow началось развитие высокопроизводительной альтернативы ImageMagick
  5. OpenNews: Новая критическая уязвимость в GraphicsMagick и ImageMagick
  6. OpenNews: Разработчики GraphicsMagick проанализировали подверженность уязвимостям ImageMagick
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50876-graphicsmagick
Ключевые слова: graphicsmagick, imagemagick, image
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.9, Аноним (9), 16:45, 16/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Открыл первый попавшийся исходник https://gitlab.com/ImageMagick/ImageMagick/blob/master/MagickWand/compare.c: функция на 1200 строк, парсинг аргументов вперемешку с логикой, if внутри switch внутри switch, внутри else, внутри else. Никакой обфускатор так не сможет.

    Я не удивлён, что в *Magick столько уязвимостей, но я удивлён, что это всё вообще работает. Видимо название придумано не зря - именно на магии это всё и держится.

     
     
  • 2.16, Аноним (16), 19:00, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То что ImageMagick - свалка ископаемого г.внокода ни для кого не секрет.

     
     
  • 3.17, НяшМяш (ok), 19:30, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зато красивый комментарий в начале файла.
     
  • 2.22, Наноним (?), 06:04, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда твой красивый аккуратный код по всем бест практисам никому не сдался, и остаётся брызгать слюной на "уродливый", но намного более полезный
     
     
  • 3.25, Попугай Кеша (?), 09:34, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы просто не понимаете еще, опыта мало у вас. Когда такой гений-выскочка пишет код - ему хорошо. Когда он уходит из проекта - другим нужно полгода-год, чтобы разобраться, что он понаписал.

    Бест практисес не просто так же придумываются

     

  • 1.1, Аноним (1), 12:23, 16/06/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –4 +/
     

     ....ответы скрыты (6)

  • 1.3, Аноним (3), 13:45, 16/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > 14 уязвимостей, которые могут привести к переполнению буфера

    Картина Репина "Си-программисты работают с буфером"

     
     
  • 2.5, Аноним (4), 15:16, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Картина Репина "Веб-дизайнеры пишут на С"
     
  • 2.6, OpenEcho (?), 15:18, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Понизить их в должности до Бэйсик программиста, там явных буферов нет...
     
  • 2.10, anonymous (??), 16:45, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если ваша позиция с том, что Си не нужен, или в том, что GraphicsMagick нужно было писать, например, на Java, то, конечно, удачи вам, когда будете делать аналогичный проект :)
     
     
  • 3.12, Аноним (3), 17:17, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Помнишь времена, когда через ИК-порт передавали друг другу мобильные Java-игры (J2ME)? Заметь, что на тех хилых девайсах это были именно Java-, а не си-игры, и с рисованием графики там проблем не было. В особенности не было переполнений буферов.
     
     
  • 4.14, Michael Shigorin (ok), 17:58, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ...и уж тем более красот вроде CVE-2008-3551 не было?
     
     
  • 5.15, Аноним (15), 18:29, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А вот и Шигорин с первым попавшимся результатом Гугла по запросу "J2ME уязвимости смотреть список бесплатно без регистрации"
     
  • 5.18, Аноним (3), 20:21, 16/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Черт возьми, а ведь и впрямь линчуют негров... И [eq поспоришь блин...
     
  • 4.19, Аноним (19), 01:20, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Самсунги перешивали через уязвимость в ява-машине.
     
     
  • 5.20, Аноним (19), 01:21, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вернее не самсунги, а сименсы.
     
  • 4.24, anonymous (??), 09:23, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    О да, это одно и то же, что и скоростная обработка множества больших изображений :)
     
  • 4.32, Аноним (32), 17:38, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >переполнений буферов

    Ваша фраза в таком виде может быть воспринята иначе, чем вы задумывали... ...или вы так и задумывали?

     
  • 3.13, Аноним (13), 17:22, 16/06/2019 Скрыто ботом-модератором     [к модератору]
  • –4 +/
     
     
  • 4.21, Led (ok), 01:44, 17/06/2019 Скрыто ботом-модератором     [к модератору]
  • +4 +/
     

     ....ответы скрыты (13)

  • 1.23, Аноним (23), 07:51, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > в GraphicsMagick 1.3.32 также устранено 14 уязвимостей, которые могут привести к переполнению буфера при обработке специально оформленных изображений в форматах SVG, BMP, DIB, MIFF, MAT, MNG, TGA, TIFF, WMF и XWD.

    Какие же вы упортые, пользователи x86. Вот в процах от IBM на аппаратном уровне есть запрет выделения памяти в режиме WX (одновременно для изменения и исполнения).

    Если сборщики дистров будут строго следовать главному правилу построения безопасных ОС: "все что исполняется не должно изменятся,а что изменяется исполнятся", то переполнения буфера перестанет быть потенциальной уязвимостью.

    Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.

     
     
  • 2.26, Аноним (26), 11:47, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.

    Ну убедимся, что весь JIT отвалится. Что дальше?

     
     
  • 3.27, Аноним84701 (ok), 12:07, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.
    > Ну убедимся, что весь JIT отвалится.

    Не весь:
    https://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox/

     
     
  • 4.29, Аноним (29), 19:17, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно настроение ядро Linux+PAX действительно отрубить весь код с JIT.

    Почти все программы сегодня поддерживают сборку без JIT. Так в Gentoo надо указать USE="-jit".

    Лучше сразу при сборке пакетов оптимизировать под ваш проц! Зачем оптимизировать (изменять код) при исполнении?

    Правильная разработка программы с JIT это ветвление на два кода с JIT и без с возможностью выбора ветки в опции configure --nojit при компиляции кода.

     
  • 2.28, Аноним84701 (ok), 12:11, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Если сборщики дистров будут строго следовать главному правилу построения безопасных ОС:
    > "все что исполняется не должно изменятся,а что изменяется исполнятся", то переполнения
    > буфера перестанет быть потенциальной уязвимостью.

    Для начала им придется выкинуть питон, sh, перл.
    Потому что у всех интерпретируемых ЯП с (разновидностью) eval это "не баг, а фича", совсем без переполнения буфера.

     
     
  • 3.30, Аноним (29), 19:21, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Интерпретируемые языки легко ограничить с помощью chmod, chown. Создать двух пользователей, одному разрешить использовать интерпретаторы, другому нет.

    Для работы в десктопе с бровзером интерпретаторы не нужны.

     
     
  • 4.31, Аноним (31), 11:29, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Скажи это половине инфраструктуры, обеспечивающей твой десктоп. Всякие firewalld, tuned, подозреваю, что и тот же gnome и энная часть утилит, которая работает "под капотом" для обеспечения приятного и уютного UX на вашем localhost-е.
     
  • 2.34, пох. (?), 18:39, 19/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Какие же вы упортые, пользователи x86. Вот в процах от IBM на

    пользователи фон-неймановской архитектуры, вы хотели сказать? Догадаетесь, где сейчас все остальные архитектуры?
    Правильно - в музее, рядом с вычислительной машиной Бэбиджа и памятью с троичной системой.

    > аппаратном уровне есть запрет выделения памяти в режиме WX (одновременно для

    очередной полуработающий костыль, это, конечно, прекрасно.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру