URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 113768
[ Назад ]

Исходное сообщение
"Опубликован метод эксплуатации уязвимости в коде разбора бло..."

Отправлено opennews , 07-Мрт-18 23:21 
Раскрыты (https://devco.re/blog/2018/03/06/exim-off-by-one-RCE-exploit.../) детали техники эксплуатации узявимости CVE-2018-6789, приводящей к однобайтовому переполнению в реализации декодировщика данных в формате BASE64, которая была устранена (https://www.opennet.dev/opennews/art.shtml?num=48054) в начале февраля в выпуске  Exim 4.90.1. Проблема проявляется при обработке данные в формате BASE64, размер которых не кратен 4 (4n+3). Рабочий эксплоит подготовлен для пакетов с Exim из состава Debian 9 и Ubuntu 17.04.


Изначально разработчики Exim скептически отнеслись к возможности практической эксплуатации проблемы, но выявивший уязвимость исследователь показал, что на основе данной уязвимости можно подготовить рабочий эксплоит, позволяющий выполнить код на сервере на стадии до прохождения аутентификации, отправив в качестве аргумента в команде "AUTH" специально оформленные данные в формате BASE64 и  при помощи  манипуляции с именем хоста отправителя (sender_host_name) в команде EHLO подготовив нужное смещение в куче для переопределения указателя на следующий блок памяти.

В итоге передачи определённой последовательности данных в командах "AUTH" и "EHLO" указатель на следующий блок хранения можно поменять и перенаправить на блок со строкой ACL. Таким образом, поступающие после команды AUTH данные будут записаны не в блок хранения, а в строку с ACL. Так как в ACL допускается использование конструкции "${run{cmd}}" для выполнения произвольных команд, можно переписать строку c ACL и организовать выполнение любой команды в момент проверки ACL.


По оценке исследователя около 400 тысяч почтовых северов на базе Exim подвержены риску. Всем администраторам рекомендуется убедиться, что на их системах используется  Exim 4.90.1 или установлено обновление пакета с Exim от разработчиков дистрибутивов (Debian (https://security-tracker.debian.org/tracker/CVE-2018-6789), FreeBSD (http://www.vuxml.org/freebsd/316b3c3e-0e98-11e8-8d41-9765715...), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2...), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1543270), openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2018-6789), SUSE (https://bugzilla.suse.com/show_bug.cgi?id=1079832), RHEL/EPEL (https://bugzilla.redhat.com/show_bug.cgi?id=1543269)).

URL: https://devco.re/blog/2018/03/06/exim-off-by-one-RCE-exploit.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=48219


Содержание

Сообщения в этом обсуждении
"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено xm , 07-Мрт-18 23:21 
Красиво

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 00:08 
Погладил свой Postfix за ушком.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено cat666 , 08-Мрт-18 00:44 
Гладь дальше. То, что Postfix такой весь "идеальный", повод насторожится и если про уязвимости и исправления в нём не пишут это не значит, что их нет.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено нах , 08-Мрт-18 05:39 
да не, в поцфиксе число возможных уязвимостей действительно сильно меньше.
потому, что если ты ничего не умеешь, то и уязвимостям быть не в чем.

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


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено amonymous , 08-Мрт-18 10:55 
> через промежуточные прокладки (и огребай последствия рассинхронизаций)

Рассинхронизаций? В постфиксе? Это каг??? 0_о Что вы такое аццкое там лепите/курите?


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 12:41 
> ну а если тебе надо что нестандартное - посиди-подожди, пока то же самое приспичит и автору

… ведь написать патч самому/нанять человека не вариант…


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено angra , 08-Мрт-18 17:04 
А потом поддерживать этот патч для каждой версии postfix, пока его не примут в upstream, если конечно его вообще когда-либо примут. По сравнению с несколькими строками конфига на exim, которые не надо будет править для каждой новой версии это действительно не вариант.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Michael Shigorin jolla , 08-Мрт-18 17:38 
> Гладь дальше. То, что Postfix такой весь "идеальный", повод насторожится и если
> про уязвимости и исправления в нём не пишут это не значит,
> что их нет.

предъявите.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 03:17 
Погладил opensmtpd, раз уж так.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено D , 09-Мрт-18 00:39 
На это он и годен.

Когда exim на порядок конфигурировованее. Но не все умеют, это да!


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 00:22 
Поставил iRedMail и не парюсь.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Crazy Alex , 08-Мрт-18 00:25 
Кхм, при всей моей любви к iRedMail обновлять его - то ещё удовольствие. Работаешь скриптом...

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 12:42 
А скрипт не может работать скриптом?

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Crazy Alex , 08-Мрт-18 13:58 
Может, но готовых нет, а писать скрипт для однократного применения на одном хосте особого смысла нет

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Миклуха , 08-Мрт-18 12:27 
Юзаю nixos-mailserver - включил и забыл.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено D , 09-Мрт-18 00:41 
> Юзаю nixos-mailserver - включил и забыл.

Так это сборка на основе чужих продуктов.

А он юзеров в бд умеет хранить?


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Crazy Alex , 09-Мрт-18 03:36 
nixos - штука сильно на любителя...

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 00:54 
> однобайтовому переполнению в реализации декодировщика данных в формате BASE64

сишники за работой с буфером - то же, что и женщины за рулем. Всех женщин и сишников с 8 марта!


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним7 , 08-Мрт-18 03:21 
Postfix тоже на C.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено fi , 08-Мрт-18 10:22 
а у него есть секретный не С-ный MTA и он ого-ого  )))))))))))

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Нет ты , 08-Мрт-18 14:54 
Надо было его под Rust-ом писать, не было бы проблем с буфером. Под Rust-ом также нет проблем с лицезрением женщин за рулём.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним7 , 08-Мрт-18 03:22 
А Exim, похоже, метит на лавры sendmail по дырявости.
Ну как в XXI  веке можно написать дырявый base64? Кому не лень, проверьте, может у них и криптография самописная?

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Ordu , 08-Мрт-18 12:53 
> Ну как в XXI веке можно написать дырявый base64?

Их дырявый base64 был написан в XX веке. Узнали о дыре в XXI -- это да.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено KonstantinB , 08-Мрт-18 05:13 
Ай, ну классика жанра же, off-by-one error. Со всеми случается.

Странно только, что так долго никто не заметил.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено qsdg , 08-Мрт-18 05:29 
Такие штуки нужно на Rust писать, по крайней мере разбор входных данных.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено KonstantinB , 08-Мрт-18 06:40 
Действительно, почему автор Exim в 1995-м году не написал его на Rust?

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 07:15 
Но сейчас то уже можно

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 12:39 
Да, приступай.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 12:43 
s/можно/модно/

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено amonymous , 08-Мрт-18 10:52 
Напишете свой MTA со сходной функциональностью - приходите.

Но я вам секрет открою: у 99% хипста на это яиц/терпения не хватит.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Имя , 08-Мрт-18 12:08 
ты так говоришь, буд-то это что-то очень сложное.. но там основная сложность - это чтение документации.. в остальном, SMTP мало чем отличается от HTTP

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено XoRe , 08-Мрт-18 12:57 
> ты так говоришь, буд-то это что-то очень сложное.. но там основная сложность
> - это чтение документации.. в остальном, SMTP мало чем отличается от
> HTTP

exim - это не только парсер smtp.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 13:31 
> exim - это, к сожалению, не только парсер smtp.

вот так-то лучше


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено XoRe , 13-Мрт-18 15:21 
>> exim - это, к сожалению, не только парсер smtp.
> вот так-то лучше

Для кого как.
Я на exim интересные и сложные вещи реализовывал.
А кому нужен просто парсер, может поставить что-то попроще.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено KonstantinB , 08-Мрт-18 15:30 
Exim хорош тем, что в его конфигурации можно сделать что угодно: по сути это даже не язык конфигурации, а этакий язык декларативного (и местами императивного) программирования для SMTP. Плох, в общем-то, тем же :-)

Для 98% ситуаций достаточно чего попроще. Но когда стоит нестандартная задача с какой-нибудь хитрой интеграцией, оказывается, что все можно решить на уровне конфигурации Exim.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено лютый жабист__ , 08-Мрт-18 18:09 
Что конкретно нельзя сделать постфиксом? Я уже с 2003 года не слежу за новыми фичами постфикса, ибо почту он исправно принимает. Чё ещё от мта надо-то?

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 08-Мрт-18 20:15 
А теперь попробуй ее форвадить.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено _ , 08-Мрт-18 20:46 
И? В чём прикол?

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено SubGun , 09-Мрт-18 01:03 
> И? В чём прикол?

В том, что он это не умеет. Банальное: принять почту, если пользователь есть в Exchange - отправить в него, если нет - доставить локально. И постфикс обосрется. Если его конечно со всех сторон не обложить костылями


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Alex_hha , 09-Мрт-18 15:29 
> Банальное: принять почту, если пользователь есть в Exchange - отправить в него, если нет - доставить локально. И постфикс обосрется.

ну такое то он умеет кстати, банальный relay_domains + relay_recipient_maps.

А вот как только дело каcается rate limits и умных проверок, то уже все, без всяких postfwd вы там ничего не сделаете, ибо postfix прямолинеен как бревно :D С одной стороны это плюс, но с другой минус. Тут уж каждый должен решать для себя, что ему важнее


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено ALex_hha , 08-Мрт-18 23:34 
Сколько раз фанбои постфикс сливали в подобных спорах. Из коробки без внешних фильтров он мало что умеет, от слова совсем

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Crazy Alex , 09-Мрт-18 03:37 
Э... А должен? linux way, single responcibility там всякие...

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Alex_hha , 09-Мрт-18 15:31 
> Э... А должен? linux way, single responcibility там всякие...

это все равно, что в iptables выкинуть все модули и сказать single way все дела. Или в том же nginx только ядро, базовый функционал и все, больше ничего не знаем.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено KonstantinB , 09-Мрт-18 19:09 
> Э... А должен? linux way, single responcibility там всякие...

Ну вот qmail написан прямо по этому вашему linux way, на каждый пук по процессу. Помню-помню. Не самый дохлый сервер уперся в полочку по CPU из-за количества процессов и context switches на не таком уж большом потоке писем. После замены на exim этот же сервер выдержал увеличение объема еще раз в 5.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено _ , 09-Мрт-18 19:19 
Правда вашей почты там так и осталось - пятая часть :)

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено KonstantinB , 09-Мрт-18 22:46 
Это было еще в те времена, когда gmail-а не было даже в планах. Сейчас там, скорее всего, вообще ничего не осталось :-)

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено KonstantinB , 09-Мрт-18 19:05 
Например, per user rate limit в соответствии со значением, прописанным в sqlite/mysql/pgsql.

Не, я понимаю, что можно написать внешний policy service, но зачем так сложно, если можно просто :-)


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено _ , 09-Мрт-18 19:21 
Красота по китайски вс красота по японски.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено anomymous , 10-Мрт-18 17:43 
Ну если policy service - это сложно, то я даже не знаю.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено EuPhobos , 08-Мрт-18 08:47 
> Изначально разработчики Exim скептически отнеслись к возможности практической эксплуатации проблемы

Зачем так много букв, это всё можно было заменить четырьмя буквами - "лень" =)


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено amonymous , 08-Мрт-18 10:51 
Лишний раз убедился в правильности выбора связки postfix+dovecot для клиентского сервиса :)

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено D , 09-Мрт-18 00:44 
> Лишний раз убедился в правильности выбора связки postfix+dovecot для клиентского сервиса
> :)

Что скажешь, когда в постфиксе найдут дыру?


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено SubGun , 09-Мрт-18 01:01 
Не найдут, он нафиг никому не нужен, судя по всему. Иначе бы давно нашли.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено VimCoder , 09-Мрт-18 12:01 
Не найдут, он нужен, судя по всему. Иначе бы давно не нашли.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено anomymous , 10-Мрт-18 17:44 
Дыры находят везде и всегда. Вопрос в отношение. "А, да разве это дыра" - прямой повод посмотреть альтернативы.

"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Некто , 09-Мрт-18 17:49 
Если сходить по ссылке и разобраться в эксплоите, то выясняется, что для успешной эксплуатации требуется:

First of all, we send a EHLO message with huge hostname ...... 0x6060 length (это, между прочим, EHLO длинной 24672 байта)

Нормальные админы начинают acl_smtp_helo, mail и rcpt с обязательной проверки:

drop    condition = ${if >={${strlen:$smtp_command_argument}}{256}}

Так что мировая катастрофа откладывается.


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено Аноним , 09-Мрт-18 19:58 
> Если сходить по ссылке и разобраться в эксплоите, то выясняется, что для
> успешной эксплуатации требуется:
> First of all, we send a EHLO message with huge hostname ......
> 0x6060 length (это, между прочим, EHLO длинной 24672 байта)
> Нормальные админы начинают acl_smtp_helo, mail и rcpt с обязательной проверки:
> drop condition = ${if >={${strlen:$smtp_command_argument}}{256}}
> Так что мировая катастрофа откладывается.

Спасибо, немного успокоил! Так то оно так, но "Изначально разработчики Exim скептически отнеслись к возможности практической эксплуатации проблемы, но" немного подмачивает (даже не смотря на то, что разработчики они (как правило) такие разработчики :(
И конечно же, это не Exchange плюс Sendmail с их 5-ю процентами на весь Интернет ;)


"Опубликован метод эксплуатации уязвимости в коде разбора бло..."
Отправлено xm , 11-Мрт-18 22:46 
"Нормальным админам" надо бы RFC почитывать на досуге
https://tools.ietf.org/html/rfc1869

"4.1.2.  Maximum command line length

   This specification extends the SMTP MAIL FROM and RCPT TO to allow
   additional parameters and parameter values.  It is possible that the
   MAIL FROM and RCPT TO lines that result will exceed the 512 character
   limit on command line length imposed by RFC 821.  This limit is
   hereby amended to only apply to command lines without any parameters.
   Each specification that defines new MAIL FROM or RCPT TO parameters
   must also specify maximum parameter value lengths for each parameter
   so that implementors of some set of extensions know how much buffer
   space must be allocated. The maximum command length that must be
   supported by an SMTP implementation with extensions is 512 plus the
   sum of all the maximum parameter lengths for all the extensions
   supported."