Разработчики почтового сервера Exim выпустили (https://lists.exim.org/lurker/message/20140528.122536.a31d60...) экстренное обновление Exim 4.82.1 (https://www.exim.org), в котором устранена критическая уязвимость (CVE-2014-2957), позволяющая удалённому злоумышленнику организовать выполнение кода на сервере. Проблема проявляется только в ветке Exim 4.82 (http://www.opennet.ru/opennews/art.shtml?num=38282) при включении в настройках отключенной по умолчанию опции EXPERIMENTAL_DMARC.
Всем пользователям Exim следует убедиться, что на их сервере для проверки валидности почтового домена отправителя не применяется DMARC. Обновления с исправлением уязвимости в настоящий момент пока не доступны для дистрибутивов. Статус выхода исправлений можно отследить на следующих страницах: Debian (https://www.debian.org/security/), Ubuntu (https://lists.ubuntu.com/archives/ubuntu-security-announce/2...) и FreeBSD (http://www.vuxml.org/freebsd/).Gentoo (http://www.gentoo.org/security/en/index.xml), openSUSE (http://lists.opensuse.org/opensuse-security-announce/2014-05/), CentOS (http://lists.centos.org/pipermail/centos-announce/2014-May/t...), Fedora (https://admin.fedoraproject.org/updates/F20/security), RHEL (http://rhn.redhat.com/errata/rhel-server-errata.html).
Проблема была выявлена неназванной компанией, использующей Exim в своей практике, и без огласки до выпуска исправления в пятницу сообщена разработчикам Exim. Через несколько дней, которые были выделены на тестирование патча на рабочих серверах, был подготовлен корректирующий выпуск. Интересно, что в ветке Exim 4.80 полтора года назад была выявлена (http://www.opennet.ru/opennews/art.shtml?num=35181) похожая по степени опасности уязвимость, проявляющаяся в конфигурациях с DKIM. Если в случае с DKIM, уязвимость возникла из-за отсутствия достаточной проверки данных, возвращаемых удалённым DNS-сервером, то проблема в DMARC связана с некорректным разбором содержимого заголовка "From".URL: https://lists.exim.org/lurker/message/20140528.122536.a31d60...
Новость: http://www.opennet.ru/opennews/art.shtml?num=39877
Перехожу на postfix надоело это все.
> Перехожу на postfix надоело это все.Гришь, там багов не бывает вовсе?
За всю историю проекта серьёзных уязвимостей ещё не было. Несколько DoS, не больше. В Postfix очень строгие правила рецензирования кода и суровые обвязки для работы со строками. Венема на безопасности собаку съел. Например, он включён в зал славы Information Systems Security Association за свой вклад в компьютерную безопасность.
За всю историю проекта серьёзных уязвимостей ещё не было. Несколько DoS, не больше. В Postfix очень строгие правила рецензирования кода и суровые обвязки для работы со строками.Наверное именно поэтому в базе NVD большая часть уязвимостей postfix с рейтингом High.
http://web.nvd.nist.gov/view/vuln/search-results?query=cpe:/...
> Венема на безопасности собаку съел. Например, он включён в зал славы Information Systems Security Association за свой вклад в компьютерную безопасность.Аппеляция к авторитету это не аргумент. Авторитеты тоже ошибаются, что и подверждает ссылка выше.
> Наверное именно поэтому в базе NVD большая часть уязвимостей postfix с рейтингом High.
> http://web.nvd.nist.gov/view/vuln/search-results?query=cpe:/...А теперь внимательно почитайте то, что перечисленно по вашей ссылке. Ещё можете глянуть базу secunia http://secunia.com/advisories/search/?search=postfix &n...
Опасных уязвимостей там нет, какие-то баги в установочных скриптах, DoS, локальные проблемы с правами доступа и дыры в левых надстройках. CVE-2011-1720 - дыра в Cyrus, а не Postfix, для неё долго обещали создать эксплоит, но так и не создали.Покажите конкретно опасную уязвимость, через которую возможен удалённый доступ или проведение представляющей угрозу атаки, а не просто исчерпание ресурсов или падение процесса. Просьба на левые web-интерфейсы для настройки Postfix и ошибки в дистрибутивных скриптах установки ссылки не присылать.
> Авторитеты тоже ошибаются, что и подверждает ссылка выше.Есть способы на порядки уменьшить риск возникновения уязвимостей. Жестко формализованный процесс разработки, использование только безопасных функций-врапперов, обязательный отдельный аудит безопасности всех изменений и многоуровневая система дополнительной защиты и изоляции для минимизации вреда в случае если уязвимость всё же всплывёт.
Показателен в этом плане Chromium, несмотря на использование изначально проблемного WebKit, благодаря модели дополнительной изоляции, критических дыр, способных вылезти за пределы sandbox, там единицы. Еще лучше пример OpenSSH, там как и в Postfix критичных дыр ещё не было.
>Есть способы на порядки уменьшить риск возникновения уязвимостей. Жестко формализованный процесс разработки, использование только безопасных функций-врапперов, обязательный отдельный аудит безопасности всех изменений и многоуровневая система дополнительной защиты и изоляции для минимизации вреда в случае если уязвимость всё же всплывёт.На какие только изощрения не готовы пойти люди, лишь бы на Haskell не писать.
> Покажите конкретно опасную уязвимостьhttp://archives.neohapsis.com/archives/postfix/2008-08/0392....
http://permalink.gmane.org/gmane.mail.postfix.announce/115
> http://archives.neohapsis.com/archives/postfix/2008-08/0392....Локальная уязвимость, проявляющаяся на системах, в которых
1. допускается создание hardlink-ов на чужие файлы (нужно создать hardlink на симлинки с правами root),
2. конфигурация предусматривает возможность добавления поступающей почты к файлам пользователя (обычные конфигурации с доставкой через внешние агенты, встроенный агент mbox и maildir не подвержены уязвимости, только левые агенты mbox)
3. криво настроены права доступа к директории со спулом.Практическая ценность от такой уязвимости близка к нулю.
> http://permalink.gmane.org/gmane.mail.postfix.announce/115
Это ошибка в в коде поддержки Milter от sendmail, который редко где используется. Проблема проявляется при очень специфичном стечении настроек и приводит к повреждению файла в очереди - это даже не уязвимость, так как повреждается только файл с письмом атакующего :-)
Postfix-у помогает ещё и конвеерная обработка посредством кучки отдельных программок в лучших традициях юниксвея. Даже если и удастся кривым письмом одну из этих программок сломать, то шансов пробраться куда-то "совсем не туда" становится значительно меньше.
А слабо на postfix сделать паузу на 15 секунд перед обработкой каждого письма?
В экзиме - элементарно делается...
В postfix тоже элементарно. Только зачем?
> В postfix тоже элементарно. Только зачем?Ну так расскажите, как?
А заодно было бы интересно послушать процесс организации доставки в Postfix в зависимости от наличия пользователя на одном из серверов.
Exim'цик SubGun: А ещё можно из буханки хлеба сделать троллейбус!
Postfix'оиды: .... но зачем?!?И в этом весь экзим, в нем есть всё кроме мала-мальски приемлемого почтового сервера.
В sendmail делается с помощью greetpause, насколько я помню.
А что в postfix нельзя, кто нибудь ответит?
Как раз думаю, что ставить на некоторые новые серверы, postfix или exim. Вот так postfix получает минус, если в нем нельзя сделать такую элементарную штуку.
http://www.postfix.org/POSTSCREEN_README.html читать про параметр postscreen_greet_wait
> http://www.postfix.org/POSTSCREEN_README.html читать про параметр postscreen_greet_waitОтлично! Спасибо!
**ятЪ!
Ну зачем?!?!?! Можешь объяснить ?
AntiSPAM/AntiDoS
> Ну зачем?!?!?! Можешь объяснить ?Предотвратить атаки на сервер путём превращения его в Неуловимого Джо. Нет пользователей — нет проблем!
> Только зачем?Чтоб пользователям жизнь мёдом не казалась. А то ишь чего захотели -- быстрой пересылки электронных писем!
Имеется в виду неавторизованный приём (от серверов) - защита от спамеров.
А от авторизованных - ясен пень без задержки и прочих "радостей жизни".
> защита от спамеровНу ты же понимаешь (надеюсь), что ждать будет не сам спамер/спамбот, а используемый им сервер? Спамер за считанные секунды/минуты отошлёт 100500 писем, а серверу потом это несколько часов разгребать.
И да, такой "антиспам" — неплохая возможность за DDoS-ить сервер путём забивания портов. Вместо того, чтобы по-быстрому всё обработать и закрыть соединение, сервер занимает порт и тупо ждёт.
>> защита от спамеров
> Ну ты же понимаешь (надеюсь), что ждать будет не сам спамер/спамбот, а
> используемый им сервер?Некоторые спам-программы ломятся на сам почтовый сервер напрямую.
У них логика проста.
- connect
- send 100500 emails
- disconnect.
Они не ждут приветствия от сервера.
Ожидание в N секунд позволяет игнорировать такие спам письма.> Вместо того, чтобы по-быстрому всё обработать и закрыть соединение, сервер
> занимает порт и тупо ждёт.Обработка спам писем может быть очень дорогой по ресурсам, когда стоит фильтр письма по содержимому, особенно если разом приезжает 100500 писем за соединение.
> В postfix тоже элементарно. Только зачем?А чтобы без нарушений RFC сбросить с хвоста спамеров для почтовика некрупной организации (для 150-300 почтовых ящиков, например). Естественно, не для mail.ru или аналогичного сервиса. Но спам уходит прочь, а реальные пользователи этого практически не замечают. Особо одаренные и 30 секунд задержки ставят...
Смешно
Смешно eval в заголовке письма.
> Смешно eval в заголовке письма.К чему это было сказано?
К уязвимости. По сути eval и есть...
> К уязвимости. По сути eval и есть...Вы не могли бы свои мысли предоставлять в более понятной форме? Потому что фиг поймет о чем вы говорите.
Ага, на приёме postfix+dovecot >> epic win [/sarcasm]
postfix неуязвим, потому как сам он туп, как дрова. Сюрпризы вылезают в схемах postfix+dkim, postfix+ldap etc. Но сам posfix всегда белый и пушистый, а что у вас дуршлаг в итоге - так это всё кривые милтеры виноваты (а где прямые-то взять?).
И да, при маршрутизации письма postfix не использует кастомных переменных by design. Видели, как этот вопрос в openldap решают? В postfix ровно так же. Берегите свой моск.
>надоело это все.down not across
Когда включаешь что-то, на чем написано Experimental... ну ты понял.
А головой подумать?
Нашли баг в какой-то экспериментальной опции, которая везде отключена по умолчанию, а включить штатно дают только в полутора дистрибутивах. А вони-то, вони!
что-то подобное можно развернуть на postfix?
http://habrahabr.ru/post/133215/
Слишком толсто, не читал.
> что-то подобное можно развернуть на postfix?
> http://habrahabr.ru/post/133215/Дядя, статья то - *oвнo. Всё что там есть на постфиксе тоже делается, но так делать не надо, надо не так! Как именно есть даже тут, ищи.
Этот метод действенный, но совершенно избыточный. Я около полугода собирал статистику по количеству срабатываний примерно полусотни критериев, и убедился, что для 99.99% надежности распознавания спама достаточно трех проверок:
1. наличия реверсной записи в ДНС (любой, не обязательно соответствия с HELO)
2. отсутствия домена в собственном черном списке (коротком, до 100 строк)
3. проверки спамассасином с байес-фильтром, обученным на письмах, пойманных на №1 и №2Ну и, разумеется, фидбек от хуманоидов, которые вручную обозначают фальш-позитивы и фальш-негативы.
> Этот метод действенный, но совершенно избыточный. Я около полугода собирал статистику по
> количеству срабатываний примерно полусотни критериев, и убедился, что для 99.99% надежности
> распознавания спама достаточно трех проверок:
> 1. наличия реверсной записи в ДНС (любой, не обязательно соответствия с HELO)
> 2. отсутствия домена в собственном черном списке (коротком, до 100 строк)
> 3. проверки спамассасином с байес-фильтром, обученным на письмах, пойманных на №1
> и №2
> Ну и, разумеется, фидбек от хуманоидов, которые вручную обозначают фальш-позитивы и фальш-негативы.Реверсная запись в ДНС, к сожалению, у многих провайдеров автоматически создается, и связана обычно с IP адресом, иногда даже динамическим... Было бы здорово, если б этого не было.
> Реверсная запись в ДНС, к сожалению, у многих провайдеров автоматически создается, и
> связана обычно с IP адресом, иногда даже динамическим...Именно поэтому вторым пунктом идет блеклист, в котором перечислены специфические для провайдерских динсетей регекспы:
^.*\d+[-\.]\d+[-\.]\d+.*
^.*dynamic.*
^.*static.*
^.*broadband.*
^.*cable.*
^.*pppoe.*
^.*pool[-\.].*
И так далее.В паре эти две проверки режут 95% спама. Оставшихся 5% добивает СА.
>[оверквотинг удален]
> динсетей регекспы:
> ^.*\d+[-\.]\d+[-\.]\d+.*
> ^.*dynamic.*
> ^.*static.*
> ^.*broadband.*
> ^.*cable.*
> ^.*pppoe.*
> ^.*pool[-\.].*
> И так далее.
> В паре эти две проверки режут 95% спама. Оставшихся 5% добивает СА.Да-да, нужно побольше блеклистов. Блеклисты - панацея, они никогда полезные письма не блокируют.
> Да-да, нужно побольше блеклистов.Один блеклист. Свой. Регулярно обновляемый скриптом на основании логов.
Впрочем, при желании можно было бы обойтись и без этого блеклиста, но нагрузка на байес стала бы на два порядка выше.Раз уж есть абсолютно явные и несомненные источники спама - глупо не воспользоваться ими для конструктивных целей.
А прочитать новость вдумчиво слабо? Или главное развести флейм у кого крепче и длиннее?Сказано прямым текстом:
Проблема проявляется только в ветке Exim 4.82 при сборке с опцией EXPERIMENTAL_DMARC, которая не применяется умолчанию.Трудно понять что это ЭКСПЕРИМЕНТАЛЬНАЯ опция и в ней необязательно, но могут быть как ошибки так и проблемы и дыры.
это как и ситуация с proftpd. За плюшки приходится платить :( К сожалению postfix в плане гибкости - бревно
>> это как и ситуация с proftpdВсегда можно поставить Pure-FTPd