The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Критическая уязвимость в Exim, позволяющая выполнить код на ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от opennews (??), 06-Июн-19, 14:18 
В почтовом сервере Exim выявлена (https://www.openwall.com/lists/oss-security/2019/06/05/4) критическая уязвимость (http://www.exim.org/static/doc/security/CVE-2019-10149.txt) (CVE-2019-10149 (https://security-tracker.debian.org/tracker/CVE-2019-10149)), которая может привести к удалённому выполнению кода на сервере с правами root  при обработке специально оформленного запроса. Возможность эксплуатации проблемы отмечена в версиях с 4.87 по 4.91 включительно или при сборке с  опцией EXPERIMENTAL_EVENT.


В конфигурации по умолчанию атака может быть совершена без лишних усложнений локальным пользователем, так как применяется ACL "verify = recipient", выполняющий дополнительные проверки для внешних адресов. Совершение удалённой атаки возможно  при изменении настроек,  например, при работе в роли вторичного MX для другого домена, удалении ACL "verify = recipient" или определённых изменениях в local_part_suffix). Удалённая атака также возможна если злоумышленник сможет удержать соединение с сервером открытым в течение 7 дней (например, отправляя по одному байту в минуту для обхода обрыва по таймауту). При этом не исключается, что для удалённой эксплуатации проблемы существуют и более простые векторы атаки.

Уязвимость вызвана некорректной проверкой адреса получателя в функции deliver_message(), определённой в файле /src/deliver.c. Через манипуляцию с форматированием адреса атакующий может добиться подстановки своих данных в аргументы команды, вызываемой через функцию execv() с правами root. Для эксплуатации не требуется применение сложных техник, используемых при переполнениях буфера или повреждении памяти, достаточно просто подстановки символов.


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

         deliver_localpart = expand_string(
                       string_sprintf("${local_part:%s}", new->address));
         deliver_domain =    expand_string(
                       string_sprintf("${domain:%s}", new->address));


Функция expand_string() является переусложнённым комбайном, в том числе распознающим команду "${run{команда аргументы}", приводящую к запуску внешнего обработчика. Таким образом, для атаки  в рамках SMTP-сеанса локальному пользователю  достаточно передать команду вида 'RCPT TO "username+${run{...}}@localhost"', где localhost один из хостов из списка local_domains, а username имя существующего локального пользователя.


Если сервер работает в качестве почтового релея достаточно удалённо отправить команду 'RCPT TO "${run{...}}@relaydomain.com"', где relaydomain.com один из хостов, перечисленных в секции настроек relay_to_domains. Так как по умолчанию в exim не применяется режим сброса привилегий (deliver_drop_privilege = false), переданные через "${run{...}}" команды будут выполнены с правами root.

Примечательно, что уязвимость была устранена (https://github.com/Exim/exim/commit/7ea1237c783e380d7bdb86c9... в вышедшем в феврале выпуске 4.92 без акцентирования внимания на то, что исправление может привести к проблемам с безопасностью. Нет оснований полагать, что имело место осознанное сокрытие уязвимости разработчиками Exim, так как проблема была устранена в ходе исправления (https://bugs.exim.org/show_bug.cgi?id=2310) сбоя , возникающего при передаче некорректных адресов,  а уязвимость была выявлена компанией Qualys при проведении аудита изменений в Exim.


Исправление для прошлых версий, которые продолжают применяться в дистрибутивах, пока доступно только в виде патча (https://git.exim.org/exim.git/commit/d740d2111f189760593a303.... Корректирующие выпуски для прошлых веток с устранением проблемы запланированы на 11 июня. Обновления пакетов подготовлены для Debian (https://security-tracker.debian.org/tracker/CVE-2019-10149),... (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2019-10149). Arch Linux (https://www.archlinux.org/packages/community/x86_64/exim/) и Fedora (https://bodhi.fedoraproject.org/updates/FEDORA-2019-7b741dcaa4) поставляют версию 4.92, в которой проблема не проявляется. RHEL и CentOS проблеме не подвержены (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10149), так как Exim не входит в их штатный репозиторий пакетов.


URL: https://lists.exim.org/lurker/message/20190605.151853.84c1a7...
Новость: https://www.opennet.dev/opennews/art.shtml?num=50819

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


2. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –5 +/
Сообщение от Аноним (2), 06-Июн-19, 14:29 
закладка
Ответить | Правка | Наверх | Cообщить модератору

14. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (14), 06-Июн-19, 16:12 
бритва хенлона
Ответить | Правка | Наверх | Cообщить модератору

31. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +3 +/
Сообщение от Аноним (31), 06-Июн-19, 20:01 
Анекдот про коров, одна из которых говорит другой про бритву Хенлона
Ответить | Правка | Наверх | Cообщить модератору

60. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним (60), 09-Июн-19, 21:45 
Еще один дурацкий комментарий.
Ответить | Правка | Наверх | Cообщить модератору

28. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним (28), 06-Июн-19, 19:32 
Ошибка проектирования.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (3), 06-Июн-19, 14:30 
Exim работает от имени root?
Ответить | Правка | Наверх | Cообщить модератору

4. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +20 +/
Сообщение от Аноним (4), 06-Июн-19, 14:44 
Именем Рут, помещаю это сообщение в исходящую очередь!
Ответить | Правка | Наверх | Cообщить модератору

5. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +2 +/
Сообщение от Your Anonymous (?), 06-Июн-19, 14:53 
В дебиан и убунту от debian-exim пользователя, по идее.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

8. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Moomintroll (ok), 06-Июн-19, 15:39 
> Exim работает от имени root?

Обычно - да, от root. И тому есть объективные причины - это нужно для поддержки Maildir в пользовательских хомяках, а так же для чтения пользовательских настроек редиректов и даже для доставки в /var/mail/<username>.

Но, поскольку уже давно почтовые серверы (включая exim) практически не используются для доставки почты локальным пользователям напрямую, а используются LDA от CyrusIMAP/Docvecot/etc, то можно запускать с правами непривилегированного пользователя. Так и делаю. Единственный момент -

setcap cap_net_bind_service=+ep /path/to/exim/binary
- для возможности слушать почтовые порты.

P.S. На всякий случай создаю для локальных пользователей mailbox'ы в /var/mail/ с правами записи для группы пользователя exim'а.

P.P.S. Знаю, вместо этого правильно указывать алиасы с реальными почтовыми ящиками, но... пусть будет.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

9. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –11 +/
Сообщение от пох. (?), 06-Июн-19, 15:44 
> Обычно - да, от root. И тому есть объективные причины

одна: это юникс-программа (не путайте с вашим "новым стандартом") а там есть только один привиллегированный пользователь, от которого и работают большинство системных демонов.

кому не нравится - вон есть прекрасная windows.

И, кстати, exchange.

Ответить | Правка | Наверх | Cообщить модератору

12. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Sw00p aka Jerom (?), 06-Июн-19, 15:55 
>И, кстати, exchange.

в январе сего года в exchange похлеще была бага.

Ответить | Правка | Наверх | Cообщить модератору

15. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (15), 06-Июн-19, 16:16 
>одна: это юникс-программа (не путайте с вашим "новым стандартом") а там есть только один привиллегированный пользователь, от которого и работают большинство системных демонов.

угу, и как правило кривосторонне-архитектурных..

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

29. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от пох. (?), 06-Июн-19, 19:53 
>>одна: это юникс-программа (не путайте с вашим "новым стандартом") а там есть только один
>>привиллегированный пользователь, от которого и работают большинство системных демонов.
> угу, и как правило кривосторонне-архитектурных..

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

И с архитектурой уж точно все блестяще.

Ответить | Правка | Наверх | Cообщить модератору

39. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним (15), 06-Июн-19, 21:18 
Ы-ы, моя морда больше по qmail, пучок килограмм postfix, охапка канистр Dovecot..
a exchange - свят, свят - миловала чаша сия
Ответить | Правка | Наверх | Cообщить модератору

40. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от пох. (?), 06-Июн-19, 22:19 
> Ы-ы, моя морда больше по qmail, пучок килограмм postfix, охапка канистр Dovecot..

а у меня sendmail работал в 97м (не для интернета ни разу) - и работает по сей день.
В юниксе, да, там не линукс. А dovecot, когда-то казавшийся почти приличным софтом, но во второй версии радостно повернувший в "новые стандарты", выброшен на помойку.

> a exchange - свят, свят - миловала чаша сия

а вот exchange был уже в 96м, если не ошибаюсь. Но я не стал учиться его админить - это ж книжку надо было читать, громадную, страниц 500, а не op.me

Ответить | Правка | Наверх | Cообщить модератору

19. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –4 +/
Сообщение от Аноним (19), 06-Июн-19, 16:58 
Только Zimbra. Аптайм 768 дней.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

47. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Ничоси (?), 07-Июн-19, 00:00 
Через 256 дней, будет юбилей - 1024 дня.
Ответить | Правка | Наверх | Cообщить модератору

21. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от жека воробьев (?), 06-Июн-19, 17:39 
Именно сейчас сношаю эксчендж, потому что при установке секьюрити фикса оно не смогло установиться и корректно откатиться тоже не смогло. Ну там еще пометило все службы эксчендж как выключенные и не включило назад. Чтобы патч все же накатить надо засунуть вглубь систем32 повершел скрипт с переопределением стандартных командлетов и после этого апдейт запустится. Суровый энтерпрайз за деньги
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

22. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +8 +/
Сообщение от Ваш Анонимус (?), 06-Июн-19, 18:17 
Ты так рассказываешь, как будто эксчендж тебя сношает, а пишешь, что ты его.
Ответить | Правка | Наверх | Cообщить модератору

24. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от жека воробьев (?), 06-Июн-19, 18:35 
Ты прав
Ответить | Правка | Наверх | Cообщить модератору

36. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от Аноним (14), 06-Июн-19, 20:57 
> там есть только один привиллегированный пользователь, от которого и работают большинство системных демонов.

Если ты не осилил setuid(2), это не повод экстраполировать.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

11. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Sw00p aka Jerom (?), 06-Июн-19, 15:54 
>Обычно - да, от root. И тому есть объективные причины - это нужно для поддержки Maildir в пользовательских хомяках, а так же для чтения пользовательских настроек редиректов и даже для доставки в /var/mail/<username>.

у Dovecot такая же история, но как обычно на почтовых серверах нет понятия "пользовательских хомяках", для того же dovecot юзается один uid/gid для всех виртуальных юзеров.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

16. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним (15), 06-Июн-19, 16:49 
>у Dovecot такая же история, но как обычно на почтовых серверах нет понятия "пользовательских хомяках"

есть, нo как говорится разрабы (LDA Dovecot) так решили архитектурно: или нить на сессию, или процесс на сессию для MUA

>для того же dovecot юзается один uid/gid для всех виртуальных юзеров.

... и т.е. потенциальная проблема для всех "почтовых хомякофф" - см. выбор дизайнa из пункта выше


Ответить | Правка | Наверх | Cообщить модератору

17. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Sw00p aka Jerom (?), 06-Июн-19, 16:55 
> ... и т.е. потенциальная проблема для всех "почтовых хомякофф" - см. выбор
> дизайнa из пункта выше

а вот тут, про проблему по подробнее пожалуйста


Ответить | Правка | Наверх | Cообщить модератору

18. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Sw00p aka Jerom (?), 06-Июн-19, 16:58 
>выбор дизайнa из пункта выше

Ну смотрите, ради "безопасности" разделяем всех юзеров на uid/gid, но при этом рабочему процессу даем рута, и на оборот, не даем рута рабочему процессу, но при этом все юзеры под одним uid/gid.

Так вот вопрос, что рискованней по мащему мнению?


Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

23. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от Аноним (15), 06-Июн-19, 18:25 
Попытаюсь раскрыть,
если не подводит память и не было новаторства - на ID posix нити нельзя вызвать setuid(), setguid()
+
плюс банальныe ограничения по CPU, RAM, и прочих ресурсов - т.е. выбор.

>Ну смотрите, ради "безопасности" разделяем всех юзеров на uid/gid, но при этом рабочему процессу даем рута, и на оборот, не даем рута рабочему процессу, но при этом все юзеры под одним uid/gid.

ИМО 2 однозначно, обясню почему:
в правильной архитектуре рут нужен только для "инициализации" - системной и сеансовой, никакой записи ему не должно быть положено и точка !

----------
рекомендую глянуть файлы qmail-start.c и qmail-lspawn.c

если разбрасывать локально из уже дoстaвленной очереди сообшений на серваке,
пример псевдо из кода qmail-lspawn.c  и часть проверок пропустил:

...
chdir(/HOMYAK/USVER)
...
ret = fork();
if (0 == ret)
{
  //сброс привилегий
  prot_uid(UID); //setuid();
  prot_gid(GUID); //setguid();
  execv*( bla-bla-bla );
}

...

Ответить | Правка | Наверх | Cообщить модератору

32. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от пох. (?), 06-Июн-19, 20:19 
> рекомендую глянуть файлы qmail-start.c и qmail-lspawn.c

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

он может и хороший теоретик, но почему-то все его теории сводятся к "тут все неправильно, переделать толком ничего нельзя, поэтому будет фигня". Правильной операционной системы, правильного smtp и правильного dns - почему-то так и не написал.

Примерно половина спама в лучшие годы васян-мэйлеров у меня была с qmail'овых релеев. Потому что автор, внезапно, вообще не предназначал свою поделку для релеинга.

Ответить | Правка | Наверх | Cообщить модератору

37. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (15), 06-Июн-19, 21:02 
>и никогда так не делать - типичный образец ненужной, антиюниксной, мертворожденной хни, как и абсолютно все поделки djb.

- REALY ? просто, лаконично и в никс стиле: ядро n-daemon (один демон - одна функция), и все аккуратно сварено pipe ; может стиль кода ? - ну таку фломастеры...
- "много-деммонный" не-хлам cо схожей архитектурой - Dovecot, Postfix тоже в хню запишем ?
... поверьте в свое время плотно с сорцами Dovecot повозился

>Примерно половина спама в лучшие годы васян-мэйлеров у меня была с qmail'овых релеев. Потому что автор, внезапно, вообще не предназначал свою поделку для релеинга.

по логам из давней старины, такие же басни могу добавить про всю оставшуюся 2-второго поколения и шлимыл, а вспомнил ишо в 2005-6 шмугль юзал поделие djb

Да и сам SMTP, с некоторымы изъянами и недоработками(для нынешнего времени).. но ничего занимаемся, допиливаем под свои нужды, а учитывая выходку одного пациента из peдмoндa по клиентy версии 7.* этой весной... ряд лиц очень расстроенные и несколько раздосадованные, каГ-бы помягшЕЕ сказать

Ответить | Правка | Наверх | Cообщить модератору

42. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –2 +/
Сообщение от пох. (?), 06-Июн-19, 22:46 
> - REALY ? просто, лаконично и в никс стиле: ядро n-daemon (один

куча мусора гадящего под себя, неумеющего пользоваться syslog ("патамушта он весь у вас неправильный") и, вишенка на тортике, в исходном авторском замысле - либо не релеящий вовсе, либо openrelay. Запускаться был предназначен, видимо, прямо из src, как у автора.
(ну и world writable dir вместо suid binary, как и у поцфикса ранних версий)

с кодом в общем-то все хорошо - но он и незамысловат настолько, что сложно было бы сделать плохо.

> - "много-деммонный" не-хлам cо схожей архитектурой - Dovecot, Postfix тоже в хню
> запишем ?

безусловно. openrelay в каждом конфиге по умолчанию, вот что такое ваш поцфикс.
Да, это исправляли и исправляют по сей день ВСЕ собиральщики пакетов, но сообразили они это далеко не сразу. И по сей день спам с так настроенных postfix иногда долетает (хотя вроде бы с третьих версий умолчание все же изменили на адекватное - спросите себя, на каком локалхосте стоит почтовка автора, что ему потребовалось двадцать лет на такое изменение, и зачем пользоваться его продуктом? - видимо, у кого-то есть конфиги, где вернули все как было)

dovecot был почти хорош во времена версии 1 - в частности, когда я вижу что софт работает с mailbox правильно, это подтверждение квалификации его автора (поддержка только maildir - это перекладывание собственного неумения на файловую систему, ну да, ее еще хорошие программисты писали, давно правда, как и поддержка обоих но первых с потерей производительности вдвое - у нормальных людей должно получаться одинаково)

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

> по логам из давней старины, такие же басни могу добавить про всю
> оставшуюся 2-второго поколения и шлимыл, а вспомнил ишо в 2005-6 шмугль

у меня неправильные логи - sendmail там никогда не было (потому что сделать openrelay на версии  7+ - я вообще не очень знаю, как. Единственные исключения - multihop, там виноват не мэйлер а руки админа, оно точно так же на любом mta бы работало (поскольку предпоследний, обычно это антивирус или васян-спамолов, он считает доверенным внутренним хостом).
exim редко, в силу его малой популярности и обслуживания в основном админами провайдеров, те умеют (но если уж лоханутся, то со страшной силой).
MDaemon (по сей день находятся, умники)
экзотика и винды с кривым Kerio - поболее.
А вот qmail'ов - сравнимо со взломанной виндой. Только последние лет пять он, наконец-то, вытеснен взломанным php и дырками в гугле.
Остальное - взломанные (спам напрямую шлет троян, а не штатный mta). Бывают и линуксы.


Ответить | Правка | Наверх | Cообщить модератору

46. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Sw00p aka Jerom (?), 06-Июн-19, 23:59 
>MDaemon (по сей день находятся, умники)

кажись это тот же постфикс, как и комунигейт

Ответить | Правка | Наверх | Cообщить модератору

51. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (15), 07-Июн-19, 10:30 
>> - REALY ? просто, лаконично и в никс стиле: ядро n-daemon (один
> куча мусора гадящего под себя, неумеющего пользоваться syslog ("патамушта он весь у  вас неправильный") и,

пардон мой френч, все настраивалось и логи все находились в /var/log/{bla-bla-bla}

> вишенка на тортике, в исходном авторском замысле - либо не релеящий вовсе, либо openrelay.

... все там нормально плюс издержки "СТАРОГО" SMTP

> Запускаться был предназначен, видимо, прямо из src, как у автора.

Ы-ы, /var/qmail/{...} ничего не говорит из дефолта ?
по ходу разные дистры по разному опакеичвали, ну там тараканы были в голове у автора по лицухе, но в дальнейшем djb твердо встал на путь исправления

> (ну и world writable dir вместо suid binary, как и у поцфикса ранних версий)

мда, world на 4+2+1 это где, в каком звене цепочки доставки можно раскрыть, могет я что-то упустил  ?
выделенный демон(процесс) со спец. UID, GUID, (etc., + на счет sticky не помню, надо в сорцы лезть) занимается постановкой в очередь сообщений SMTP из сети - если это называть world writable dir - становится страшно

> когда я вижу что софт работает с mailbox правильно, это подтверждение квалификации его автора
> (поддержка только maildir - это перекладывание собственного неумения на файловую систему,
> ну да, ее еще хорошие программисты писали, давно правда, как и поддержка обоих но первых с потерей производительности вдвое - у нормальных людей должно получаться одинаково)

ага, mbox concurency, NFS trouble(каких-то версий) - ни слухом, ни духом
а так да, в тепличных условиях localhost`a mbox чье-то ффсе

> к сожалению, авторы тоже свернули в "новые стандарты", и современным пользоваться мне категорически расхотелось.

+ авторам Dovecot за "самодеятельсть и кривjрукость" с форматом Maildir++(или как там обозвали) пожизненный эцих с гвоздями и граблями

> А вот qmail'ов - сравнимо со взломанной виндой.

голословно и сказать смешно, не сказать ничего

> Остальное - взломанные (спам напрямую шлет троян, а не штатный mta). Бывают и линуксы.

вопрос кривизны рук админов

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

53. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от пох. (?), 07-Июн-19, 13:00 
> пардон мой френч, все настраивалось

в нормальном unix mta эти вещи не нужно настраивать - он просто использует syslog.
Идущие своим другим путем - вечно создают проблемы  на пустом месте.

Но вообще-то оно было изначально предназначено для daemontools, со всеми вытекающими.

> .. все там нормально плюс издержки "СТАРОГО" SMTP

в smtp нет обязательств релеить мусор. патч к сендмэйлу появился в 98м, когда спам начал представлять проблему.
Нет, openrelay почти из коробки и нетривиальные телоджвижения для его ограничения - это не "нормально".
Нормально - no relay из коробки и нетривиальные телодвижения чтобы добавить доверенные хосты - при невозможности добавить весь мир "потому что некогда разбираться, начальника спрашивает - почта мая где?!"

> ага, mbox concurency, NFS trouble(каких-то версий) - ни слухом, ни духом

стесняюсь спросить - и много у вас mbox'ов на nfs 3й версии?
И отдельно - что, по вашему, делает файловая система в этих же самых случаях, когда у вас "mbox concurency"? (правильно, она ставит локи - только это ее внутренние локи, и вы их не видите, вам кажется что операции - атомарны. Ну так это - кажется.)

А так - Володя Бутенко мерял - скорость правильно написанного кода различалась на уровне погрешности измерения (fs с тех пор стали сильно сложнее, и скорее всего скорость обработки метаинфы сильно упала). Причем он тренировался на завернутом в smtp alt.binaries.erotica.pictures.* - там был стабильный поток сисек и писек шириной больше типовых каналов тогдашних мелких провайдеров.


>> А вот qmail'ов - сравнимо со взломанной виндой.
> голословно и сказать смешно, не сказать ничего

! (это палец, посмейся)

для меня голословно - это твое "Уменявсеработает,уостальныхкривыеруки". А вот своей собственной статистике я верю.


Ответить | Правка | Наверх | Cообщить модератору

54. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от Аноним (15), 07-Июн-19, 13:47 

> в smtp нет обязательств релеить мусор. патч к сендмэйлу появился в 98м,
> когда спам начал представлять проблему.

угу, када "ппольшого пызнеса" не было, а были чинно и блохародно (сплошное MIT, НИИЧАВО, пр.) - недоработки SMTP повылазили

> Нет, openrelay почти из коробки и нетривиальные телоджвижения для его ограничения -
> это не "нормально".
> Нормально - no relay из коробки и нетривиальные телодвижения чтобы добавить доверенные
> хосты - при невозможности добавить весь мир "потому что некогда разбираться,
> начальника спрашивает - почта мая где?!"

...это к архитекторам SMTP - выбираем или SIMPLE, или SERVER - така хня малята
хотя в стандарте сказано SIMPLE - получите распишитесь

>> ага, mbox concurency, NFS trouble(каких-то версий) - ни слухом, ни духом
> стесняюсь спросить - и много у вас mbox'ов на nfs 3й версии?

приходилось пересекаться, и с криворукими поделями MUA - но там да, квал. нужна, хотя бы базовая уровня разработчика СУБД

> И отдельно - что, по вашему, делает файловая система в этих же
> самых случаях, когда у вас "mbox concurency"? (правильно, она ставит локи
> - только это ее внутренние локи, и вы их не видите,
> вам кажется что операции - атомарны. Ну так это - кажется.)

мне ничего не кажется, там по (maildir) идет привязка уникальности  по i-node и/или подобному и точка, локи(from user-level) на юг не впились

> А так - Володя Бутенко мерял - скорость правильно написанного кода различалась
> на уровне погрешности измерения (fs с тех пор стали сильно сложнее,
> и скорее всего скорость обработки метаинфы сильно упала). Причем он тренировался
> на завернутом в smtp alt.binaries.erotica.pictures.* - там был стабильный поток сисек
> и писек шириной больше типовых каналов тогдашних мелких провайдеров.
>>> А вот qmail'ов - сравнимо со взломанной виндой.
>> голословно и сказать смешно, не сказать ничего
> ! (это палец, посмейся)
> для меня голословно - это твое "Уменявсеработает,уостальныхкривыеруки". А вот своей собственной
> статистике я верю.

квадратное и зеленое, у каждого своя лож.. тьфу статистика, в свою верю

P.S.:
предлагается продолжить партию на следующей новости по mail services ?!

Ответить | Правка | Наверх | Cообщить модератору

65. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Анкхemail (?), 10-Июн-19, 18:58 
Ну дак exim при доставке письма транспортом так и делает. Реально он пишет в почтовый ящик под правами юзера.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

25. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (25), 06-Июн-19, 18:40 
> И тому есть объективные причины - это нужно для поддержки Maildir в пользовательских хомяках, а так же для чтения пользовательских настроек редиректов и даже для доставки в /var/mail/<username>.

Это не причина, это подход "и так сойдёт...". И этот подход не в Exim, он на уровне ОС.

Отдельно стоит заметить про setcap, вот что люди только не придумают, чтобы RBAC и ACL не использовать. Вон какой целый SELinux есть. Ну прикрутить к этой операционке рабочую модель аутентификации вместо PAM, прикрутить нормальную сервисную модель, прибить всё это к SELinux гвоздями, тогда хотя бы один дистрибутив  не даст запускать из-под рута всякое барахло.

Примечательно, что такое простофильство в линуксе - это мрачное наследие Unix.
Когда пользователь был еще и программист предполагалось, что безопасности на прикладном уровне "пользователь сам должен знать, что запускает" хватит всем. А потом компьютеры стали дешевле, появилась сеть на дешевых компьютерах и появилось понимание, что пользователь может не понимать. Забавно, что технически в линуксе есть почти всё что нужно для локальной централизованной безопасности. Однако, дистрибутива, который это всё использует сразу, заботясь о том что и пользователь, и админ и программист могут быть обмануты или их система может быть уязвима из-за ошибки, до сих пор нет. Сидим запускаем почтари от рута в 2019 или изобретаем костылики на capability... мрак.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

33. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от пох. (?), 06-Июн-19, 20:31 
> Отдельно стоит заметить про setcap, вот что люди только не придумают, чтобы RBAC и ACL не
> использовать.

заменяя один костылик другим

> Примечательно, что такое простофильство в линуксе - это мрачное наследие Unix.

я только одного не пойму - что вы все в него при этом лезете, медом вам тут что ли намазано, или какой другой субстанцией? У вас есть прекраснейшая винда. Где можно даже directory traversal bypass выключить (правда, от этого она сломается, но с MAC-selinux тоже ничего и нигде не работает) и ролевых юзеров на все случаи жизни понапридумано и еще самому можно придумать (но все равно альтернативно-одаренные разработчики требуют своим поделкам привиллегий, которых у domain admin и system вместе взятых нет)

> Сидим запускаем почтари от рута в 2019

в почтовом сервере (а exim, обычно, стоит именно на таковом) НЕТ ничего ценнее почты. Как правило, кроме нее и того к чему у почтового сервера обязан быть доступ, чтобы почта ходила, там вообще ничего ценного нет и взяться неоткуда.
Когда эта нехитрая мысль до вас дойдет - возвращайтесь, продолжим.

Лет этак не раньше чем через 500.

Ответить | Правка | Наверх | Cообщить модератору

34. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –2 +/
Сообщение от Аноним (34), 06-Июн-19, 20:48 
> Лет этак не раньше чем через 500.

Вы сегодня очень устали.
Иначе зачем так далеко посылать?
Отдохните сегодня, а они пусть завтра снова приходят ;)
Ведь не бывает программ без "дырок" и популяций без индивидуумов которым хочется "все" переделать (естественно как "лучше"), или я ошибаюсь?

Ответить | Правка | Наверх | Cообщить модератору

43. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от пох. (?), 06-Июн-19, 22:50 
> Ведь не бывает программ без "дырок" и популяций без индивидуумов которым хочется
> "все" переделать (естественно как "лучше"), или я ошибаюсь?

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

Ответить | Правка | Наверх | Cообщить модератору

48. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 07-Июн-19, 00:13 
> Это не причина, это подход "и так сойдёт...". И этот подход не в Exim, он на уровне ОС.

Эта проблема только эксзима ибо он спроектирован через одно место, монолитом. Было бы как, например, в Postfix, то таких проблем не было бы.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

58. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от Аноним (58), 08-Июн-19, 10:54 
Где-то это уже было. "Мрачное наследие" СССР всё долбят и долбят десталинизациями, а лучше почему-то не становится. Линукс возник как клон Юникс и существует благодаря постоянным заимствованиям из него. Короче, нечего на других пенять, коли у самого рожа крива. Не можешь сделать - не отсвечивай. Жалкие оправдания, что виноват кто-то другой 30 лет назад лучше оставь себе.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

57. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (58), 08-Июн-19, 10:37 
Работает во имя рута.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

6. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +13 +/
Сообщение от Аноним (6), 06-Июн-19, 15:09 
Новая услуга: "Настрока серверов через SMTP. Очень дорого!"
Ответить | Правка | Наверх | Cообщить модератору

7. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 06-Июн-19, 15:10 
Шо, опять?! (ц)
Ответить | Правка | Наверх | Cообщить модератору

10. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от grsec (ok), 06-Июн-19, 15:46 
Опередил)
Ответить | Правка | Наверх | Cообщить модератору

13. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от Аноним (15), 06-Июн-19, 16:09 
Понятно почему, из тройки MTA второго поколения, самый кривой архитектурно...
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

27. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним (27), 06-Июн-19, 19:13 
один раз установи семь раз обнови.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

20. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от xm (ok), 06-Июн-19, 17:23 
> уязвимость была устранена в вышедшем в феврале выпуске 4.92

Очередной привет любителям некрософта и принципа "работает - не трожь".

Ответить | Правка | Наверх | Cообщить модератору

26. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +2 +/
Сообщение от Аноним (27), 06-Июн-19, 19:10 
Ти шо оно же в контейнере секурность.
Ответить | Правка | Наверх | Cообщить модератору

30. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от пох. (?), 06-Июн-19, 19:58 
>> уязвимость была устранена в вышедшем в феврале выпуске 4.92
> Очередной привет любителям некрософта и принципа "работает - не трожь".

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

P.S. новый код, кстати, в сравнении со старым выглядит омерзительно и нечитаемо. Почему вместо этого не написана безопасная реализация  expand_string, способная работать с невалидирнованными данными - которые еще наверняка в тысяче мест так экспандятся, а нет, так будут - спросите у авторов.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

41. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от xm (ok), 06-Июн-19, 22:42 
Лучше иметь гипотетическую уязвимость о которой (почти) никто не знает, чем реальную о которой знают все.
Ответить | Правка | Наверх | Cообщить модератору

44. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от пох. (?), 06-Июн-19, 22:52 
> Лучше иметь гипотетическую уязвимость о которой (почти) никто не знает, чем реальную
> о которой знают все.

она реальная только в нереальном контексте - шеллюзеры на почтовом сервере, или очень странная настройка.

И это - везение. Поэтому следующая может оказаться более удободоставаемой извне.

Ответить | Правка | Наверх | Cообщить модератору

56. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от xm (ok), 07-Июн-19, 20:32 
Если конкретно эта то да. Events мало кто в Exim использует.
Ответить | Правка | Наверх | Cообщить модератору

59. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (58), 08-Июн-19, 10:59 
Не понятно к чему тут такие странные приветы.
Но это видимо была ирония и ты хотельрассказать всему свету что уд ты-то не такой.
Расскажи подробней, что такое ты целыми днями трогаешь, что считаешь, будто этот принцип к тебе не применим?
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

71. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от eksim (?), 13-Июн-19, 15:03 
Ну, например версия 4.84.2-2+deb8u5 никогда и не была уязвима, в отличие от более новых версиях, которые таскали CVE-2019-10149 ещё с 2016 ;)
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

35. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним (35), 06-Июн-19, 20:56 
>с 4.87 по 4.91

Хорошо сидеть на oldstable

Ответить | Правка | Наверх | Cообщить модератору

38. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +4 +/
Сообщение от Аноним (14), 06-Июн-19, 21:02 
Но на postfix лучше.
Ответить | Правка | Наверх | Cообщить модератору

49. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним (49), 07-Июн-19, 01:09 
1. Непонятно почему root? Кто от root запускает? (или кто не умеет понижать привилегии процесса)
2. Postfix
3.
> RHEL и CentOS проблеме не подвержены, так как Exim не входит в их штатный репозиторий пакетов.

Это что за ухня? Автор, ты больной? Такую ахинею написал. Можно было про epel версию написать, и то было бы лучше.  Ещё бы написал windows проблеме не подвержены так как не Linux...

Ответить | Правка | Наверх | Cообщить модератору

52. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от онанимас (?), 07-Июн-19, 11:45 
удваиваю, редхэт и центось ещё как подвержены, вчера проверил - рутовое выполнение кода работает, обновлений в репах нет.

Installed Packages
Name        : exim
Arch        : x86_64
Version     : 4.91
Release     : 1.el6
Size        : 4.3 M
Repo        : installed
From repo   : epel

epel можно считать стандартной репой, т.к. она включается командой yum install epel-release, а не пердолингом с /etc/yum/repos.d/ как в случае репозиториев от васяна.

Ответить | Правка | Наверх | Cообщить модератору

55. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от привет (?), 07-Июн-19, 17:51 
Как проверили? Можно полный smtp диалог?

у меня куча екзимов и произвести не получилось,
отаваливается на фазе провери формата емейла

Ответить | Правка | Наверх | Cообщить модератору

50. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Гвоздь (?), 07-Июн-19, 05:46 
> RHEL и CentOS проблеме не подвержены, так как Exim не входит в их штатный репозиторий пакетов.

Ггг

Ответить | Правка | Наверх | Cообщить модератору

61. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Аноним473647 (?), 10-Июн-19, 09:37 
в EPEL Exim наконец обновится до 4.92 (спустя 3 месяца после того как вышла версия)
В итоге все CentOS + Exim до сегодняшнего дня уязвимы.
Погововаривают, что идет массовый взлом серверов, в частности на ISPmanager (для этой панели стандартная ОС это CentOS7 + exim из epel)
Проверьте свой root crontab, вирус сидит в нем
Ответить | Правка | Наверх | Cообщить модератору

62. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Anon23423423423423 (?), 10-Июн-19, 16:51 
Как вычистили?
Ответить | Правка | Наверх | Cообщить модератору

63. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +3 +/
Сообщение от Аноним (63), 10-Июн-19, 17:38 
Мой сервер с ISPmanager тоже взломали, почистил задания в cron, в /etc/rc.local, был заменен бинарник curl, вроде пока чисто
Я понять не могу похоже это майнер или что-то подобное заливают
Ответить | Правка | Наверх | Cообщить модератору

64. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от DenniMelloemail (?), 10-Июн-19, 18:23 
Как вы почистили cron? После удаления, опять создается процесс. Втроем справиться не можем.
Ответить | Правка | Наверх | Cообщить модератору

66. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (66), 10-Июн-19, 20:18 
https://pastebin.com/LWG525zS

посмотрите на пути

Ответить | Правка | Наверх | Cообщить модератору

67. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +1 +/
Сообщение от Ананим422356 (?), 11-Июн-19, 02:22 
Лечение вируса
https://habr.com/ru/company/first/blog/455636/
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

68. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  –1 +/
Сообщение от Аноним (68), 11-Июн-19, 14:32 
Так и надо идиотам, у которых exim от рута работает.
Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

69. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (69), 12-Июн-19, 08:48 
как обновить exim в CentOS 6?
Ответить | Правка | Наверх | Cообщить модератору

70. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Анонимный эксперт (?), 12-Июн-19, 13:26 
yum install epel-release
yum --enablerepo=epel-testing install exim
exim --version
Ответить | Правка | Наверх | Cообщить модератору

72. "Критическая уязвимость в Exim, позволяющая выполнить код на ..."  +/
Сообщение от Аноним (72), 16-Июн-19, 20:53 
ежели версия древнее чем 4.87, выдыхаем?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру