В Exim обнаружили критические уязвимости, позволящие выполнить на сервере произвольный код

Детали и пруфы они, получается, не опубликовали?

Я потыкался по их сайту — такое ощущение, что нет.

Мол, разрабов уведомили, ждемс.

Судя по тексту, они уже год как передают им последнее китайское предупреждение. Толи разработчики exim превратились в тыкву, толи эти CVE не представляют реальной опасности.

Есть ещё варианты «сложно починить» и «полезно, попросили оставить»

толи эти CVE не представляют реальной опасности.

У CVE-2023-42115 score 9.8, почти максимум

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

exploitability:

• attack verctor: network
• attack complexity: low
• privileges required: none
• user interaction: none
• scope: unchanged

impact:

• confidentiality impact: high
• integrity impact: high
• availability impact: high

Я не удивлён такому от exim-а, от него за км запахом дыр несёт.

Это вопрос доверия к тому, кто поставил эту оценку. Вот с curl недавно был случай: https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/.

Он же на сишее написан. Чего вы ещё ожидали? Невозможно написать на си программу длиннее трёх строк и не заложить при этом парочку уязвимостей.

Си тут ни при чём. Просто традиционно всё что связано с email пишут какие-то странные люди, начиная с почтовых rfc и sendmail-а десятки лет назад. Как сервера так и клиенты. Хотя сейчас наверно уже есть что-то вменяемое (например я не видел postfix, может он норм).

Еще одно доказательство дырявости почты.

К счастью все больше и больше умных людей и компаний от нее отказываются.

HRу надо научиться новой методике проверки адекватности кандидата:

- Здравствуйте, собеседуемый, у вас есть email ?

- Есть.

- Извините, на данный момент вы нам не подходите.

А что касается самого Exim - что ж, лучше него еще ничего не придумали. Тот второй, который postfix - боль, головная боль, жопоболь.

Это надо у него во ВКонтакте спросить, я правильно тебя понял?

позволяет добиться записи своих данных за границами выделенного буфера

вызвана копированием данных от пользователя в буфер фиксированного размера без проверки необходимого размера

Written in C

Классика

Просто традиционно всё что связано с email пишут какие-то странные люди

Какие забавные маневры. У любителей сишки всегда так: куда не плюнь – везде неправильные люди.

Сплоит бы. Хочу вернуть почивший sibmail себе обратно, а то могут принимать почту по старому адресу левые люди

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

У любителей сишки всегда так: куда не плюнь – везде неправильные люди.

Вообщет это классика лора :)

Разработчики Exim вообще странные люди. Я как-то им писал, просил сделать вывод логов на stdout, чтобы в контейнере не нужно было кудесничать с симлинками. Мне ответили, что не нужно, потому что, мол, разную информацию надо писать в разные логи. А мультилог? Не слышали, не нужно.

Qmail был норм, но вообще ничего не умел.

Не зря он так же известен, как patchmail.

В свое время был дефолтом в линуксах.

Си тут ни при чём.

Спасибо, поржал =)

Просто традиционно всё что связано с email пишут какие-то странные люди

e-mail тут можно заменить на все, что угодно, например на ядро, да на все, что написано на Си.

Странно, что такие ошибки не были выявлены статическим анализатором кода. Или на их основе как-раз и были выявлены проблемы?

Забавляют комментарии насчет языка, когда во всех трех проблемах «разработчик не проверил пользовательский ввод, разработчик не проверил пользовательский ввод, разработчик не проверил пользовательский ввод».

Забавляют комментарии насчет языка, когда во всех трех проблемах «разработчик не проверил пользовательский ввод,

Больше удивляет квалификация разработчиков и 1000 глаз, которые типа смотрят код.

Да и язык виноват и там сам это прекрасно понимаешь. Точнее язык позволяет писать безопасно, но этим тайным навыком обладают единицы людей на планете, если они вообще есть.

Да и язык виноват и там сам это прекрасно понимаешь

Граната не виновата, что её в руки взяла макака

Забавляют комментарии насчет языка, когда во всех трех проблемах «разработчик не проверил пользовательский ввод, разработчик не проверил пользовательский ввод, разработчик не проверил пользовательский ввод».

Это легко говорить сидя на диване, но когда тебе нужно 20 тысяч раз в коде проверить пользовательский ввод, причем, это нужно сделать в дополнение ко всей остальной работе, то вопрос уже не стоит как «забудет ли програмист проверить ввод?», вопрос стоит «что произойдет, когда программист снова забудет проверить ввод?». И именно вот здесь языки C и в большой степени C++ отличаются от подавляющего большинства ЯП ответом «тогда злоумышленник выполнит произвольный код».

Я хочу подчеркнуть, что этого не было в фортране, этого не было в коболе — это «изобретение» разработчиков Си, создавших самый уязвимый ЯП в мире, который позже был превзойден разве что PHP, и то не факт.

В свое время был дефолтом в линуксах.

qmail ? Да никогда !

Ты с sendmail'om перепутал

Граната не виновата, что её в руки взяла макака

Я вижу по CVE =)

Так может гранаты убрать от неразумных макак ?

Так может использовать появившиеся за последние 30 лет средства статического и динамического анализа? Применять безопасные практики? Следовать стандартам? Да ну, лучше придумать еще один псевдоязычок с инопланетным синтаксисом, который ну точно будет безопаснее*

*но это не точно.

Вангую что в exim есть функции на 400-500 строк, сотни функций в одном файле, макросы на 50-60 строк и миллион однобуквенных переменных вперемешку с волшебными цифрами.

Так может гранаты убрать от неразумных макак ?

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

Так может использовать появившиеся за последние 30 лет средства статического и динамического анализа? Применять безопасные практики? Следовать стандартам?

А оно помогает ? Ядру линукса статистический и динамический анализ помог ? А exim'у ?

вопрос стоит «что произойдет, когда программист снова забудет проверить ввод?»

Ещё и «опять»?! Дисциплинарное взыскание, очевидно, и постановка вопроса о профпригодности. Да и вообще, слова «проверить ввод» несколько вводят в заблуждение и создают некорректную и примитивную картину того, что требуется делать.

Следовать стандартам?

Это тем самым стандартам, которые привели к трешу с strict aliasing и прочим официально разрешенным undefined behavior? Отличная история. Осталось услышать советы «следовать корану» и «ставить свечки в церкви».

Так может гранаты убрать от неразумных макак ?

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

Хороший вопрос, потому что Я ЗНАЮ СИШНИКОВ. Знаете поговорку про «нет такого преступления, на которое капиталист не пойдет ради двукратного увеличения прибыли»? Есть такая поговорка про сишников «нет такого неопределенного поведения, на которое сишник не пойдет ради увеличения производительности на 2%» — сишники серьезно не видят подвоха в этой фразе, отвечая вроде «ну так ты правильно пиши код» и «2% производительности на дороге не валяются», они в упор не видят в таком мировозрении подвоха.

Ещё и «опять»?! Дисциплинарное взыскание, очевидно, и постановка вопроса о профпригодности.

Именно это и сделали в самом начале истории, когда один студент положил все сервера в институте. То есть, выгнали из института, наложили дисциплинарное взыскание. Правда, программы после этого не перестали быть уязвимыми. К сожалению (или к счастью), реальный мир и бюрократия пересекаются довольно редко.

ЗНАЮ СИШНИКОВ

Я вас поздравляю. А я среди нескольких десятков таких не замечал, дальше что?

А оно помогает ? Ядру линукса статистический и динамический анализ помог ? А exim’у ?

Оно помогает от проблем, которые приписывают си. Есть пруфы, что exim проходил регулярные проверки или хотя бы автоматические прогоны при компиляции?

ЗНАЮ СИШНИКОВ

Я вас поздравляю. А я среди нескольких десятков таких не замечал, дальше что?

Это значит, что ты сам сишник.

А оно помогает ? Ядру линукса статистический и динамический анализ помог ? А exim’у ?

Оно помогает от проблем, которые приписывают си.

Статический анализ сишного кода весьма затруднителен, динамический анализ позволяет просто показать ошибки, которые в норме в Си скрыты, то есть тихо повреждают память. Сколько сишный код не отлаживай — а в нем все равно будут оставаться лютейшие баги с повреждением памяти. Только hello world можно достаточно полноценно отладить.

Может быть, после этого его перестанут в debian пихать как default-mta

Чем сабж лучше Postfix? За столько лет никто так и не смог объяснить.

Чем сабж лучше Postfix?

Во-первых, гибкостью. Это практически такой фреймворк почтовика. Что в конфиге напишешь, так он и будет работать.

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

В-третьих, действительно хорошая документация.

Ну и по моим наблюдениям, поддержка всякого нового и интересного там появляется раньше, чем в постфиксе.

что этого не было в фортране

Чего не было в Фортране? В Фортране времён Кобола вобще не было динамической памяти, тогда стандартно создавали два больших массива (REAL и INTEGER) и в них всё хранили. Если не проверять размер входных данных, то одни данные могли перезаписать другие.

А ещё был COMMON-блок, и не все компиляторы отслеживали выход за границу COMMON-блока. А когда появились массивы динамического размера, опять не все компиляторы контролировали выход за границы такого массива... Я переписывал несколько чужих программ, которые собирались и работали по FORTRAN PowerStation 1.x и крошились по памяти под FPS 4.

Растовикам не приходится лепить глупейшие отмазки про неправильных людей

Невероятное заключение, Холмс. Но как?

Статический анализ сишного кода весьма затруднителен

Статический анализ сишного кода проще чем для любого другого языка. Любой бомж может написать свой анализатор. Посмотрите, например на бомжей из PVS.

Сколько сишный код не отлаживай — а в нем все равно будут оставаться лютейшие баги с повреждением памяти

Вы либо никогда не писали на си и повторяете как обезьяна либо не умеете пользоваться инструментами.

Толи разработчики exim превратились в тыкву, толи эти CVE не представляют реальной опасности.

учитывая что ZDI деньги платит за баги (им еще и скан паспорта нужно послать), дыры-таки есть и оценены они верно. А вот то, что после «Next contact with ZDI was in May 2023. Right after this contact we created project bug tracker for 3 of the 6 issues. 2 high scored of them are fixed (OOB access)» оно так в дистрибутивы и не попало, какбы намекает на то, кто здесь неправ.

Разработчики Exim вообще странные люди. Я как-то им писал, просил сделать вывод логов на stdout, чтобы в контейнере не нужно было кудесничать с симлинками.

Бугагага. Почтарь в контейнере… Вот уж воистину «докер головного мозга». Нет, я видел всякое. Я даже видел маразм, когда в контейнер пихали томкат. Но вот почтарь….

Во-первых, гибкостью. Это практически такой фреймворк почтовика. Что в конфиге напишешь, так он и будет работать.

Его формат конфига - это первое, что намекает на хроническую костыльность и забагованность.

В-третьих, действительно хорошая документация.

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