Опубликован внеплановый выпуск почтового сервера Exim 4.90.1 (http://exim.org/) в котором устранена (http://seclists.org/oss-sec/2018/q1/145) критическая уязвимость (https://exim.org/static/doc/security/CVE-2018-6789.txt) (CVE-2018-6789 (https://security-tracker.debian.org/tracker/CVE-2018-6789)), потенциально позволяющая организовать удалённое выполнение кода на сервере при обработке сообщений со специально оформленными блоками в формате BASE64.Исправление доступно в виде патча (https://git.exim.org/exim.git/commit/062990cc1b2f9e5d82a413b...). Обновления пакетов пока сформированы только для Debian (https://security-tracker.debian.org/tracker/CVE-2018-6789) и FreeBSD (http://www.vuxml.org/freebsd/316b3c3e-0e98-11e8-8d41-9765715...). Проблема остаётся неисправленной в Ubuntu (https://usn.ubuntu.com/usn/), Fedora (https://bodhi.fedoraproject.org/updates/?releases=F27&type=s...), openSUSE (https://lists.opensuse.org/opensuse-security-announce/2018-02/), SUSE (https://bugzilla.suse.com/show_bug.cgi?id=1079832), RHEL/EPEL (https://bugzilla.redhat.com/show_bug.cgi?id=1543269). Изначально информацию о проблеме планировалось раскрыть через неделю, но скоординированному выпуску обновлений помешало нарушение эмбарго одним из дистрибутивов, досрочно опубликовавшем исправление.
Проблема вызвана ошибкой в функции base64d(), которую можно использовать для инициирования переполнения буфера. По мнению разработчиков Exim уязвимость достаточно трудна для эксплуатации, но выявивший уязвимость исследователь заявил, что у него уже есть работающий эксплоит. В выпуске Exim 4.90.1 также устранено несколько ошибок (ftp://ftp.exim.org/pub/exim/exim4/ChangeLog), в том числе переполнение буфера в коде верификации DKIM, которое явно не помечено как уязвимость.URL: http://seclists.org/oss-sec/2018/q1/145
Новость: https://www.opennet.ru/opennews/art.shtml?num=48054
Немного огорчает, но исправляют же.
Интересно, как давно эта ошибка есть в коде?
Какой дистрибутив оказался впереди планеты всей?
> Какой дистрибутив оказался впереди планеты всей?"Обновления пакетов пока сформированы только для Debian и FreeBSD.", что как-бы намекает.
> переполнения буфераклассика сишного жанра
а ты зачем такой толстый?
то есть это не только у сишных прог такая болезнь? назови мне реализацию base64d на любом другом языке, где бы наблюдалось переполнение буфера с потенциальной возможностью выполнить код на сервере. Хотя бы одну назови.
В Postfix с этим проблем нету, а для макак которые используют Си как хотят есть Rust,
то есть хочешь сказать, Exim писали макаки?
Да естественно, не OpenBSD же.
>то есть хочешь сказать, Exim писали макаки?Вы код то его видели? Пример из spool_in.c:
if (Ufgets(big_buffer, big_buffer_size, f) == NULL) goto SPOOL_READ_ERROR;
p = big_buffer + Ustrlen(big_buffer);
while (p > big_buffer && isspace(p[-1])) p--;
*p = 0;
if (!isdigit(p[-1])) goto SPOOL_FORMAT_ERROR;
while (p > big_buffer && (isdigit(p[-1]) || '-' == p[-1])) p--;
gid = Uatoi(p);
if (p <= big_buffer || *(--p) != ' ') goto SPOOL_FORMAT_ERROR;
*p = 0;
if (!isdigit(p[-1])) goto SPOOL_FORMAT_ERROR;
while (p > big_buffer && (isdigit(p[-1]) || '-' == p[-1])) p--;
uid = Uatoi(p);
if (p <= big_buffer || *(--p) != ' ') goto SPOOL_FORMAT_ERROR;
*p = 0;В postfix код намного читаемее и чище.
Форматирование оригинальное, неиспорченное.
> Форматирование оригинальное, неиспорченное.Что тебе не нравится? Учился чел указатели использовать. Заодно закоммитил вот. Вебню так вообще целиком по этой технологии делают, даже работает как-то :).
Заодно приведите, пожалуйста, вариант, который вы лично сочли бы более читабельным
Вот так: https://pastebin.com/dc82ZNKB
Примерно так. Этот код будет работать не совсем так, как в exim, потому что он не будет терпеть символов '-' в середине чисел.
Exim похоже пишут те, кто процессоров быстрее 33 МГц и памяти за 640КБ не видели никогда. Иначе невозможно обьяснить экономию на количестве символов в исходниках и обмазывание goto.
А дык ты с Больших Дрыщей только чтоприехал?
Exim написал чувак который половину своей жизни был программером IBM mainframe(s) ...
Ну и писали тогда так :) А форматирование стандартное для BCPL-я :-)
Почему оно до сих пор так ... ну это уже совсем другая история!(С)
> Exim написал чувак который половину своей жизни был программером IBM mainframe(s) ...Оу, действительно. Заглянул в википедию -- это ведь такое старпёрище, что у меня всякое удивление пропало от того, как можно писать столь говённый код.
В коде видно, что principle of the least surprize этому Хазелу не известен совершенно. Мысль о том, что программы пишутся для людей, а не компьютеров тоже ни разу не освещала его внутричерепные пустоты. Код напоминает ассемблерную лапшу для тех самых 286 и для даже более младших микропроцессоров. Лапшу, от которой Дейкстру хватил бы удар, потому что там считалось, что экономия двух байт на стеке стоит того, чтобы уже запутанный код запутать ещё больше. При этом код совершенно игнорирует способности современных компиляторов к оптимизации, он высокооптимизированный, но для компилятора C из 80-х годов, который генерировал машинный код более похожим на исходный, чем современный компилятор генерирует с флагом -O0 для удобства отладки. Кстати встаёт вопрос, не становится ли этот код медленнее из-за демонстративного игнорирования способностей компилятора к оптимизации.
Пока я втыкал в этот код, я вспоминал одного из преподавателей информатики в своей молодости, который втирал мне, что инициализируя переменную типа float целым числом, надо в сорце обязательно писать не 'float a = 2', а 'float a = 2.0'. Само по себе может и здравая мысль (rust, например, требует писать именно так), но аутентичное объяснение этому было феерическим: если написать 2, то компилятор сгенерирует код, который будет преобразовывать (int)2, к (float)2.0, а это (sic!) замедлит программу. Будучи ещё молодым и глупым тогда, двадцать лет назад в конце 90-х, я слушал его со скепсисом, подозревая, что меня где-то нaёбывают (благоразумно сохраняя молчание: мне был нужен зачёт), но в в конце 10-х -- через двадцать мазафака лет -- я вижу "продакшн" код, который был написан на тех же принципах.
Вот смотришь в этот код и удивляешься: как так можно? Но всякое удивление пропадает, когда узнаёшь что автор всю жизнь отработал в IT, вышел на пенсию десять лет тому назад, и уже успел написать мемуары: многим людям не удаётся испытать на себе, что такое открытость к новым идеям, но лишь очень немногим удаётся сохранить эту открытость до старости.
>многим людям не удаётся испытать на себе, что такое открытость
> к новым идеям, но лишь очень немногим удаётся сохранить эту открытость
> до старости.Big Brother Patches You!
> blah-blahТо есть писать быстрый и компактный код теперь уже не модно, я правильно понял основную мысль?
Во-во. Облака же. Безразмерные. Нафига быстрый код? Надо красивый и понятный!
>> blah-blah
> То есть писать быстрый и компактный код теперь уже не модно, я
> правильно понял основную мысль?Нет не правильно. Сегодня как раз модно писать быстрый и компактный код, но сегодня быстрый и компактный код быстрее и компактнее чем то, что есть в exim. Скажем очень полезно использовать for'ы и индексы, вместо адресной арифметики -- компилятору будет проще разобраться в происходящем, и может быть компилятор, например, векторизует код, и будет при выделении токена тратить меньше одного такта процессора на символ строки. А если он не векторизует, то вынос всех этих циклов перебора char'ов в отдельные функции, позволяет программисту измываться над этими циклами как угодно, хоть векторизовать руками. Пока же повторное использование кода достигается копипастом, попытки написать более сложный и более быстрый код упрутся в то, что придётся каждый эпизод копипаста переписывать ручками, привнося тучи багов, которые отлавливать будут использованием в продакшне.
Современные компиляторы и современные процессоры отличаются от того, что было в 80-х: сегодня есть куча длинных конвееров, огромные кеши, переупорядочивание команд и спекулятивное выполнение. Если оптимизировать руками, то надо учитывать все эти вещи. Если оставлять оптимизацию компилятору, то это надо делать так, чтобы не мешать ему. Попытки же оптимизировать код под 8086 могут привести к тому, что на современном проце они дадут замедление кода.
При этом, я отмечу, все возможные приросты скорости в данном конкретном случае совершенно бессмысленны, потому что речь идёт о разборе конфига: это код, выполнение которого занимает какие-то смешные доли процента от общего времени работы exim.
А компактным его код совершенно определённо называть не стоит. Мой код больше, но если ты присмотришься, там 90% уходит в библиотеку и будет использоваться неоднократно. То есть, если в этом стиле переписать весь exim, то кода станет меньше. Вероятно можно взять и переписать только вон ту функцию парсинга конфига, и уже тогда станет видно сокращение размера. Но с учётом того, что exim парсит не только конфиги, а довольно много чего, и весь парсинг в exim можно перевести на использование библиотечного кода для парсинга, то общий размер кода занятого парсингом можно сократить таким образом в разы.
Кроме того, у библиотеки состоящей из маленьких и повторно используемых функций есть ещё один бонус: её возможно покрыть тестами. Вот его код покрывать тестами ты убьёшься.
Был такой чудо-процессор Itanium, вся архитектура которого планировалась исходя из того, что решать, что быстро, а что медленно, будет не программист, а компилятор.Это было не в 80-х.
Это сдохло в страшных муках.
P.S. Я прекрасно понимаю, что у красивого кода есть плюсы, касающиеся сопровождения. Но когда вижу, что´ пишут люди, которые никогда не видели, в какой машинный код транслируется то, что´ они пишут, то моя рука тянется. Мнение Фролова тут разделяю целиком и полностью.
> Был такой чудо-процессор Itanium, вся архитектура которого планировалась исходя из того,
> что решать, что быстро, а что медленно, будет не программист, а
> компилятор.
> Это было не в 80-х.
> Это сдохло в страшных муках.Ты передёргиваешь. Сдох процессор, а не идея.
> P.S. Я прекрасно понимаю, что у красивого кода есть плюсы, касающиеся сопровождения.
> Но когда вижу, что´ пишут люди, которые никогда не видели, в
> какой машинный код транслируется то, что´ они пишут, то моя рука
> тянется. Мнение Фролова тут разделяю целиком и полностью.Спорим, что мой код быстрее, чем код из Exim? Мне только нужно будет расставить там static inline -- я не делал этого пока писал код, а после этого не стал делать ввиду картонности этого кода. Но я могу посмотреть, расставить там эти подсказки процессору, после чего скормить ему миллион строк для парсинга, замерив время. И коду из exim скормить ровно тот же миллион строк, причём ровно тем же способом, и тоже замерить время. И мой код будет _заметно_ быстрее. То есть не на 1-2%, а процентов на 10%. Потому что мой код будет оптимизирован компилятором для -march=native, а код из Exim будет оптимизирован для 8086 вне зависимости от флагов компиляции.
Я сравнил из любопытства. Отказ от оптимизации в старпёрском стиле сократил время выполнения на 30%:uname -srp
Linux 4.15.1-gentoo-amdgpu Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
C version: -863074811, -1605719530real 0m0,206s
user 0m0,192s
sys 0m0,014s"Asm" version: -863074811, -1605719530
real 0m0,303s
user 0m0,290s
sys 0m0,013sМожешь проверить в своей системe: https://github.com/amty/string-handling-styles
Кстати, если сделать du -b *version, то:12720 asm-version
12784 c-versionМоя версия на 64 байта длиннее. Если скомпилировать с -Os, то разница более значительна:
8568 asm-version
12728 c-versionПри таком варианте моя версия начинает отставать по скорости от exim'овой, добавляя ~15% времени выполнения:
real 0m0,450s
vs
real 0m0,395sИтого вывод. Старпёрский стиль -- это оптимизация по размеру кода, экономия байтов. Что объяснимо, в древности связь между количеством выполненных процессором инструкций и временем их выполнения была гораздо сильнее, чем сейчас, и цена памяти была совершенно иной. Так что если нужно поднять MTA на очень ограниченных ресурсах, в первую очередь по памяти (т.е. если этой памяти <100Mb), то имеет смысл, по-крайней мере, рассмотреть идею поставить Exim, скомпилировав его с -Os.
> Был такой чудо-процессор Itanium, вся архитектура которого
> планировалась исходя из того, что решать, что быстро, а что медленно,
> будет не программист, а компилятор.
> Это было не в 80-х.
> Это сдохло в страшных муках.Жаль, что Вы чайник, который никогда ничего _реально_ не сможет оптимизировать руками на более-менее современных процессорах (скажем, x86_64) с развесистым регистровым файлом.
Иначе не пёрли бы вот так внаглую на рожон с глупостями.
Ну а то, что американцы не осиливают действительно сложные проекты, к тому же построенные на заимствованных идеях -- не новость.
Да я вообще не программист. Скорее тыжпрограммист.
Красиво пишете.
Вот ещё бы взяли, и сделали с Exim то, что описали - вообще вам цены не было.
> то есть хочешь сказать, Exim писали макаки?хуже -- прохвессура; в результате не новость, а "скучно, девочки".
> В Postfix с этим проблем нету, а для макак которые используют Си
> как хотят есть Rust,
unsafe для дурачков
Поэтому от во __всех__ ржавых программах :)
> назови мне реализацию base64d на любом другом языке, где бы наблюдалось переполнение буфера с потенциальной возможностью выполнить код на сервере. Хотя бы одну назови.На pascal без проблем реализуется. Он средствами самого языка имеет тип LString и bounds checking. Там при работе даже с указателями на массивы в принципе нельзя мимо промазать, если они правильно типизированные. Равно как и запихать в строку больше чем под нее при описании типа выделено. Кстати интеля до сих пор не упразднили инструкцию процессора bound, которая и выполняет такую проверку. Но у компилятора на этапе компиляции должна быть точная информация о типе указателя, чтобы знать размер массива.
Хотя можно задаться целью и невозбранно выстрелить себе в ногу используя asciiz строки и безтиповые указатели на байт, а также разнообразные околозапрещенные трюкачества при манипуляции со строками мимо RTL, лазая по памяти через pchar указатели. Но если программист хочет стрелять себе в ногу, то это уже его проблемы.
> если программист хочет стрелять себе в ногу, то это уже его проблемы.Суть в том, что если ни один программист не захочет выстрелить себе в ногу, то сишники все равно стреляют. Только сишники. Исключительно сишники.
Предвосхищая твой аргумент от макак, -- см. комментом выше.
> Суть в том, что если ни один программист не захочет выстрелить себе в ногу, то сишники все равно стреляют. Только сишники. Исключительно сишники.Язык располагает. Си хорошо ложился на PDPшную архитектуру. Там имел смысл всех этих сишных трюкачеств. Фактически си тогда был относительно несложным препроцессором к макроассемблеру, и все эти затейливые автоинкрементные и автодекрементные косвенные адресации, выражения с чудовыми значениями и прочие затейливости, которые ныне несутся в свет как достижения мало того что первородный смысл потеряли, так еще и выросли в лютейший геморрой, когда всю эту легаси на другие архитектуры потащили.
Именно. Приятно видеть здесь понимающего человека.
Ой, аж два человека понимающих отличие PDP-11 от x86. Ну может хоть на этот раз кто-то мне откроет глаза на принципиальную разницу их архитектур и ассемблеров. А то в прошлый раз никто не справился.
> Ой, аж два человека понимающих отличие PDP-11 от x86. Ну может хоть
> на этот раз кто-то мне откроет глаза на принципиальную разницу их
> архитектур и ассемблеров. А то в прошлый раз никто не справился.Для наглядности могу привести наиболее яркое принципиальное отличие: у PDP-11 в отличие от x86 ВСЕ операции над константами, регистрами, ячейками памяти, косвенной адресации и ссылками в любых сочетаниях выполняются одними и теми же командами, например:
CMP <регистр>,<память>
MOV <ссылка>,<регистр>
BIS <счетчик команд>,<ссылка>
и т.д.Также ВСЕ регистры (включая адресный, стековый и пр. - равнозначны!) Т.е. допустимы любые операции над ними, т.е. ты можешь прямо писать в адресный регистр, использовать его в арифметических операциях и т.д.
CMP <счетчик команд>,<память>
SUB <константа>,<счетчик команд>
DEC <указатель стека>
Ты бредишь!
Принципиальное? Эк вас забрало.
Вот практическое могу.
В PDP-11 возможна адресация ячейки памяти как регистра, откуда проистекают все эти приятности в виде, к примеру, косвенной адресации и автоинкре(вар. - декре)ментов. Корни, насколько я понимаю, лежат в архитектуре процессоров, где в случае с DEC используется общая шина данных и адреса. В отличие от.
Сейчас уже много чего подзабылось, но в своё время я мог прямо в машинном коде писать фрагменты кода, минуя ассемблер. Это как ещё одно практическое преимущество.
> Принципиальное? Эк вас забрало.Адекватное требование в ответ на тот пафос про жуткую завязку С на архитектуру PDP и проблемность его при переносе на другие архитектуры.
> В PDP-11 возможна адресация ячейки памяти как регистра, откуда проистекают все эти приятности в виде, к примеру, косвенной адресации и автоинкре(вар. - декре)ментов.
Ну так покажи пример того, чего нет в x86. Там тоже есть инкременты/декременты и косвенная адресация, причем многих видов.
> где в случае с DEC используется общая шина данных и адреса.
И что в этом хорошего?
> Сейчас уже много чего подзабылось
Подозреваю, что это основная причина ностальгических вздохов по PDP-11.
> Ну так покажи пример того, чего нет в x86. Там тоже есть инкременты/декременты и косвенная адресация, причем многих видов.Единые команды как для работы с регистрами, так и с памятью и, конечно, двойная косвенная адресация да с инкре(декре)ментом. В одну команду. В итоге то, что в DEC реализуется одной строкой, в Intel требует в разы больше.
Пример DEC (2 байта)
MOV @(R2)+,@(R2)+То же для Intel (12, если не обсчитался, байтов) + засранные регистры. Можно покороче, но не сильно и ценой ещё засёра флагов.
mov si,[bx]
mov di,[bx+2]
lea bx,[bx+4]
mov ax,[si]
mov [di],axКак это сказывается на производительности тоже примерно понятно.
Вот это уже интересно. Спасибо.
Просматривая набор инструкций PDP-11 я больше обратил внимание на сами инструкции, не уделив должного внимания режимам адресации.Однако хотелось бы отметить несколько моментов.
1. В предложенной реализации на x86 нет нужды использовать еще и di регистр, можно было дважды задействовать si.
2. Данная инструкция хоть и любопытна, но с точки зрения С(а разговор шел о нем изначально) не выглядит особо полезной. Я как то не могу сходу вспомнить код, в котором бы заполняли массив парами указателей на word c последующим проходом по нему и переносом значения указываемого каждым нечетным элементом в ячейку указываемую соответствующим четным. И я сильно сомневаюсь, что компилятор С тех времен мог распознать такую ситуацию и воспользоваться данной инструкцией.
Я не являюсь экспертом в сях, но действительно ряд конструкций выглядят как наследие PDPшной архитектуры. Да и логично это, по очевидным причинам.
Это понятно. Но есть огромная разница "архитектура pdp оказала некоторое влияние на язык" и "мало того что первородный смысл потеряли, так еще и выросли в лютейший геморрой, когда всю эту легаси на другие архитектуры потащили". С первым никто не спорит, а второе либо передергивание, либо результат незнания как pdp-11, так и x86.
>Корни, насколько я понимаю, лежат в архитектуре процессоров, где в случае с DEC используется общая шина данных и адреса. В отличие от.Да мультиплексируемая шина адреса/данных много где использовалась. Например, локальная шина процессоров 8085, 8086, шина межсоединений Multibus II. PCI, жива и поныне, тоже имеет мультипленксируемые линии адреса/данных. На систему команд Intel совмещённость не повлияла. Поэтому и на систему команд DEC вряд-ли как-то влияла.
Хм, ну не знаю. По мне очевидно что система машинных команд растёт из архитектуры процессора. Иначе и быть не может.
> А то в прошлый раз никто не справился.это верный признак того, что тебе - повые... а не разницу.
то что тут понаписали, разумеется, мура, это совершенно не то что имел в виду ram_scan (и к тому же неверно).
То о чем он - как раз была непринципиальная, просто специфическая.это команды, использовавшие параметры вида (Rn)+ или -(Rn) - то есть полный эквивалент *i++ (и, да, этот + означал +2, потому что у нее обычные команды работают с двухбайтовыми словами, то есть это именно адресная арифметика ;-)
Заметим, что постфиксного -- или префиксного ++ не было, по очень простой причине - всего два бита отвечали за этот фокус (если взведены оба, получался a[i] ;) - хотя язык си такое и позволял с самого начала, и нигде и никогда в нем не утверждалось что надо/не надо использовать только один вариант. И если *i не int, а элемент структуры неведомой длины, тоже ничего автоматически в одну команду не транслировалось, автоинкремент работал только с указателями на двухбайты.так что дело не в том что Си использует специфические фичи процессора pdp, а скорее в том, что инженеры тех времен иногда думали примерно одинаково с программистами, и считали это удобным и правильным.
Например, процессор умел одной командой что-нибудь вроде *(i+10) (заметьте, не i+=) - но что-то я не вижу кода, который пользуется такими конструкциями. В ассемблере было удобно, в языке высокого уровня это была бы обычная структура.
> это верный признак того, что тебе - повые... а не разницу.Нет, мне действительно интересно. Но пока ничего такого не увидел.
> то что тут понаписали, разумеется, мура ...и к тому же неверноВот и мне так кажется.
> это команды, использовавшие параметры вида (Rn)+ или -(Rn) - то есть полный эквивалент *i++Всего то? И вот из-за этой мелкой фишки надо было с таким пафосом вещать "выросли в лютейший геморрой, когда всю эту легаси на другие архитектуры потащили"?
> Нет, мне действительно интересно.интересно - ищешь эмулятор и мировскую книжку по "язык ассемблера" (или ее оригинал, но смысла в том немного, тогда их переводили хорошие переводчики), и вперед.
Ну или ищешь по помойкам недоразломанный microVAX, он вообще-то поинтересней будет, только вот оживить его - тяжкий труд.> Всего то? И вот из-за этой мелкой фишки надо было с таким пафосом вещать "выросли в лютейший
> геморрой, когда всю эту легаси на другиетам всей легаси - существование адресной арифметики и косвенной адресации вообще.
Покажите мне, на какой такой платформе их нет?
> интересно - ищешь эмулятор ...Я не сказал, что мне интересно на нем программировать, мне интересно понять причину, по которой о нем говорят с таким придыханием. А так список мнемоник я и в прошлый раз просмотрел, ничего особо интересного по сравнению с x86 не нашел.
> там всей легаси - существование адресной арифметики и косвенной адресации вообще. Покажите мне, на какой такой платформе их нет?
Так и я о том же. Но там вверху один раскрыл незрячим тайны мироздания, а другой выразил ему понимание. А стоило предложить перейти к конкретике, как оба сгинули в тумане.
> А стоило предложить перейти к конкретике, как оба сгинули в тумане.Прошу прощения у xm, на момент написания предыдущего комментария его ответа с конкретикой еще не было.
> Я не сказал, что мне интересно на нем программировать, мне интересно понять причинуесли ты не программист - что ты надеешься там "понять"?
чтобы понять - надо программировать.
Оно действительно было сделано инженерами и для инженеров. Не несло ненужной легаси, не шаталось вместе с линией партии "сначала попытаемся сделать хорошо для языков высокого уровня, ой, нет, не получается, давайте сделаем такой почти риск, только с непредсказуемой длиной команды и нечитаемым кодом, пусть наоборот, разработчики компиляторов попрыгают..." и так без конца.ну и проиграло, по сути, не инженерной, а маркетинговой командой. Как и DEC целиком.
> Суть в том, что если ни один программист не захочет выстрелить себе
> в ногу, то сишники все равно стреляют. Только сишники. Исключительно сишники.Странно, почему же тогда основной объем взломов через дырявую вебню идет? Ее вроде на си редко пишут. Хоть это и можно иногда.
> Странно, почему же тогда основной объем взломов через дырявую вебню идет?дай угадаю: потому что вебня чаще всего имеет интересное свойство торчать в интернет.
И при этом штука достаточно массовая (дырявых вордпрессов в мире явно поболее будет чем дырявых exim, да и вообще каких бы то ни было доступных извне mta), а проблемы в ней двадцать лет не меняются - injections/xss/mitm.
>> Странно, почему же тогда основной объем взломов через дырявую
>> вебню идет?
> дай угадаю: потому что вебня чаще всего имеет интересное свойство
> торчать в интернет....в отличие от сишного веб-сервера ;-]
> назови мне реализацию base64d на любом другом языке, где бы наблюдалось переполнение буфера с потенциальной возможностью выполнить код на сервере. Хотя бы одну назови.Легко, C++ подходит под любой другой.
https://android.googlesource.com/platform/frameworks/av/+/55...^!/
А ты на чем пишешь, если не секрет?
любопытная тактика: выпросить язык у оппонента, чтобы переключить внимание с чисто сишной ошибки "переполнение буфера с выполнением кода на сервере" на проблему абсолютно другого языка.Ну хорошо, я пишу на хаскеле. Критикуй хаскель.
Ты пишешь на Хаскеле и не знаешь, что в нем можно легко получить buffer overflow, segfault и прочие прелести?
Пока слабо. Нужна разгромная критика, такая, чтобы все забыли о си и переполнении буфера с возможностью выполнения кода на сервере.
Кому нужна? Одному толстячку? Пусть худеет.
А вот и переходы на личности. Но я тебя понимаю: куда интереснее обсуждать, кто кого траллирует, чем исключительно сишные переполнения буфера и выполнение кода на сервере.
Ой, да тут всё ешё проще - покахи мне SMTP сервер класса Exim'a на Haskell'e ... и всё - все жЫрненькие пошли жрать ненавистный С :-) Ибо "есть прекрастные языки программирования ... а есть на которых и в правду пишут софт!" (С) :-)
И что за дистр слил первым?
Скорее всего OpenWall
Понимаю желание нас троллить после анонса такого спорного (в том числе на наш же взгляд) проекта как LKRG (мы знали на что шли), знаю что кормить не положено, но ведь кто-то может и всерьез воспринять. ;-) На исходный вопрос: я не знаю какой дистрибутив нарушил эмбарго, Exim'овцы это аккуратно умалчивают. В Openwall информации об уязвимости (кроме самого факта ее наличия, что было известно публично) не было за ненадобностью (мы не распространяем Exim).
> мы не распространяем EximДа уж, мне даже стало интересно, насколько развесистому лопуху из того комментария это было неочевидно...
> но скоординированному выпуску обновлений помешало нарушение эмбарго одним из дистрибутивов, досрочно опубликовавшем исправлениеогласите имя этого мерзавца
О, опять exim, который весь такой правильный и умеет делать все, что захочешь. Postfix-админы в очередной раз запасаются попкорном.
там все пять ссылок под основной ссылкой, как раз о дырах в этом решете
а здесь холивар постфикса и экзима. ну офигеть теперь.> С того времени все население Лилипутии разделилось на два лагеря - тупоконечников и остроконечников. Тупоконечники не захотели подчиниться указу императора и бежали за море, в соседнюю империю Блефуску. Лилипутский император потребовал, чтобы блефускуанский император казнил беглых тупоконечников. Однако император Блефуску не только не казнил их, но даже взял к себе на службу. С тех пор между Лилипутией и Блефуску идет непрерывная война...
Джонатан Свифт, 1726 год
Да он тут годами в КАЖДОЙ новости про exim или postfix как бы
Да как-то не забористо.
Наверное, надо что-то про FreeBSD вставить эдакое. Что б попёрло :-)
> а здесь холивар постфикса и экзима. ну офигеть теперь.Я за sendmail. Безо всяких новомодных m4, sendmail.cf. Ручками, с нуля.
:-)
> О, опять exim, который весь такой правильный и умеет делать все, что захочешь. Postfix-админы в очередной раз запасаются попкорном.за гибкость приходится чем то платить :)
Главное что бы авиационная отрасль не платила безопасностью
У павлина же ыксчеёнж ... они 100% булетпруФФ! :-)
Exim и над ним putty.exe и windows defender!??
Тогда там все точно в безопасности!