Сэр Серж aka Sir Serge (Сергей Лебедев) - official site
Статьи и заметкиРасчетыСтихиПрозаО сайте

Имя и известность – вот главное. Всё остальное – ничто!

Баги и принципиальные ошибки алгоритмов работы почтового сервера QMAIL

    И снова веет ветер
    и бередит мне раны...
    Qmail, почтовый сервер, -
    отстой такой поганый,
    но даже этот фуфел
    спасает, без сомнения,
    D.J.Bernstein'a имя,
    как автора творения...

(безымянная лирика без авторских прав)

Сподвигла на написание этой статьи меня очередная эпопея, связанная с тем, что паскудники-спамеры нашли и начали массово эксплуатировать очередную лазейку в MTA qmail... Как всегда, пришлось брать в руки молоток лезть в исходный код qmail-smtpd и закрывать лазейку; ибо достало.

Как и всё мире этом, qmail не обходится без кучи сопровождающих его мифов и верований. Якобы он полностью безопасен, масштабируем, удобен и столь хорош, что только стоит изумляться, почему это именно он не остался единственным MTA на платформе UNIX, ибо нет никаких оправданий существованию всего остального.

Так вот, поскольку опять разбираться в хитросплетениях полуассемблерного по манере программирования, кода qmail, не очень-то хотелось, я решил спросить у гугла и яндекса, а что они знают о фиксации насущной проблемы. И натолкнулся на любопытную home page, а именно: http://home.pages.de/~mandree/qmail-bugs.html

Билль озаглавлен следующим образом: «Qmail bugs and wishlist». Ибо это Страшное. Среди униксоидов создание подобных страничек считается отвратительным тоном и они быстро исчезают из поля зрения. Потому что замахиваться на Святое – это то же самое что не слушать своего кюре для правоверного протестанта.

Далее я слегка пробегусь по тексту. Внимание! В этом процессе возможно присутствие ненормативной лексики. Для любителей точности: это такой же клон Пиноккио, как Буратино из отечественных источников, поэтому всех педантов – к истокам. Ссылку я дал.

Документ пополняться не будет, поэтому – за всеми новшествами и пополнениями – вэлкам к тем же истокам.


Превед!

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

Автор Qmail DJB любит всегда и везде делать заявления, касающиеся беспримерной безопасности qmail, и его поддерживает толпа почитателей, некоторые из которых вообще не верят в существование багов этого пакета и предпочитают именовать тех, кто хотя бы заикнулся о пятнах на солнце, дебилами. Так вот, здесь будут перечислены некоторые замечания относительно этой темы, перечислены проблемы и известные методы их решения, если таковые на сегодняшний день известны.

Вся эта гадость касается qmail-1.03, большинство из перечисленного также применимо к этому пакету с наложенными патчами netqmail-1.05. Наивно считаем, что всякие там qmailrocks и подобного рода комплекты – это не qmail... Хотя, основная алгоритмика сохраняется, и ряд багов затрагивает и их.

В документе этом – всего лишь перечень ужасов, и вы самостоятельно должны решить, стоит ли вам работать с qmail, или лучше предпочесть какое-либо другое программное обеспечение с подобными функциями. Приблизительно то же самое, а иногда и лучше, умеют делать Postfix, Exim, и Courier.

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

Часть первая. Ошибки.

1.Ошибки, связанные с безопасностью

1.1. Атаки, основанные на исчерпание памяти qmail-smtpd

Несмотря на то, что qmail заявлен самым безопасным MTA, он, в инсталляции по дефолту, таковым не является абсолютно.

Некто Wietse Venema нашел два способа заставить qmail-smtpd пожрать всю доступную память машины и сообщил об этом еще в 1997 году.

1. при помощи команды RCPT.

2. При обработке длинных строк, однако нет никакой уверенности в отсутствии этих багов и для qmail 1.03, датированной 1998 годом. Оба перечисленных метода очень эффективно и быстро способны привести почтовый сервер с qmail в состояние denial of service. Дэн J Bernstein по этому поводу сказал, что просто должны быть проведены предварительные действия по ограничению ресурсоёмкости этого приложения, но в файлике INSTALL об этом не упомянул ни тогда, ни позже.

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

Методы решения и обхода проблемы:

в статье Dave Sill'са "Life With Qmail" опубликован скрипт, в котором без особых объяснений причин таких действий показано, как предотвратить атаку с помощью программного ограничения. (См. раздел: "The supervise scripts") Dave предлагает следующее (замените 1234 числовым id вашего пользователя qmaild и 4321 - числовым id группы nofiles:

/usr/local/bin/softlimit -m 2000000

/usr/local/bin/tcpserver -v -R -l 0 -x /etc/tcp.smtp.cdb -u 1234 -g 4321 0 smtp /var/qmail/bin/qmail-smtpd

1.2. Флуд сообщениями bounce messages со стороны qmail-smtpd

Принципы работы Отложенных сообщений о невозможности доставки Qmail (Delayed-Bounce behavior), мягко говоря, являются прямым нарушением здравого смысла и логической защиты против спама. Именно эта особенность qmail может быть использована (и применяется многими спамерами практически) для исчерпания локальных ресурсов и заваливания почтовым сервером с установленной qmail спамом в виде bounce messages хостов третьей стороны.

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

Какого-либо общепринятого обхода этой проблемы на сегодняшний день не существует. Можно назвать только частичные методы решения проблемы, такие как патч goodrcptto автора Eben Pratt, патч qmail-realrcptto автора Paul Jarc, расширение qmail-smtpd авторства Tim Clarke, расширение автора Erwin Hoffmann под названием RECIPIENTS extension for qmail-smtpd и qmail-фронтенд пакета Bruce Guenter's mailfront.

1.3. Переполнение буфера qmail-qmtpd

Георгий Гунинский (Georgi Guninski) сообщил о возможности переполнения буфера вqmail-qmtpd в случае, когда переменная окружения RELAYCLIENT содержит в себе текст длиной от 4 до 1003 байт и передаются входные строки с неправильно обозначенной длиной.

Возможное решение: вымарать нафиг qmail-qmtpd, и вместо этого использовать работу по SMTP. QMTP вообще не является каким-либо стандартным протоколом и вы его поддерживать не обязаны.

Поправок можно сказать нет. Господин Guninski предложил свои исправления кода, но их досконально никто не проверял.

1.4. Получение прав root на машинах с большим количеством памяти

Тот же Georgi Guninski сообщает об опасных переполнениях, которые можно применить для получения привилегий root на 64-битных машинах с большой оперативной памятью.

Сообщение Гунинского было проверено исследованиями James Craig Burley's, и мистер Бурли :) добавил, что проблема существует не только для 64-битных платформ, но может проявляться и для 32-битных платформ с сегментированной моделью памяти.

Персональное примечание: баг, найденный Guninski, является «классическим» программерским багом переполнения целого в знаковых индексных переменных, и это развенчивает напрочь миф о том, что DJB программирует гораздо лучше других. Сам же DJB до сих пор заявляет о том, что он пишет исключительно «свободный от багов» код. DJB также заявляет, что по сегодняшний день никаких багов, связанных с безопасностью, в qmail не найдено, и склонен игнорировать блажь

камрада Гунински, аргументируя это тем, что никто в здравом уме не станет устанавливать на свою машину столько гигабайт оперативной памяти для каждого процесса qmail-smtpd. Угу, дистрибутив qmail-1.03 от DJB не содержит никаких пояснений к тому, как и чем необходимо устанавливать лимиты на используемую память. Другими словами, информация, предоставленная (или не предоставленная) в исходном дистрибутиве qmail-1.03, не объясняет системному администратору, как он должен установить qmail, чтобы избежать опасных ситуаций.

Методы обхода ситуации: удалить qmail-popup и qmail-pop3d и установит сервер POP3, который таких багов не содержит.

Решения проблемы и патчей не существует.

2. Надёжность

2.1. Содержимое сообщений о недоставке не защищено от сбоев

Qmail не проверяет целостность сообщений о недоставке почты. Дэн откомментировал эту необычную ситуацию в qmail reliability FAQ. Это значит: если, в то время как qmail пытается отправить сообщение о недоставке, ваша система подвисает или сбоит, содержимое сообщения о недоставке может быть разрушего или будет неполным.

Каких либо обходных решений или патчей не существует.

2.2. Создание имён файлов в Maildir не защищено от коллизий. Возможна потеря почты,зависящая от действий используемого пользовательского почтового агента.

Код, ответственный в qmail за доставку сообщений, подразумевает, что ID каждого процесса уникален в каждый момент времени. Если это не так, а такая ситуация возможна на очень быстрых или высоконагруженных системах, или же в системах, которые произвольно назначают ID процессам, один и тот же ID процесса может быть повторно использован одновременно с другим. Ели доставка почты и чтение почты пользовательским почтовым агентом перекрываются во времени, такая особенность работы может привести к потере почтового сообщения, зависящей от того, как именно действует почтовый агент пользователя для перемещения почты из /new в /cur. DJB объявляет qmail-pop3d безопасным, но другие приложения, например mutt, не заботятся о уникальности имён файлов, что может привести к потерям почты. Ага, вот она, та самая надёжность qmail, построенная на уникальности имён файлов.

Патч: это делает имена файлов в maildir действительно уникальными

Обходные решения: использовать самую последнюю версию maildrop для локальной доставки в каталоги maildir, в ней код создания имён файлов поправлен для гарантирования действительной уникальности имён файлов на самых быстрых машинах (в имена файлов включается серийный номер inode, что действительно гарантирует уникальность имени файла в пределах файловой системы).

2.3. Алиасы IP

Qmail неспособна нормально определять IP-алиасы под Linux.

Qmail подразумевает, что только системы, которые имеют поле "sa_len" в структуре "struct sockaddr" могут иметь одновременно несколько IPv4 адресов (другими словами, IP алиасов/виртуальных интерфейсов) для одного и того же имени интерфейса. Это неверно для Linux, когда адреса у него определены командой: (ip addr add 1.2.3.4 dev eth0 ; ip addr add 4.3.2.1 dev eth0).

Следствие: qmail может не определить правильно собственный IP при отсылке почты, или же когда получает почту по доменному IP адресу (RCPT TO: ).

Обходные действия: Для Linux необходимо всегда конфигурировать IP-алиасы в стиле Solaris, т.е., ifconfig eth0 1.2.3.4 ; ifconfig eth0:1 4.3.2.1 or ip addr add 1.2.3.4 dev eth0 ; ip addr add 4.3.2.1 dev eth0:1.

Исправления: примените qmail/patch-qmail-1.03-4.3BSD-ipalias.diff (signature).

3. Нарушения RFC

3.1. Предумышленное нарушение RFC-1652, параграф "8BITMIME"

RFC-1652 описывает расширение протокола SMTP для использования при передаче сообщений символов, не входящих в диапазон кодировки US-ASCII.

SMTP сервер, поддерживающий эти расширения, отвечает в приветствии 8BITMIME, и когда клиент предваряет посылку тела почтового сообщения тэгом BODY=8BITMIME, сервер гарантирует наличие этого сообщения в bounce именно в кодировке 8BITMIME или переводит ее в семибитное представление (например, используя кодировку base64 MIME) при релеинге почты принимающему серверу, который не поддерживает это расширение.

qmail притязает на соответствие RFC-1652, и конечно же, предоставляет расширение 8BITMIME, но неспособен переконвертировать почту из 8BITMIME, которая направляется на 7-битные хосты. В то время как qmail в целом достаточно хорошо справляется с доставкой 8-битной почты, в сообщениях о недоставке qmail не позволяет использовать расширение 8BITMIME. Практика Qmailа отослать почтовое сообщение назад в том виде, в котором оно было получено, может разрушить структуру письма.

Это довольно опасно. Почитайте мнение Дэна об 8BITMIME: он описывает RFC-1652 как "фантастическую" сеть. qmail объявляет 8BITMIME без преобразования, что предотвращает Q-P преобразование SMTP клиентом, соединяющимся с qmail. Это срабатывает до тех пор, пока qmail не релеит почту. Однако, когда почта перенаправляется на хост, работающий исключительно в семибитной кодировке, случается страшное: восьмибитные символы либо искажаются, либо пропадают из текста письма, либо такой хост высылает bounce.

Раз уж Дэн знает о таких последствиях, он вроде бы должен пофиксить qmail и удалить из него объявление 8BITMIME. Патчик ниже делает это. Однако, и он не может защитить от тупых клиентов, которые всегда передают некодированные 8-битные данные (читай: от других хостов, на которых установлен непатченный qmail).

Обходные пути: отсутствуют

Патч: примените qmail/patch-qmail-1.03-rfc1652.diff

3.2. Нарушение RFC-2821 (SMTP) (Роутинг почты)

Ранее задокументировано в RFC-974.

В 2002, после немецкой проблемы, описанной наde.comm.software.mailserver, было обнаружено, что qmail никогда не пытается доставить почту на какой-либо MX кроме того, к которому он подключился первоначально, даже если MX не отвечает сообщением с кодом 220. Когда сервер отвечает, например, сообщением 554, qmail отключается и позже пытается снова установить связь с этим же сервером, игнорируя тот факт, что код ошибки 554 является признаком постоянного сбоя, и дальнейшая доставка почты на этот хост производится не должна.

qmail должна была бы вместо этого сделать попытки обращения на все перечисленные в MX сервера в порядке предпочтения до тех пор, пока почта не будет успешно доставлена:

RFC-2821, параграф, соответствующий оригинальной версии:

"5.Резольвинг адресов и доставка почты
[...] После того, как имя хоста, ответственного за приём почты, определено, может быть получен перечень альтернативной доставки, а не только единственный адрес, из за наличия нескольких записей MX, нескольких серверов обслуживания, либо того и другого одновременно. Для того, чтобы обеспечить нормальную передачу почты, клиент SMTP ДОЛЖЕН пытаться (и повторять попытки доставки) для каждого корректного адреса в этом перечне, до тех пор, пока такие попытки завершатся успешно.[...]"

Патчик: используйте qmail/patch-qmail-1.03-rfc2821.diff.

Обход проблемы: использование /var/qmail/control/smtproutes и недвусмысленно вручную направлять почту проблемного домена на резервный MX.

3.3. Потенциал для нарушения RFC-2045(MIME) и недостаточная поддержка RFC-1894(Delivery Status Notifications)

qmail сознательно игнорирует RFC-1894 и вводит свой собственный формат сообщений о сбоях доставки, "qmail-send bounce message format (QSBMF)". Qmail заявляет QSBMF весьма лёгким для трассировки, но это имеет серьёзные оговорки:

Проблема не решена.

Обходные пути: существует патч авторства Frederik P. Lindberg patch для предотвращения MIME-ness в сообщениях о сбоях доставки qmail-send. Этот патч не обеспечивает соответствия RFC-1894, но он присоединяет оригинальное почтовое сообщение в виде, соответствующем rfc822, так что проблема «отсутствия завершающей строки» в сообщениях о сбоях доставки пофиксена и такое сообщение может быть нормально декодировано почтовыми программами, работающими с MIME.

3.4. Нарушения RFC-1939(POP3) (Размер почтового сообщения)

qmail-pop3d неправильно подсчитывает размер почтовых сообщений, не так, как это должно делаться по RFC-1939, раздел 11; даёт сильно заниженные значения размера.

Часть II: Недостатки

4. Другие технические проблемы

4.1. Непомерное потребление локальных ресурсов

Ещё в 2001 году автор исходного бюллетеня, измерил и сравнил быстродействие некоторых почтовых серверов. Несмотря на то, что к сегодняшнему дню часть этих тестов уже не отражает истинной картины, доселе сохраняется один, наиболее важный, пункт: qmail делает намного больше синхронных записей в отношении к одному почтовому сообщению, чем какие либо другие MTA больших UNIX - систем и существенно уступает в производительности даже sendmail, если сравнивать используемые ресурсы процессора с учётом операций быстрого дискового ввода/вывода. qmail был на то время агентом передачи почты с самой низкой пропускной способностью (количество переданной корреспонденции в секунду) во всём списке тестируемых MTA.

4.2. Qmail не поддерживает интеллектуальные файловые системы.

Qmail не поодерживает кэширование в файловых системах с программным ускорением. Файловые системы с программным ускорением доступа(FFS) стараются уменьшить необходимость синхронных записей, что гарантирует хорошую структуру файловой системы. В то время как Дэн абсолютно прав в том, что qmail на настоящий момент небезопасен на таких файловых системах, он должен быть сделан безопасным. (Postfix, например, может безопасно использоваться при наличии его каталога /var/spool/postfix на кэшированной файловой системе (softupdated FFS.)

4.3. Монополизация канала передачи данных(нарушение декларации SHOULD(«обязан») из RFC-2821)

qmail не пакетирует почту. Большинство других почтовых серверов передают почту для a@same.example.com и b@same.example.com в одном и том же запросе. qmail в этом случае делает два разных запроса на передачу почты, отдельно для a@same.example.com, отдельно для b@same.example.com. Соответственно, такие действия вдвое увеличивают трафик, и используя qmail, вы платите дважды. (От Sir Serge: довольно сомнительный тезис для экономии в практике; более того, моё имхо говорит о том, что одновременная доставка двух сообщений одинакового содержания на более чем два адреса одного и того же хоста – в 99% случаев – откровенный спам. Поэтому владелец спамящего хоста – пусть платит, если такие действия позволяет, это исключительно его проблемы, я приём mass mailing предпочитаю прекращать на втором адресе доставки и предпочел бы, чтобы такая массовая почта вообще не рассылалась.)

RFC-2821, раздел "4.5.4.1 Стратегия рассылки", рекомендует по возможности производить рассылки путем выдачи нескольких запросов RCPT в одном сеансе:: "В случае, когда почтовое сообщение должно быть доставлено нескольким адресатам, и SMTP сервер рассылает копию одного и того же сообщения нескольким адресатам, только одна копия текста сообщения ДОЛЖНА быть передана. То есть, клиент SMTP ДОЛЖЕН использовать последовательность команд: MAIL, RCPT, RCPT,... RCPT, DATA вместо последовательности: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. Однако, если в списке слишком много адресов, может вступать в действие ограничение на количество команд RCPT, соответствующих единственной команде MAIL. Усовершенствование этой особенности должно всячески поощряться"

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

4.4. Отсутствует ESMTP PIPELINING с клиентской стороны

Несмотря на то, что ESMTP PIPELINING может существенно сократить время, требующееся для передачи почтового вложения, qmail не применяет этот метод при отсылке почты (хотя, применяет его при приёме). Пакет serialmail такую методику использует, но он ни в коей мере не является частью qmail и всё равно следует qmail`овской политике монополизации канала связи из предыдущего параграфа.

Обходных путей - нет

Патч: Rolf Eike Beer предлагает ESMTP патч для SIZE и PIPELINING в целях улучшения работы qmail-remote.

Примечание: вместо того, чтобы реализовать вышеописанное, Dan J. Bernstein зачем-то разработал собственный новый протокол, quick mail queuing protocol (QMQP в сокращении) который призван превзойти по производительности ESMTP PIPELINING при больших объемах передачи. QMQP обладает собственными недостатками, которые не позволяют снизить трафик за счёт сброса почты, направленной на адреса несуществующих локальных пользователей или с нежелательных адресов/серверов: в нем тело сообщения высылается до того, как высылается «конверт» сообщения.

4.5. Отложенные сообщения о сбоях доставки (методику можно квалифицировать как разбазаривание трафика и прямую поддержку спамеров)

Qmail в общем случае допускает приём любой почты,кроме попыток релеинга (обеспечивается существованием /var/qmail/control/rcpthosts) и почты со стороны пользователей, внесённых в чёрный список /var/qmail/control/badmailfrom). Что означает: если некто посылает почту на адрес несуществующего пользователя вашего домена (некоторые спамеры тупо перехватывают Message-ID и рассматривают их в качестве почтовых адресов), qmail с радостью принимает такую почту, сообщает высылающей стороне "250 Ok", затем обнаруживает, что такого адреса для доставки у него нет, и генерирует bounce для возврата тому, кто якобы письмо посылал.

Допустим, некто доставил пятимегабайтное письмо: qmail эти пять мегабайт принимает, а затем отсылает bounce, также размером не менее пяти мегабайт: в сумме 10 мегабайт трафика сгенерировано запросто и почём зря.

Ещё более худшая ситуация возникает, когда адрес отправителя подделан. qmail в этом случае может наградить увесистым сообщением о сбое доставки совершенно не относящийся к исходной рассылке хост или целый перечень хостов, или же, если пострадавшая сторона не сможет принять это сообщение, оно застрянет в очереди передачи до окончания тайм-аута и периодически будет передаваться, создавая грандиозный трафик вам и пострадавшей стороне. qmail записывает IP передающей стороны в лог, но не делает никаких пометок, что bounce было послано ничего не подозревающему третьему хосту.

Патчи/ пути решения см. в разделе 1.2.

4.6. Неправомерная логика работы qmail-remote.

Florian Weimer сообщает, что он наблюдал выходящие за рамки разумного поведения попытки распараллеливания доставки через qmail-remote, создающие излишние задержки доставки почты с других хостов. Такое случается, когда qmail-remote открывает больше SMTP соединений, чем может себе позволить MX принимающей стороны (если другая сторона имеет меньший лимит на одновременное количество SMTP соединений, чем qmail-remote). Некоторые процессы qmail-remote затем получают "Connection refused" или подобную временную ошибку и сбрасывают почту, несмотря на то, что почта могла бы быть доставлена, если бы qmail открыла меньше одновременных сеансов SMTP. Данная область поведения требует дополнительных исследований.

4.7. Почта рассылается от анонимных пользователей, обычно демонами.

Эта особенность поведения не документирована, однако приводится здесь.

qmail-inject (то есть, входящая в комплект qmail оболочка-имитатор sendmail) смотрит исключительно на переменные окружения для определения источника почты. Эта программа проверяет переменные QMAILUSER, MAILUSER, USER и LOGNAME в приведённом порядке до тех пор, пока не обнаружит совпадение. Если qmail-inject совпадения не обнаруживает, в качестве автора сообщения вносится строка "anonymous". Резидентные процессы, однако, обычно не имеют переменных окружения USER и LOGNAME, потому что эти переменные устанавливаются программой login(1) -- которая демоном не используется. qmail-inject не пользуется результатами функций getuid() и getpwuid(), хотя вообще-то должна это делать.

Патчей нет.

Обходные пути: насильно задавать адрес, с которого производится отправка, с помощью опции -f sendmail (но см. 4.12), или в переменных окружения.

4.8. Неустойчивая работа qmail при обработке большого объёма поступающей почты.

qmail-send станет узким местом в случае, когда почта добавляется высокими темпами. Это уже отмечено во вторичном измерении производительности qmail. После получения почты, необходимая предварительная обработка почты qmail резко снижает конкурентность qmail-remote, что приводит к задержке доставки почты, поэтому большинство слотов qmail-remote простаивают.
André Oppermann графически выразил эту ситуацию. Смотреть рядом с его выражением "silly qmail syndrome patch".

Обходных путей нет.

Патч: решение предлагается André Oppermann здесь. Смотреть по словосочетанию "silly qmail syndrome patch".

4.9. Неправильное определение переменной errno

Некоторые исходники qmail и её клонов вместо нормального использования директивы #include определяют собственное значение этой переменной как extern int errno; Несмотря на то, что такой подход во многих случаях срабатывает, стандарт POSIX требует обязательного включения заголовочного файла

для определения errno. qmail основывается на недокументированном формате этой переменной что приводит к сбоям при использовании GNU libc начиная с версии 2.3.1.

Хотя DJB сейчас рекомендует использование include errno.h в conf-cc, эта обходная методика не полностью переносима.

Патч: Phil Edwards' errno.h patch.

4.10. Переполнение целого в qmail-smtpd

Georgi Guninski сообщает: Qmail-smtpd использует знаковую индексную переменную в ссылках на строки, не проверяя её на переполнение. Посылка строки заголовка длиной 231 байт, не имеющей внутри символа LF, приводит к падению qmail-smtpd.

4.11. qmail не распознаёт 0.0.0.0 в качестве специального адреса

Scott Gifford нашел, что qmail не распознаёт 0.0.0.0 в качестве локального адреса (это общепринятый специальный адрес для локального хоста в текущей сети), и пытается форвардить сообщения для такого адреса, трактуя его как адрес удаленного хоста. Во многих инсталляциях эти действия создают локальные петли доставки. (Вряд ли это приведет к отказу от обслуживания, но после нескольких бессмысленных пробежек завершится генерированием сообщения о сбое доставки).

Обходных путей нет

Патч: Scott Gifford's qmail-0.0.0.0.patch (обязательно прочитайте qmail-0.0.0.0.README).

4.12. qmail'овская строчка sendmail -f несовместима с sendmail.

Входящий в комплект qmail имитатор sendmail неправильно обрабатывает опцию командной строки -f , то есть он не устанавливает по умолчанию адресное поле From: почтового сообщения,корректируя только конверт. Это отличается от поведения оригинального sendmail и приводит к сбоям в работе некоторых приложений.

Обходных путей нет.

Патч: David Phillips's sendmail-flagf.patch.

4.13. qmail-remote неправильно обрабатывает символ CR.

qmail-remote пропускает «чистые» CR и вставляет CR перед любым знаком LF. Это может привести к появлению комбинации отдельно стоящего CR или сочетания CRCRLF в передаваемом сообщении.

Обходных путей нет

Патч: Rolf Eike Beer выпустил patch,

qmail-remote-CRLF.diff, который принудительно превратит CR в CRLF и оставит CRLF неизменными.

4.14. qmail-smtpd неправильно определяет CR LF на границах пакетов.

Mark Martinec сообщает, что qmail-smtpd некорректно отказывается принимать почтовые сообщения и отсылает к страничке

http://cr.yp.to/docs/smtplf.html, если CR является последним символом в пакете, а LF – первым символом следующего пакета.

Обходные пути: если у вас есть возможность управления посылающей стороной соединения, сделайте так, чтобы символы CRLF всегда посылались в одном пакете. Отчёт Марка Мартинека говорит о том, что такое может быть достигнуто при построчной посылке сообщений.

Известных патчей не существует.

4.15 qmail всегда генерирует дату во временной зоне GMT

Хоть это возможно и спорно, но большинство нормальных людей предпочитают даты локальной временной зоны.

Патч: здесь можно получить патч, который позволит qmail записывать даты в формате локальной временной зоны. Довольно распространенная заплатка, в

разных вариантах существующая на разных сайтах.

5. Антиреклама

5.1. Гарантия безопасности

Все гарантии безопасности qmail есть ни что иное, как эфемерное колечко дыма, которое легко развеивается при малейшем дуновении ветра. По крайней мере двое: Wietse Venema и Georgi Guninski, задокументировали баги безопасности qmail, для которых могут быть созданы действующие эксплоиты, но знаменитые 500 долларов США не были никогда выплачены ни одному из них. DJB отклонил сообщение Guninski ссылкой на то, что системные администраторы должны ограничивать доступные qmail ресурсы, не дав об этом никаких инструкций по установке.

Это личные наезды автора списка дефектов на Великого и Могучего DJB:

Код, написанный DJB, содержит явные дефекты, что не мешает DJB во всеуслышание заявлять, что он создаёт исключительно код «свободный от каких-либо багов». Высосанное из пальца предположение DJB относительно того, что клиенты QMTP будут отсылать исключительно правильно отформатированные сетевые строки (пренебрегая проверкой на то, что символы действительно находятся в диапазоне 0-9), использование знаковых индексных переменных, слабая проверка на допустимость границ, соглашения, ни на чем не основанные, относительно фактического размера полей данных, допускает ситуации,когда сервер с qmail становится уязвимым, если для qmail не выставлены ограничения по памяти, - всё это показывает, что DJB не является великим магом и монстром программирования, а такой же человек, склонный делать ошибки; несмотря на все его напыщенные заявления.

DJB даже не задокументировал ответственные моменты, касающиеся его кода, которые должны быть в обязательном порядке предприняты администратором в системном окружении и никак не являются присутствующими по умолчанию. Если Гунински в установке qmail по умолчанию на FreeBSD 5.4 и машине с amd64 получает удалённый доступ с правами root, Гунински должен получить эти самые обещанные 500 долларов, ясен пень! Другие люди, например, James Craig Burley, думают так же.

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

DJB потерял своё лицо не за счёт багов в его коде как таковых (все люди ошибаются иногда, не так ли?), но за счет помпезной политики списывать всё на действия конечных пользователей, которых он напрочь забыл предупредить об особенностях поведения qmail; в таком случае по какому моральному праву он может сам отсылать отчеты об ошибках другим людям, если игнорирует присутствие замеченных багов в собственном коде?

Часть III: Пожелания

6. Пожелания

6.1. Копировать сообщения о сбоях доставки postmaster'у.

Qmail не имеет собственных средств для копирования всех отсылаемых сообщений о сбоях доставки почты локальному postmaster'у хоста.

6.2. Дайте qmail возможность допускать одиночные знаки LF в теле сообщения.

Qmail предлагает администраторам почтовых серверов отстать до тех пор, пока их почтовые системы не будут в строгости соответствовать стандарту CRLF. Это нарушает базовый принцип существования в сообществе «Быть как можно более либеральным в своих предположениях относительно того, что вы принимает, и быть консервативным в отношении того, что отправляете вы». (от Sir Serge: Угу. И так куча кривых агентов занимаются рассылкой мусора,еще и принимать их кривую почту? Резко против этой идеи. Положено по стандарту не принимать писем без CRLF – да будет так!)

Обходные пути: запустить программу fixcrio в качестве оболочки для qmail-smtpd. fixcrio поставляется в составе UCSPI-TCP.

Патч: Dean Gaudet предлагает патч, ползволяющий qmail-smtpd допускать чистые LF


Всего комментариев: 3

alsan OC: Windows 2000   2007-09-27 13:46:14


Очень интересная статья ...
Спасибо автору за перевод статьи.
Я не программист, а системный администратор и мне первый раз трудновато было сориентироваться с выбором МТА. Пришлось перепробовать почти все в последствии...
Я и многие из моих знакомых, кто ставил и потом сопровождал почтовый сервер на qmail сталкивался со многими из вышеперечисленных выше проблемами... применяли патчи и т.д.
А когда поставил и настроил, работает, появляются проблемы их патчишь и дальше по кругу... далеко не сразу приходит мысль поменять в принципе МТА.

Было бы значительно интереснее увидеть дополнение к данной статье, где сравниваются разные МТА (цитирую: Приблизительно то же самое, а иногда и лучше, умеют делать Postfix, Exim, и Courier).
Что именно "то же самое " и "иногда и лучше ", а что хуже...
Т.е. статьи типа [ ccылка ] очень сухо и без аргументов.
Если, конечно, цель данной статьи не просто показать как плохо D.J.Bernstein программирует да и еще не выплачивает обещанные деньги за обнаруженные дыры в безопасности...
Еще раз спасибо за перевод с комментариями!!!


Alex Povolotsky OC: FreeBSD   2008-10-22 19:10:54


<i>Код, ответственный в qmail за доставку сообщений, подразумевает, что ID каждого процесса уникален в каждый момент времени. Если это не так, а такая ситуация возможна на очень быстрых или высоконагруженных системах, или же в системах, которые произвольно назначают ID процессам, один и тот же ID процесса может быть повторно использован одновременно с другим.</i>

Эээ.... 64 тысячи процессов в секунду? Система умрет уже на 1000.

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


smkuzmin OC: Windows 7   2012-11-16 16:24:34


> 4.10. Переполнение целого в qmail-smtpd
>
> Georgi Guninski сообщает: Qmail-smtpd использует знаковую индексную переменную в ссылках на строки, не проверяя её на переполнение. Посылка строки заголовка длиной 2^31 байт, не имеющей внутри символа LF, приводит к падению qmail-smtpd.

Интересно, в каком письме можно увидеть строку, длиной 2Гб?



Вы можете добавить свои комментарии.

Поскольку у нас тут абсолютная демократия, то комментарий появится на сайте только после того, как он будет одобрен администрацией. Оперативности, однако, не обещаем.

Прошу соблюдать относительную корректность в высказываниях. Заявления типа "Пошел на...", посты, написанные в олбанской лексике и психоанализ личности автора и участников обсуждения в свет не выйдут. Также будут блокированы сообщения, не имеющие никакого отношения к заявленной тематике. Если вы не согласны с приведенным текстом - выскажите своё мнение, но обосновывайте его. Помните, что свою позицию доказываете Вы не мне, а другим читателям. Всячески приветствуются возможные технические поправки и исправления неточностей. Для возможности внесения комментариев в браузере должна быть включена поддержка JavaScript. Реклама и ссылки на сайты, не относящиеся к делу, являются прямым основанием блокировки. Поля "E-mail" и "WWW" обязательными для заполнения не являются, поле E-Mail не публикуется. Если хотите просто что-то написать автору статьи, без публикации на сайте - воспользуйтесь специальной формой под пунктом меню "О сайте". Администрация оставляет за собой право публиковать или не публиковать адреса, введенные в поле www, а также при необходимости редактировать текст вашего сообщения. Ответы на ваши сообщения по введенному вами E-mail автоматически сайтом не высылаются. Да, теги PHPBB и HTML не действуют, так что не старайтесь их вводить.

Copyright © 2003-2018 by Sir Serge