Комментарии 13
Никогда с Exim не мог сдружиться. Sendmail, затем QMail, потом Postfix — всё ОК. А с Exim все время косяк на косяке. Наверно собственные кривые руки виноваты
Да не… Дело не в руках — там оно чуть не всё такое.
Простейшие вещи нужно иногда через одно место делать… Вот например чтобы отловить "неправильные" Bounce и почту от всяких backscatter и ко (без BATV, ибо не надо) вместо пары простейших правил в системном фильтре чтобы например режектнуть их на входе (без того чтобы самому стать спамером отправляя bounce не туда куда надо), нужно делать кучу ненужных телодвижений.
И главное потом еще и дебажить его на живую, потому что внезапно чтобы протестировать от рута (ибо только так всё, включая системные фильтры и т.д., можно проверить), т.е. "нельзя просто взять и сделать"© что-нибудь вида:
echo "$msg" | exim -N -d+all+filter+... -f from@example.com -t to@example.com ...ибо вдруг по какой-то одному exim известной причине оно позаменяет from@example.com и envelope from и ко из сообщения на root@localhost (wtf) ну и вся проверка дальше коту под хвост...
А поиск в известных поисковиках по howto "exim" "что-то чуть более сложнее чем ..." (как в прочем и для многих популярных продуктов) нередко тонет в бестолковой массе нерелевантных ответов на форумах/SO/SE и т.п. — т.е. найти то что действительно нужное практически нереально.
Документация же (довольно большая кстати) или вики у exim местами откровенно хромают.
Инфы-то вроде много, но как сделать "правильно" что-то конкретное (чуть сложнее чем хеловорлды) — можно искать часами, потому что вот этот параметр конфликтует с вот этим вот (а найти это удается чуть ли не в исходниках).
Хотя с появлением wiki на github стало полегче, да…
Осталось им еще там issues включить (чтобы можно было нормальный баг-трэкер юзать).
Хмм…
А баг конечно эпичный:
int
string_interpret_escape(const uschar **pp)
{
const uschar *p = *pp;
int ch = *(++p);
+ if (ch == '\0') return **pp;
...
*pp = p; /* fail был здесь - возвращаем ptr на следующий (за границей NTS) байт. */
return ch;
}Т.е. ранее (до фикса) возвращенный указатель в *pp "тупо" указывал на следующий после последнего '\\' символ (за '\0') в буфере и рутина вызывающая string_interpret_escape при проверке внутри циклов типа while (*p) {...} продолжала исполнение уже за границей строки пока не ловила следующий '\0' или собственно BO.
Учитывая что string_interpret_escape пользуется почем зря (от фильтров до string expansion) мне вот совсем непонятно почему exim разрабы ограничились "BO с возможным RCE на SNI-data в процессе TLS-nego"… когда оно вот прямо само напрашивается.
И если вернуть или выдернуть что-то дельное на стадии TLS-negotiation таким образом действительно вряд ли получится, то например сценарии вида "отправить в bounce атакующему кусок памяти exim" и подобные фишки выглядят вполне себе ничего… а развернуться в exim даже при дефолтных/стандартных конфигах есть где.
Я не большой любитель теорий заговора, но как-то оно не очень выглядит...
Я: Just curious, whether Exim is regularly tested for vulnerabilities as it's developed?
Jeremy Harris: Please feel free to volunteer your time and expertise.
Всё ближе час, когда, думаю, таки начну поглядывать на Postfix — если не хватит духу заняться тем, на что намекнули.
Но я прекрасно понимаю, что 1) это не означает, что в целом Postfix надёжнее, и 2).достаточно давно уже пользуюсь Exim, как-то привык уже.
А так да, ответить могут ровно так же.
В целом, если так грубо, Exim сейчас популярнее. Так что, если в результате которого по счету CVE бага, его «очередь пройдет» и все перейдут на Postfix, думаю, там обнаружится все тоже самое.
Для меня между Exim/Postfix отличия слились, грубо говоря, в то, что Postfix модульная система :) Еще в Postfix конфиги лаконичнее и проще, но это субъективно.
Спешу однако обрадовать — 4.92.2 уже устарела / Хабр
Теперь опять Ваша очередь :)
Пропатчил Exim — пропатчь еще раз. Свежее Remote Command Execution в Exim 4.92 в один запрос