LINUX.ORG.RU

Вышел sendmail 8.13.6: устранена серьезная уязвимость


0

0

Вышла версия 8.13.6 самого популярного почтового сервера. В новой версии исправлена серьезная ошибка (CVE-2006-0058), позволяющая удаленному пользователю выполнять на целевой системе произвольные команды с правами пользователя, запустившего sendmail (часто это root). Уязвимы все предыдущие версии, разработчики рекомендуют всем срочно обновиться.

>>> Сайт проекта

★★

Проверено: Tima_ ()

Ответ на: комментарий от stellar

> Выясняется, что в сlamav находится очередная дырка. Ваши действия?

Хм, это со мной надо разговаривать как с идиотом? А я считаю, что и
первый и второй вопрос задан по-идиотски. Объясните мне связь между
обновлением clamav и qmail? Я же тоже для "как идиотов" привел сравнение
с bash, с которым отдельные модули qmail взаимодействуют очень плотно.
В чем конечный смысл вопроса? Какой вы ожидаете ответ? Что я ничего не
буду делать или что я обновлю clamav? Или есть какой-то третий вариант? ;)

anonymous
()
Ответ на: комментарий от anonymous

> > Ну и сиди со своим qmail, заваленным тоннами спама.

> Дык, эта... нет у меня тонн спама. Нет даже маленькой тележки со спамом...
> Можно я умру от стыда за то, что не вписался в твою стройную теорию про неудачников qmail-админов? ;)

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

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

554 5.7.1 virus Worm.Mydoom.I detected by ClamAV - http://www.clamav.net

после DATA, так ? А генерить DNS на деревню дедушке по mail from бессмысленно. Если у твоего юзера переполнен ящик, а на него сыпятся какие-нибудь сообщения с левым mail from (subscribe.ru это любит, к примеру), DSN будут крутиться в _твоём_ спуле и грузить _твой_ сервер, но и так далее.

AS ★★★★★
()
Ответ на: комментарий от stellar

> Приведите примеры таких (хотя бы одной) контор, администрирующих порядка сотни клиентов

Я работал в Nettlife Inc. (Phoenix, AZ). Внутри - штук 7 соляр
разнокалиберных, 3 freebsd, 1 openbsd, 4 линукса. Это у себя. Клиентов
не считал точно - много. Там вообще что угодно может быть. Любой крупный
университет возьмем для примера. Так же все, что угодно можно увидеть.

anonymous
()
Ответ на: комментарий от AS

> Кстати, у безусловного приёма сообщения до всяких обработок есть и еще
недостатки, как, например, отправка сообщения о вирусе в письме. Ведь
ты не можешь сообщить серверу отправителя
554 5.7.1 virus Worm.Mydoom.I detected by ClamAV - http://www.clamav.net

Начнем с того, что это возможно сделать для qmail. Как известно, qmail
имеет модульную архитектуру. И если есть большой желание так делать,
просто ставится mailfront перед настоящим qmail'ом. Mailfront написан
Брюсом Гюнтером, если вам о чем говорит это имя.

А закончим вот чем: а я обязан кого-то предупреждать, что у него
завелись вирусы? За какие грехи я должен взять такую повинность на себя?
Если кому-то это кажется очевидным, то мне - нет. Я считаю такое
поведение бессмысленным.

anonymous
()
Ответ на: комментарий от anonymous

> А закончим вот чем: а я обязан кого-то предупреждать,

Это твое личное дело, конечно.

> Я считаю такое поведение бессмысленным.

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

AS ★★★★★
()
Ответ на: комментарий от anonymous

> И если есть большой желание так делать, просто ставится mailfront

забыл добавить: "опять довесок, опять костыль...".

AS ★★★★★
()
Ответ на: комментарий от anonymous

>Хм, это со мной надо разговаривать как с идиотом?

Именно с Вами.

Ответа от Вас не дождаться, поэтому будем считать слив состоявшимся. Вы мне более неинтересны. Спасибо.

stellar
()
Ответ на: комментарий от AS

> Если тебя не волнует лишняя нагрузка на почтовый сервер

Я отношусь к этому философски. Ресурсов никогда не бывает много ;)
Но допустим даже, что волнует. Как текст с режектом серьёзно может
помочь снижению этой нагрузки? Ну ладно, у провайдеров, допустим, кто-то
просматривает логи, а в сотнях тысяч мелких контор? Эти реджекты -
чепуха и сотрясание воздуха.

anonymous
()
Ответ на: комментарий от stellar

> Ответа от Вас не дождаться,

Коллега по несчатью ;-( Я тоже не дождался ответа, про третий вариант ;)
А очень хотелось услышать!

anonymous
()
Ответ на: комментарий от AS

> забыл добавить: "опять довесок, опять костыль...".

Модуль. В данном случае - именно модуль. Он ничего не патчит, ничего
не изменяет в архитектурной схеме. Более того, возможность подобных
вещей изначально запроектирована в qmail'е с рождения. Давайте отделять
мух от котлет.

anonymous
()
Ответ на: комментарий от anonymous

> Как текст с режектом серьёзно может помочь снижению этой нагрузки?
> Ну ладно, у провайдеров, допустим, кто-то просматривает логи,

Без "допустим". :-) Причем, даже логи смотреть не надо, если копии bounce валятся на постмастера.

> а в сотнях тысяч мелких контор?

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

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

AS ★★★★★
()
Ответ на: комментарий от AS

> Без "допустим". :-) Причем, даже логи смотреть не надо, если копии bounce валятся на постмастера.

Ок. Имеем вирусную эпидемию. Тонны вирусных писем одновременно от 90%
клиентов провайдера. 1) Что он сможет сделать? 2) Как ему помогли
реджекты с сообщениями о вирусах?

> Во-первых, могие используют сервер провайдера в качестве смарт-релея,

Возможно, но не факт. У меня, например, другие данные. Больше
сталкивался с самостоятельными MX'ами даже в совсем небольших конторах.

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

Если ящик переполнен, то по идее формируется bounce. А спамоловку нужно
нормальную ставить.

anonymous
()
Ответ на: комментарий от anonymous

> Эти реджекты - чепуха и сотрясание воздуха.

Кстати, еще момент. Сервер отправителя сгенерит DSN и создаст спам. На который могут пожаловаться его провайдеру со всеми вытекающими.

AS ★★★★★
()
Ответ на: комментарий от AS

подписывайтесь на freebsd-security и не парьте мозг

anonymous
()
Ответ на: комментарий от anonymous

> Ну и сиди со своим qmail, заваленным тоннами спама.

Дык, эта... нет у меня тонн спама. Нет даже маленькой тележки со спамом... Можно я умру от стыда за то, что не вписался в твою стройную теорию про неудачников qmail-админов? ;)

----------

не а быстро учить остальных мудил что повелись на твои росказни и поставили кумыл

anonymous
()
Ответ на: комментарий от anonymous

> > Без "допустим". :-) Причем, даже логи смотреть не надо, если копии bounce валятся на постмастера.

> Ок. Имеем вирусную эпидемию. Тонны вирусных писем одновременно от 90%
клиентов провайдера. 1) Что он сможет сделать?

Лично я клиентов отключаю не задумываясь. 90% накопиться не успевает. :-) Исключение составляют только клиенты со статусом оператора и особо крупные, но там, как правило, сами справляются.

> 2) Как ему помогли реджекты с сообщениями о вирусах?

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

> Если ящик переполнен, то по идее формируется bounce.

Угу, только mail from-то подставной, причем, кстати, как правило от того домена, где наличие пользователя при приёме не проверяется. И начинается кормёжка постмастера того домена левыми боунсами. Впрочем он сам виноват - нефиг почту принимать для несуществующих юзеров. А если реальный E-Mail, то бедного, ничего не подозревающего, юзера кормить начинаем...

AS ★★★★★
()
Ответ на: комментарий от anonymous

> Ну, пожаловались. А это оказался не спам. И что теперь? Мало ли кто на кого жалуется?

Нет, это именно спам. Я ничего никому не отправлял. Нахрена мне DSN о том, что кто-то где-то кому-то что-то послал, подписавшись моим E-Mail, и оно не доставилось ? Это - не мои проблемы.

AS ★★★★★
()
Ответ на: комментарий от AS

4AS:
>А все потому, что, из коробки, он не может при приёме базу локальных пользователей проверить. Это - основная болезнь почтовиков с Qmail и Postfix.

"Давайте спорить о вкусе устриц с теми, кто их ел".
Postfix из коробки такой проблемы не имеет.

//Loseki

anonymous
()
Ответ на: комментарий от anonymous

Кстати, сами по себе баунсы - штука неприятная, конечно, но в ряде случаев приходится с ней мириться (как правило, по воле клиента c exchange'ем).

Но кто совершенно зае - так это spamcop'овцы с их политикой засовывать баунсящие хосты в листы.

//Loseki

anonymous
()
Ответ на: комментарий от anonymous

Тут кто-то говорил за vpopmail.

Штука неплохая, особенно в свете существования веб-морды для её администрения.

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

//Loseki

anonymous
()
Ответ на: комментарий от anonymous

> "Давайте спорить о вкусе устриц с теми, кто их ел".
> Postfix из коробки такой проблемы не имеет.

Сильно спорить не буду, но раньше точно была. Я согласен с тем, что Постфикс развивается. Хорошо, если теперь уже и это сделали.

AS ★★★★★
()
Ответ на: комментарий от anonymous

> Но кто совершенно зае - так это spamcop'овцы с их политикой засовывать баунсящие хосты в листы.

1. нехрен баунсить не в тему - это спам.
2. нехрен bl.spamcop.net для блокировки использовать, он для этого не предназначен.

:-)

AS ★★★★★
()

>1. Спам легко пройдёт проверку на smtp callback. >2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

для этого есть файл badmailfrom Темболее достаточно приблуд для определения правильности адреса доставки

anonymous
()
Ответ на: комментарий от anonymous

> >1. Спам легко пройдёт проверку на smtp callback. >2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

> для этого есть файл badmailfrom

И ты запихаешь в него <>. мАлАдец, возьми с полки пирожок (я так понимаю - это другой анонимус ?).

AS ★★★★★
()
Ответ на: комментарий от AS

> Эх, как далеки от Вас, похоже, проблемы, когда у какого-нибудь Экванта или Транстелекома начинаются проблемы с передачей трафика, но, при этом, замечательно с полной таблицей продолжает работать BGP...

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

Bogerm
()
Ответ на: комментарий от AS

> И ты запихаешь в него <>. мАлАдец, возьми с полки пирожок (я так понимаю - это другой анонимус ?).

Я уже говорил, что <> - это аналог MAILER-DAEMON, с этого адреса не должно генерится никаких баунсов или уведомлений в соотествии с RFC. Если генерятся, то значит админ криворукий.

Bogerm
()
Ответ на: комментарий от Bogerm

> Я уже говорил, что <> - это аналог MAILER-DAEMON, с этого адреса не
> должно генерится никаких баунсов или уведомлений в соотествии с RFC.
> Если генерятся, то значит админ криворукий.

ЧЕГО ???? МАРШ ЧИТАТЬ RFC821 !

AS ★★★★★
()
Ответ на: комментарий от vtVitus

> обнови до RH7.3 и узнай про http://www.fedoralegacy.org/

Если бы я хотел обновиться, то уж точно бы не на 7.3. А RHEL2.1, как мне известно, основан на 7.2, так что я взял src.rpm с него и собрал у себя.

annoynimous ★★★★★
()
Ответ на: комментарий от AS

> ЧЕГО ???? МАРШ ЧИТАТЬ RFC821 !

Во-первых не 821, а 2821. Во-вторых читаем:

6.1 Reliable Delivery and Replies by Email

When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage.

If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing in this section can or should prohibit local decisions (i.e., as part of the same system environment as the receiver-SMTP) to log or otherwise transmit information about null address events locally if that is desired. If the address is an explicit source route, it MUST be stripped down to its final hop.

После чего жуем сопли и перестаем гнать пургу о том, чего не знаем.

Bogerm
()
Ответ на: комментарий от Bogerm

> Еще как далеки... примерно 4000 км,

Европа ? Про Европу не знаю.

> На рынке больше сотни провайдеров и они с радостью примут нового клиента, ушедшего от неудачников.

Я думаю, что провайдера мало волнует мнение неадекватного абонента. Клиент, ожидающий от сети Интернет доступности, как от локалки, приносит больше головной боли, как правило, а не денег.

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

AS ★★★★★
()
Ответ на: комментарий от AS

Для дебиановодов ужо вышло обновление уязв. тулзы. Там кстати Шульц до сих пор.

anonymous
()
Ответ на: комментарий от Bogerm

> > ЧЕГО ???? МАРШ ЧИТАТЬ RFC821 !

> Во-первых не 821, а 2821. Во-вторых читаем:

1. не важно.
2. RFC821 - стандарт, 2821 - всё еще просто RFC.

> This notification MUST be sent using a null ("<>") reverse path in the envelope.

Мне перевести это ? :-)

> После чего жуем сопли и перестаем гнать пургу о том, чего не знаем.

Ага, именно. :-)

AS ★★★★★
()
Ответ на: комментарий от anonymous

> Блин! Очередное удаленное выполнение произвольного кода! Пока эксполита в публичном доступе нет, но это вопрос времени. Следом тут-же последует очередной спамовый потоп.

Ананизмируйте и газифицируйте водоёмы в другом месте, у меня переустановка на 4-х!!! серверах произошла в течении 5 минут, рестарт sendmail тоже не вызвал никаких проблем простоя практически не было. Всем недоделкам типа qmail и postfix срочно мазать жопы вазелином.

CrazyClaus
()
Ответ на: комментарий от AS

> > This notification MUST be sent using a null ("<>") reverse path in the envelope.

> Мне перевести это ? :-)

Нет, вот это:

However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification

Кроме того, советую научиться читать документы полностью, а не только те части, которые нравятся.

Bogerm
()
Ответ на: комментарий от Bogerm

> Нет, вот это:

> However, if this address is null ("<>"), the receiver-SMTP MUST NOT
> send a notification

Тогда Вам следует отмотать тред и понять, о чем я говил раньше.

AS ★★★★★
()
Ответ на: комментарий от Bogerm

> However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification

И еще

> Я уже говорил, что <> - это аналог MAILER-DAEMON, с этого адреса не
> должно генерится никаких баунсов или уведомлений в соотествии с RFC.

это вот кто написал ? Я еще читать умею. Если бы тут было написано "_на_ этот адрес не должно", это было бы правильно.


AS ★★★★★
()
Ответ на: комментарий от AS

> Тогда Вам следует отмотать тред и понять, о чем я говил раньше.

А чего там непонятного? Вы отправляете письмо с адреса "<>" на несуществующий и надеетесь, что это породит поток спама. Это не так, потому что в соотвествии с RFC, который я привел получатель должен просто уничтожить это сообщение или отказаться его принимать. Поскольку qmail-smtpd "отвязан" от модуля локальной доставки, то в момент получения он не знает, существует ли данный адрес или нет. Поэтому он его принимает и кладет в очередь. Менеджер очереди при попытке доставить сообщение обнаружит, что адресата не существует и обязан это письмо уничтожить, потому что отправлять "отлупы" на нулевой адрес НЕЛЬЗЯ. Если админ таких вещей не знает, то он криворук. Теперь перечитайте тред и скажите, где я говорил что-то иное?

Bogerm
()
Ответ на: комментарий от AS

> это вот кто написал ? Я еще читать умею. Если бы тут было написано "_на_ этот адрес не должно", это было бы правильно.

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

Bogerm
()
Ответ на: комментарий от Bogerm

> А чего там непонятного? Вы отправляете письмо с адреса "<>" на несуществующий и надеетесь, что это породит поток спама.

Нет. Это финальный результат. Собственно, тот спам, про который я говорю. Если так можно выразиться, спам второго уровня.

Попробую собрать в кучу. Возьму за пример уже рассмотренный домен.

1. Я отправляю исходный спам, (пусть это будет, к примеру, "как удлиннить пенис") на некую группу адресов, в том числе и на jsajasbvja@cr.yp.to (допустим, у меня робот по сайттам бегает, вот, на LOR забрёл). В качестве адреса отправителя, зная, что у многих используеется smtp callback (а он реально используется), я подставля ю какой-то реальный адрес, например, Ваш. Это спам первого порядка.

2. спам про пенис приходит на cr.yp.to, сервер понимает, что такого пользователя нет, и формирует боунс. Куда ? Правлино, ориентируясь на mail from. ТАм Ваш адрес, не забыли ?

3. К Вам приходит сообщение с mail from:<> и rcpt to:<ваш адрес>. Это спам второго порядка, порожденный несоответствующей сегодняшней реальности настройкой сервера cr.yp.to.

Итого, cr.yp.to сам стал генератором спама.





AS ★★★★★
()
Ответ на: комментарий от AS

Блин, мужики, читаю вашу перепалку и думаю, как иногда полезно сходить в ЛОР. :) Тем более что, тема треда меня мало интересовала. Однако узнал много интересного. Теперь предъявы к прову будут более увесистыми. У них кстати qmail ;) и отвалы почты зае..али, зае..али сообщениями типа, а нехер спамить. Мы же, нах, только читаем.

anonymous
()

> произвольные команды с правами пользователя, запустившего sendmail (часто это root)

У кого? У поколения чупа-чупс или у тебя лично?

anonymous
()
Ответ на: комментарий от anonymous

> > произвольные команды с правами пользователя, запустившего sendmail (часто это root)

> У кого?

Например, в RH по-умолчанию. Недооценивать проблему тоже не надо.

AS ★★★★★
()
Ответ на: комментарий от anonymous

> У них кстати qmail ;)

О чем и речь. Уж не знаю, можно ли его довести до ума, но то, что он много где недоведённый - это совершенно бесспорно.

AS ★★★★★
()
Ответ на: комментарий от anonymous

> Хм. А зачем? Ну вот зачем sendmail'у права рута?

Вообще, по идее, давно незачем. Но так исторически сложилось. Кто-то из дистрибутостроителей должен сделать первый шаг. И, вообще, в chroot его запихать. ;-)

AS ★★★★★
()
Ответ на: комментарий от AS

>А то, что полезные вещи узнаются - так это хорошо, на то советы и даются. Эт чё ж? Прав мой прадед был, когда выводил кистью на баннере - "ВСЯ ВЛАСТЬ СОВЕТАМ!"? А я то думаю, откуда у меня такие позывы - "ДОЛОЙ ПРОПРИЕТАРЩИНУ!"

anonymous
()
Ответ на: комментарий от AS

> Итого, cr.yp.to сам стал генератором спама.

Несколько сумбурное объяснение и совершенно неожиданный вывод. qmail не возвращает оригинал письма, а только сообщение о том, что письмо не доставлено, делая подобную рассылку бессмысленной. При чем тут <> вообще не понятно, ибо qmail делает все в соотвествии с RFC. Чем отличется от того же sendmail?

Bogerm
()
Ответ на: комментарий от AS

> Вообще, по идее, давно незачем. Но так исторически сложилось. Кто-то из дистрибутостроителей должен сделать первый шаг.

Не, я правда не понимаю. Вот в инструкциях по установке jabberd, к примеру, пишут: сначала создайте юзера jabberd и группу jabberd. Затем... А sendmail чем-то принципиально отличается, что ли? Почему не делают так же?

yozhhh ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.