>> Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`).
> Описанная проблема понятна, её разработчики OpenSMTPD пытаются решать списком допустимых
> символов и эскейпингом. Т.е. вызвать тот же rm таким способом, как
> ты описал, в конкретном случае не получилось бы.Да, но и тем не менее логическая ошибка в коде экранизации привела к возможности эксплуатации этой ошибки. Никакого запаса прочности. Сколько ещё ненайденных ошибок прячется в коде экранизации? Есть ли быстрый надёжный способ найти все code-path ведущие к этому execle и доказать, что во всех этих случаях экранизация выполняется верно? Где гарантия, что будущие правки кода не создадут кодопути к этому execle, которые нарушат допущения и засунут туда неэкранированные строки?
> Я несколько неверно высказался, что проблема в неверной валидации входных данных. Ну
> то есть это так, но "[функция] smtp_mailaddr() имеет логическую ошибку, из-за
> которой в случае передачи пустого домена в email, функция возвращает успешный
> код проверки, даже если часть адреса до "@" содержит недопустимые символы"
> - это не то, что можно было бы пофиксить условной libsh.
Так уж и не мог бы пофиксить? В случае с условной libsh этот инвалидный почтовый адрес ушёл бы бэкэнду, тот бы либо переслал дальше, либо сообщил о несуществующем адресе. Я не к тому, что ошибку с синтаксически кривым адресом будет более правильным обрабатывать в mda_agent, чем в MTA -- хз, на самом деле: бекенду всё равно нужно проверить валидность, почему бы не свалить эту проверку на него и не париться о ней? -- но, как минимум, при таком раскладе класс опасности ошибки был бы существенно ниже.
> Я вообще не уверен, что есть серебрянная пуля, защищающая от подобного рода
> ошибок.
> Условная libsh, в зависимости от того, как она будет сделана, может быть
> и будет решать какие-то типовые проблемы, в то же время, ИМХО,
> в бОльшей части случаев практичнее просто ответственно подходить к валидации входных
> данных, а не использовать комплексные решения (unix-way головного мозга, да).
Бороться с каждой ошибкой в отдельности -- это хорошо, но выделять классы ошибок и использовать AoE спеллы против них -- это гораздо эффективнее. Да, AoE -- не серебряная пуля, но они высвобождают ресуры под то, чтобы бороться с ошибками, которые нам ещё не удалось прибить AoE оружием. Бывают AoE "спеллы", которые требуют, например, кучу дополнительной памяти, или ещё как-то повышают требования к железу, или вообще сильно не бесплатны. Но здесь "плата" за AoE -- это виртуально однократно вложенные усилия в разработку libsh. Никаких накладных расходов в runtime, более того потенциально могут быть возможности срезать эти накладные расходы в рантайме.
