В самом популярном на сегодняшний день почтовом сервере Exim был обнаружен опасный баг: если отправить специально сформированное сообщение, то потенциально можно выполнить произвольный код на целевой системе. Как это работает и как этим воспользоваться, чтобы получить контроль над сервером? Давай разберемся.

Баг был обнаружен исследователем под ником Meh из тайваньской компании Devcore. Проблема связана с некорректной реализацией логики работы при отправке писем частями (чанками). В результате отправки специально сформированного сообщения возникает ошибка типа use-after-free. Уязвимость позволяет атакующему вызвать отказ в обслуживании и даже выполнить произвольный код на целевой системе.

 

Готовимся к тестированию

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

Чтобы тебе не пришлось возиться, я уже собрал готовый докер-файл, который ты можешь скачать из моего репозитория и быстренько развернуть уязвимую версию Exim.

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

/usr/exim/bin/exim -bdf -d+all

Ключ -d+all нужен для отображения на экране подробного лога работы.

Запущенный демон почтового сервера Exim 4.89
Запущенный демон почтового сервера Exim 4.89

Также нелишним будет вооружиться отладчиком gdb, чтобы контролировать процесс выполнения приложения. В самом отладчике нужно выполнить команду set follow-fork-mode child, потому что Exim запускается в режиме демона, а при подключении клиента он создает отдельный форк для обработки соединения. Эта опция поможет переключиться на новоиспеченный процесс.

Включение отладки дочерних процессов в gdb
Включение отладки дочерних процессов в gdb

Если хочешь безболезненно потестить эксплоиты Meh, то рекомендую запустить еще один контейнер, так как в эксплоитах используется библиотека pwntools, которая не завелась у меня в Windows и требует Linux для х64.

docker build -t . pocexim
docker run --rm -ti --link=exim4 --hostname=pocexim pocexim /bin/bash
 

Пара слов о чанкинге

Как и HTTP с его динамическими пакетами, SMTP поддерживает отправку писем частями, без указания точного размера передаваемых данных. За это отвечает механизм из Extended SMTP под названием chunking. Он подробно описан в разделе 4.1 спецификации RFC 3030, где выступает под именем SMTP Service Extensions for Transmission of Large and Binary MIME Messages («расширения протокола SMTP для передачи больших и бинарных сообщений» — перевел как смог!). Передача писем частями впервые была реализована в Exim версии 4.88.

Формат команды для передачи сообщения частями такой:

BDAT <размер_сообщения>
<сообщение>

Символом окончания передачи чанка служит точка в начале новой строки. Последний чанк должен иметь нулевую длину или обозначаться кодовым словом LAST.

 

Подробнее об уязвимости

Самый простой PoC вызывается следующими командами к серверу SMTP.

EHLO localhost
MAIL FROM:<test@localhost>
RCPT TO:<test@localhost>
BDAT 10
.
BDAT 0

Сервер будет спамить сообщением с кодом 250, уведомляя, что получен чанк размером 0 байт.

Результат отправки простого PoC
Результат отправки простого PoC

После череды безуспешных попыток процесс упадет.

Вообще, исследователь выложил две версии работающих PoC эксплоитов. Скачать их можно из треда об уязвимости на «Багзилле» или по прямым ссылкам (одна и другая).

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

PoC успешно отработал
PoC успешно отработал

Пойдем по порядку. Сначала посмотрим на файл receive.c.

/src/receive.c
1783:     if (!store_extend(next->text, oldsize, header_size))
1784:       {
1785:       uschar *newtext = store_get(header_size);
1786:       memcpy(newtext, next->text, ptr);
1787:       store_release(next->text);
1788:       next->text = newtext;
1789:       }
1790:     }

Сервер Exim имеет в своем распоряжении простой инструмент для управления кучей (heap), он располагается в файле store.c. Функция store_extend наряду с store_get и store_release как раз относится к этому инструментарию. Эти три функции и играют ключевую роль в возникновении уязвимости. Если точнее, то это обертки для реальных функций с суффиксами _3.

/src/store.h
30: #define store_extend(addr,old,new) \
31:   store_extend_3(addr, old, new, __FILE__, __LINE__)
...
34: #define store_get(size)      store_get_3(size, __FILE__, __LINE__)
...
48: extern void    store_release_3(void *, const char *, int);  /* so give its  */

Первым шагом (после подключения к серверу, конечно) в эксплоите будет отправка пачки невалидных данных в качестве команды. Это нужно для того, чтобы отрегулировать значение переменной yield_length. Она отвечает за оставшийся размер кучи.

Продолжение доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все материалы на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи один материал

Заинтересовала информация, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для материалов, опубликованных более двух месяцев назад.


Оставить мнение

Check Also

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

Недавно для уязвимости CVE-2018-7600, также известной под названием Drupalgeddon2, был опу…