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

Не понял, что именно не попало в дистрибутивы и «кто неправ»?

Долгих лет жизни Доктору Бернштейну!!

Открой для себя Mailcow, docker-mailserver и Mailu. Последним я кстати пользуюсь на своей почте. Не потому что я не могу взять руками postfix, dovecot, opendmarc и opendkim и склеить их вместе. Могу и проделывал это неоднократно. Просто лень. Плюс в Mailu еще и веб-админка приятным бонусом идет (правда для чего-то нетривиального все равно приходится лезть в консоль - но это меня не пугает).

Да любой мануал от васи пупкина по настройке хоста был про qmail. То, что людям кроме очереди еще и роутинг нужен, умалчивалось.

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

После проверки PVS разве есть гарантия, что специально подобранные данные не будут портить память?

Чего не было в Фортране?

Не было ситуации типа:

  char c[10];
  char x;
  x = 0;
  c[10] = 42;
  // здесь может быть x = 42

Да и UB не было, пока динамическая память не появилась.

Да, если хранить всё вперемешку в одном массиве, можно было эмулировать ошибки Си. Так их даже на лиспе можно эмулировать… Настоящий программист напишет программу на Фортране Си на любом языке.

Бернштейн тот еще крендель был. Кричал, что написал код без багов, в котором нет уязвимостей. Даже денег предлагал тем, кто найдет. А когда нашли, слился (но подправил в документации параметры вызова своего tcpserver’а). Плюс qmail был совершенно бессмысленен без сторонних патчей.

это чо за прога? первый раз слышу.

кто именно? qmail или patchmail?
первый никогда не был по умолчанию, по целому ряду причин.
а про второй я вообще первый раз слышу, WTF?

Открой для себя зимбру и не имей себе мозг :) Сейчас вот карбониро у них развивается вполне. Всяко лучше. Но пихать почтовую систему в докер я считаю маразмом, тут ты меня переубедить не сможешь. Может я и ретроград, но достаточно обосновано считаю, что почтарь - отдельная машина (пусть даже в виртуалке), которая больше ничем не занимается от слова совсем. Там крутится почта и сервисы вокруг нее вроде вебморды, админки и т.п. (хотя на нагруженных системах это лучше разнести). Все.

Я имел в виду, что qmail из-за того, что базовая функциональность была минимальна и на каждый чих нужен был патч, в шутку называли patchmail :)

Первый. Значит, я ошибся. Но с ним все носились. Хотя ограничен рн ппц как.

После проверки PVS нет, я привел пример бомжей. Clang-analyze умеет показывать где входные данные могут повредить буфер.

Clang-analyze умеет показывать где входные данные могут повредить буфер.

Тогда аналогичный вопрос про Clang-analyze. Если он показывает, что всё хорошо, это гарантирует отсутствие UB и порчи памяти?

Фактически, нужен автоматический механизм для Си/Си++, который позволил бы проверить наличие UB в коде. Потому что если нормальную ошибку можно отловить, то UB может испортить любые данные в любом месте (а если UB провоцируется входными данными, то можно и подобрать такую порчу, которая станет уязвимостью).

Есть анализаторы, что могут показать UB/ID. По моему тот же clang-analyze умеет показывать такие места, он прям очень умный. Хочу попробовать Coverity, но там сложно с ними связаться, но их тоже очень хвалят, особенно за очень простое встраивание в CI/CD, тогда код с предупреждениями вообще в реп не попадает.

а какие проблемы с маршрутами в кумыле?

А подробнее? Если там дело было в параметрах вызова то может и правда то был не баг?

а, я просто не понял =D

согласен!

у нас просто оно в виде своей SRPM было, поэтому подзабыл уже про эти «нюансы» ))))

sendmail был в основном MTA по умолчанию в большинстве дистров во времена популярности qmail (1997-2005), демьяном я тогда не увлекался, поэтом не могу ничего сказать про него.

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

Надо самому городить парсеры и обработчики. В exim у тебя развесистая смесь acl с чем-то типа mod_rewrite из коробки.

Решето

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

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

А когда появились массивы динамического размера, опять не все компиляторы контролировали выход за границы такого массива...

У фортрана очень большая история, и естественно поздний фортран сильно отличается от раннего.

Статический анализ сишного кода проще чем для любого другого языка.

Ну может и проще (что спорно, у Си даже парсинг тяжелый), только смысла в таком статическом анализе мало. Сравни статический анализ в ЯП, где все переменные либо локальные, либо обрабатываются сборщиком мусора, с анализом в Си, где через пару подбросов указателей в воздух уже вообще не понятно, что, куда, чего, и зачем.

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

У всех сишников программы падают с переполнением стэка и повреждениями памяти (причем, иногда баги висят по 10 лет), а вот у тебя точно ничего не падает, я уверен. Господь, прости, что сразу не узнал.

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

Я много чего видел и слышал про сишников, но я в упор не понимаю поведение человеков, которые пишут код больше одного месяца, да еще и на Си, и потом говорят «в моем коде уязвимостей нету». Я повидал и в моем, и не в моем коде на абсолютно разных стадиях разработки столько багов и они были такие, что меня уже не удивит НИЧЕГО, даже если hello world позволит повысить права до рута через специально скрафченную переменную окружения из-за бага в обработке /etc/ld.so.cache — вот вообще ни капельки не удивлюсь, обычный день в обычной сишной системе. Если сегодня спящий берсерк не покрошил всех в капусту — это просто везение, сегодня можно поспать спокойно.

Господь, прости, что сразу не узнал.

Прощаю тебе, сын мой. Архангелы мои анализаторы да опыт 10тилетний помогают код писать который по всей россии работает уже 8 лет.

У всех сишников программы падают с переполнением стэка и повреждениями памяти

Пруфы есть что у всех падают или балабольство?

(что спорно, у Си даже парсинг тяжелый

Ну да, Си гораздо тяжелее парсить, чем С++ или С#. Намного, намного тяжелее.

только смысла в таком статическом анализе мало

Видимо clang-analyzer показывая мне указатель в 6м поколении сдвинутый на значение из другого указателя через libastral показывает.

либо обрабатываются сборщиком мусора

А, это то говно из-за которого вся программа раком встает раз в пару минут включая весь user-input, обработку сообщений и сигналов? Да, очень полезная штука когда нужна реакция 1/24 с чтобы не дай боже посетителю кинотеатра не показался яркий фрейм рекламного ролика, вшитого в фильм.

которые пишут код больше одного месяца, да еще и на С

Ну то есть чукча не писатель, смотрели только на студентов и\или идиотов, этого достаточно чтобы обобщить на всех. Так и запишем.

Clang-analyze умеет показывать где входные данные могут повредить буфер.

Только если он может статически вычислить диапазоны входных данных. Любая косвенность или побочные эффекты — ­и досвидос, функция анализу не подлежит.

Есть анализаторы, что могут показать UB/ID

«Могут показать UB» != «гарантируют отсутствие UB». Потому что могут и не показать. Причем, чем сложнее код, тем чаще не могут.

Только вот не видно что-то толп добродетелей, спешащих переписать софт с забагованной сишки на более современные ЯП. Видимо, затрат на это будет больше, чем потерь от потенциальных взломов сишного кода.

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

Если говорить о том, почему сишка сожрала всех — здесь с одной стороны порешали совершенно обозревшие корпорации, которые просили кучу денег за свои ОС, а с другой стороны — (почти) бесплатный юникс, который слепили из того, что было. В какой-то момент случилась страшная вещь, и Intel тонко оптимизировал свои процессоры под Си — на этой стадии сишка с x86 держась за руки прокатилась по всей индустрии, поставив знаки тождества ОС = Си = близость к железу.

Но если бы в параллельной вселенной победила JVM, то программы на Си стали бы медленными и никому не нужными.

Пруфы есть что у всех падают или балабольство?

Давай так: были уязвимости в линуксе (в том числе десятилетиями висевшие), браузерах, СУБД, suid хреновине polkit, удаленное управление в мессенжере tkabber, как минимум DOS в pidgin — любая мало-мальски сложная программа не заколоченная в песочницу имела в то или иное время ту или иную уязвимость. В линуксе повышений прав до рута было настолько много, что безопасники уже относятся к этому в духе «как не дать злоумышленнику удаленно выполнить команды после получения прав рута», а все мало-мальски популярные хостинги помещают контейнера docker в отдельную VM, потому что возможность запуска любого софта в контейнере фактически значит возможность доступа к руту на хосте.

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

Ну да, Си гораздо тяжелее парсить, чем С++ или С#. Намного, намного тяжелее.

Только немножко наоборот: С++ намного сложнее парсить, чем Си, потому что C++ включает в себя Си. Правда, Си по прежнему остается тяжелым для парсинга языком.

Видимо clang-analyzer показывая мне указатель в 6м поколении сдвинутый на значение из другого указателя через libastral показывает.

Я не понял, о чем ты.

А, это то говно из-за которого вся программа раком встает раз в пару минут включая весь user-input, обработку сообщений и сигналов? Да, очень полезная штука когда нужна реакция 1/24 с чтобы не дай боже посетителю кинотеатра не показался яркий фрейм рекламного ролика, вшитого в фильм.

GC-фоб в треде, все в кучу.

Ну то есть чукча не писатель, смотрели только на студентов и\или идиотов, этого достаточно чтобы обобщить на всех. Так и запишем.

Ну да, всякие там идиоты, вроде Торвальдса — действительно, я наверное не туда смотрел.

у Си даже парсинг тяжелый

Ты рофлишь что ли? Во времена, когда си создавался, компьютеры были большими и медленными. Синтаксис у Си простой, как валенок, чтобы древние машины не захлебывались на его обработке.

где через пару подбросов указателей в воздух уже вообще не понятно, что, куда, чего, и зачем

Напоминаю, что указатели все еще типизированные, не считая хаков с войдом.

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

Си нельзя распарсить до отработки препроцессора со всеми инклудами и правильными дефайнами. На системах, где есть только заголовки libc, проблема стоит не особо остро, но по мере роста сложности программ выяснилось, для для обработки кода hello world нужно распарсить сотни строк кода. И это еще куда не шло, потому что в C++ счет идет уже на тысячи.

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

где через пару подбросов указателей в воздух уже вообще не понятно, что, куда, чего, и зачем

Напоминаю, что указатели все еще типизированные, не считая хаков с войдом.

Пока PPP328 отвечает, отвечу тебе на смежный вопрос. Дело в том, что оптимизация Си была бы по большей части невозможной без одного некорректного допущения, которое в наше время делают почти все компиляторы C/C++ — передача указателя на переменную интерпретируется как передача по ссылке, in-out значение, то есть, чтение-запись памяти по адресу не обязательно, иногда оно полностью исключается, даже если это ломает логику программы.

Эта некорректная оптимизация сломала настолько много программ, что пришлось срочно вводить модификатор volatile, который данную оптимизацию отключает. Однако же, передача указателей настолько вездесуща в Си, что без этой некорректной оптимизация теряет смысл инлайн, скаляризация сложных структур (распихать поля структуры в регистры и обрабатывать их без доступа к памяти), дедукция константных значений и устранение мертвого кода (например, возвращаемые поля структуры никем не читаются в этом конкретном вызове).

Это значит, что статически определенная как безусловная передача указателя на ячейку рассматривается как in-out передача значения, то есть, передача по ссылке. Если статически не удалось высчитать указатель, то в этом месте оптимизация ломается. Статически вычислить не получится, если имеет место внешний код и побочные эффекты.

Для упарывающихся функциональщиной замечу, что побочные эффекты, как то ввод-вывод файла-консоли-GUI — это основный смысл работы программ, потому с побочными эффектами сталкивается любая полезная программа.

Си нельзя распарсить до отработки препроцессора со всеми инклудами и правильными дефайнами.

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

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

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

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

Ввод-вывод и многопоточность-многозадачность (разделяемая память) как минимум. Си был изначально однозадачным ЯП с синхронным вводом-выводом, но такой подход давно неактуален, потому необходимость деоптимизации нынче намного больше, просто делается она не только через volatile, а, например, через встроенные атомарные функции (__atomic_***). В ОС, которая работает с устройствами через память, это вообще беда, там сплошные volatile в драйверах, но это всё-таки больше про ядро, а не userspace.

если хранить всё вперемешку в одном массиве

А других вариантов и не было. Динамической памяти нет, входные данные разные, объявляем массив максимального размера, такого что после компиляции задача запустится, и в этот массив всё и складываем.

И это было исходно заложено в язык. Мы передаём в подпрограмму прозвольный элемент массива, а для подпограммы — это массив, расположенный в заданной части исходого, причем, может быть другой размерности (одномерных->двухмерный).

Не было ситуации типа:

Ещё как была. Контроль выхода за границы массива опционален, у каких-то компиляторов его вобще не было, у каких-то его нужно было включать. Где-то он был только как в вашем примере, когда размер массива задан явно, но переставал работать для передаваемых в п/п массивов или в COMMON-блоках.

можно было эмулировать ошибки Си

Если что, это в Fortran IV применялось, когда ещё никакого Си близко не было.

Я хочу подчеркнуть, что этого не было в фортране, этого не было в коболе — это «изобретение» разработчиков Си

Не знаю, как было в первых версиях Кобола, но это никакое не «изобретение» Си, в ЯП времён появляения Си такая работа с памятью была нормой.

Всё еще частный случай.

проверки на доступ за пределами массива

Просто их отключали часто «чтоб быстрее работало».

Просто они ломали давно написаный и работающий код. Да и чаще их просто не включали, у многих компиляторов по умолчанию они выключены. А людям, пишущими код на Фортане для расчётов, некогда изучать опции компилятора, они же не проф. программисты.

И при чём тут поздние компиляторы? Фортран изменился до неузнаваемости, а Си нет. Фортран 95 и Фортран 66 фактически разные языки. Утверждение «этого не было в фортране» неверно, это было в Фортране, относительно недавно сделали возможность убрать это. Но, вроде как, даже если в компиляторе есть проверки выхода за границу массива, их можно отключить, то есть сделать, чтобы «это было в Фортране».

Всё еще частный случай.

Да, частный случай. Значит, я прав? Или ты мне на что-то хочешь возразить?

Просто они ломали давно написаный и работающий код.

Лол, то есть, доступ за границы массива был нормой? Я слышал что-то про математиков, но не до такой степени.

Утверждение «этого не было в фортране» неверно, это было в Фортране, относительно недавно сделали возможность убрать это.

Я изначально вел речь ТОЛЬКО про самый ранний фортран и явно это написал.

Да, частный случай. Значит, я прав?

Нет, это значит, что прав я. Возвращаемся к моему исходному посту:

1. Си - простой, и парсить его просто.

2. Твое суждение о некорректности предположения для оптимизаций ошибочно, так как частный случай << общий случай.

Какой именно стандарт фортрана вы считаете самым ранним? Вот первое руководство по фортрану http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/704/704_FortranProgRefMa... там ни слова про то, что произойдёт при выходе за границу массива. Просто написано, что индекс не может быть больше, чем указано в объявлении массива. И всё.

доступ за границы массива был нормой

И да, и нет. Широко использовался и EQUIVALENCE, и COMMON. А проверки могли этого не понимать. EQUIVALENCE, в частности, позволял наложить один массив на другой (со сдивгом). Один массив большой, мы его объявили как надо, и если надо меняем размер и перекомпилируем. А другой массив объявляем размером 1, но накладываем его на 5 элемент первого массива. И потом работаем со вторым массивом не выходя за границы первого.

Си - простой, и парсить его просто.

Си в вакууме — да, простой. Си в реальности — сложный и правильно сформировать структуру файлов не получается даже у отлаженной системы сборки. Год назад я отказался от clang-analyzer при работе с одним проектом потому, что он никак не мог правильно проанализировать код с большим числом макросов.

Твое суждение о некорректности предположения для оптимизаций ошибочно, так как частный случай << общий случай.

Да, оно мое. Оно моё не потому, что «частный случай << общий случай», а потом что я его написал и под ним значится мой ник.

Оптимизация некорректна, потому что ломает рабочий код. А описание некорректной оптимизации я делал для того, чтобы показать, что «тип указателя» — это мягко говоря не определяющий фактор для статического анализа кода, указатель одного типа в двух разных местах может иметь радикально разную интерпретацию, но общее «желание» оптимизаторов и прочих анализаторов — это превратить указатель в не-указатель, что возможно только если ячейка, на которую ссылаются, заранее известна и подлежит оптимизации (не имеет побочных эффектов) в данном контексте.

«Не иметь побочных эффектов» нынче всё реже и реже получается соблюсти по мере того, как приложение начинает делать ввод-вывод и обращения к разделяемой памяти (в том числе многопоток). «Заранее известна» реже получается соблюсти по мере роста сложности алгоримтов ­— число шагов в вычислениях может быть бесконечным, то есть, программа не завершается. Как можно заметить, оба фактора связаны со СЛОЖНОСТЬЮ программы, то есть, достаточно хорошо проанализировать или оптимизировать можно только изолированный прямолинейный и чистый (без побочных эффектов) код, то есть, который можно представить как отдельную простую программу.

Вот первое руководство по фортрану http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/704/704_FortranProgRefMa... там ни слова про то, что произойдёт при выходе за границу массива.

Да, ничего не написано. Также там не написано, как вообще выполнить программу, и тем более как ее отладить.

Один массив большой, мы его объявили как надо, и если надо меняем размер и перекомпилируем. А другой массив объявляем размером 1, но накладываем его на 5 элемент первого массива. И потом работаем со вторым массивом не выходя за границы первого.

Ты о том, что компиляторы не умели проверять одновременно доступы к обоим массивам? Да, непростая задачка. Однако, в фортране не было типов «массив любой длины».

Си в реальности — сложный и правильно сформировать структуру файлов не получается даже у отлаженной системы сборки.

Проекты прекрасно существуют и собираются, не надо выдумывать.

Оптимизация некорректна, потому что ломает рабочий код.

Какой конкретно код сломан? Покажи мне его.

Проекты прекрасно существуют и собираются, не надо выдумывать.

Господа, у кого здесь при попытке сборки проекта (например, с гитхаба) при установленных зависимостях всё собирается и вообще ничего не нужно дополнительно конфигурировать?

Какой конкретно код сломан? Покажи мне его.

Выбирай любую ссылку из 1725 штук:
https://elixir.bootlin.com/linux/v6.5.5/A/ident/volatile
Да, там много asm volatile, которое применяется примерно для того же, для чего и модификатор volatile на переменной.

Я уже не помню всю историю и очень давно не видел qmail. Насколько я помню, там был собственный аналог inetd - tcpserver, который слушал порт и отправлял данные в qmail-smtp, в котором и нашли переполнение буфера. Параметрами tcpserver он по-моему ограничил не то время сессии, не то максимальный размер передаваемых данных.

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

Господа, у кого здесь при попытке сборки проекта (например, с гитхаба) при установленных зависимостях всё собирается и вообще ничего не нужно дополнительно конфигурировать?

Не юродствуй. Есть сборочная система, есть список зависимостей и то, как они должны быть установлены. Выполнено? Если да, и сборочные скрипты писал не идиот, то всё соберется.

Выбирай любую ссылку из 1725 штук

Использование языковой конструкции = сломанное? Ты вообще Си знаешь, или теоретизируешь просто? Ты понимаешь, что именно делает volatile?