Дыра в BIND 4.9.x до 4.9.8 и в 8.2.x до 8.2.3.

Вот так вот, господа :)
И так - с каждой версией Bind. Решето.

Мда жуткие строки.
Так 9 -ый то несломали :-) еще бы там же 500 зиленых программер обещал
тому кто сломает !

Н-да, а кто-то кричал о суперзащищенности BSD.

Можно я вставлю своих пять копеек? Народ, если вы хотите раз и навсегда
забыть кошмар под названием bind, не слушайте дурные советы америкоса Тимы.
Выбросьте bind _совсем_. Никогда связка bind+sendmail не была
и не будет безопасным решением. Делаются они фактически одними руками.
А эти руки слишком много раз доказывали свою кривизну. Сколько же раз
нужно наступить на одни грабли, чтоб осознать это?

Есть нормальные проверенные решения. И не беда, что они имееют гораздо
меньшее распространение.

Ну не факт что эти проверенные решения написаны более прямыми руками. Тут как в том фильме: а что он и вправду такой неуловимый? Да нет он просто нахрен никому не нужен. Хотя согласен что если ставить что-нибудь специфическое то сразу число кул хацкеров желающих поживится следующим эксплоитом сократится катострофически.

А при чем тут BSD ? Равно как и Linux c AIX'ом напару. Дырка ведь в софтине а не в операционке - да пускай ты этот несчастный BIND под chroot'ом и под не привелегированным пользователем как все нормальные люди делают и спать спокойнее будешь. А если всякую кривую софтину пускать под рутом то и будешь получать по мозгам даже не от хакеров, а от червяков типа давешнего Рамена который использует дыры столетней давности

К счастью, во всяком случае в дебиане, уже есть обновление для него. PS Это мне больше всего нравиться в этом дистрибутиве.

Хм...не только в дебиане делают быстро обновления.

Нет, врешь, Шарапов, то бишь shuras. Ты хоть понял, о чем речь идет?
Я благодарю небо, что еще год назад избавился от дерьма под названием BIND,
aka "Buggy Internet Name Daemon", и что мне не придется сейчас переставлять
это добро на десятках удаленных серверов. Представляю удовольствие,
которое сейчас испытывают большие провайдеры. Да что они, все корневые сервера...

Так что читайте, завидуйте, и (как там дальше?) http://cr.yp.to/djbdns/ad/unbind.html
Цитата:
BIND is like Microsoft Windows. The damn thing doesn't work. Every version has been
brimming with bugs.

2foreigner А что вы, батенька, посоветуете ставить среднему такому провайлеру с 1200-1500 клиентами и держащему 15-17 доменов 2го уровня?

A вот давайте немножко подискутируем. Эта история стара как мир - переполнили буфер на юнихе и получили рута. На сайте www.void.ru можно найти теоретические труды объясняющие что переполнение буфера это наследственная болезнь юниха. Вопрос - может стоит создать с нуля операционную систему которая не будет этим болеть? Пусть она будет подвержена атакам которые ее выводят из строя, но ни в коем случае не дают рута. То есть что бы можно было ее завалить, но не получить рута ни за что в жизни. Это вопрос к юниксоидам. Есть еще вопрос к специалистам по винде - ирси, орг, ВСЛ. Как дела с переполнением буфера под видной? Best regards, Mальчик-Шакал.

А что кроме бинда можно ставить?

2 anonymous (*) (2001-01-30 12:16:04.0) что за бред ты несешь? Это беда на юникса а языка C, а может беда тех программистов которые так пишут.. и фраза "но ни в коем случае не дают рута" глупа - дают шелл /bin/sh или возможность выполнить другие команды на удаленном сервере с правами юзера от которого работает демон. RTFM а не void.ru!

to Мальчик-Шакал: Так же, даже лучше :))) ибо все сервисы гоняются под System, читай, их суперпользователем. А на счет неисполняемого стека - посмотри дискуссию на BUGTRAQ. На сколько я помню, она была в конце прошлого года. Кроме того, неисполняемый стек не лечит всех buffer overflows. Опять же, на BUGTRAQ была бесподобная статья о том, как использовать BO в хипповых массивах для исполнения произвольного кода.

> На сайте www.void.ru можно найти теоретические
> труды объясняющие что переполнение буфера это
> наследственная болезнь юниха
На ядро ставишь опенволовские патчи которые перемешивают стек

to: anonymous (*) (2001-01-30 12:14:03.0)

И простому среднему и непростому большому и администраторам TLD я рекомендую
только одно - djbdns. Только в этом случае их волосы будут шелковистыми.
Вообще, я уверен (а с предсказаниями у меня все нормально), что к 2005 году весь
серьезный интернет будет использовать софт, написанный этим человеком.

2foreigner
ты забыл слово в конце добавить: "АМИНЬ"

Аминь говорят те, кто надеется, но не уверен. Я уверен.

Это все РедХат и вообще Линух виноват!

>И простому среднему и непростому большому и администраторам TLD я рекомендую 
>только одно - djbdns. Только в этом случае их волосы будут шелковистыми. 
>Вообще, я уверен (а с предсказаниями у меня все нормально), что к 2005 году весь 
>серьезный интернет будет использовать софт, написанный этим человеком.

Как раз сейчас в fido7.ru.unix обсуждаются теории этого
человека в приложении к ``серьезному интернету''. 
Очень интересно почитать :))

to Мальчик-Шакал... интересно а какой root аккаунт ты задумал в win95/98 получить? там шелла то нормального нет.. command.com - так это надсмешка.. а не оболочка..

to foreigner, а djbdns написал похоже тот же мужик, который qmail забахал ?? интересно, а qmail еще поддерживает или написал софтину полюбовался и бросил .... Helpless

Ну что я могу посоветовать товаришу форенжиру. А не буду ничего советовать. Понадеюсь, что он прав. Время покажет. Очень хочется верить. Мне бы такую уверенность. :) И знания. Ну а преведущему оратору стоит заметить что шелы шелами а для того что-бы тебе все потерли вполне хватит и command.com :) Тоже не очень приятно.

to helpless:
Да, это он.
Поддерживают bind, sendmail, vixie cron и прочую шелуху. Потому как если
полумертвого не поддерживать, то он совсем упадет. А есть продукты, которые
твердо стоят на ногах. Более 3-х лет без единой дырки. Хотел бы я чтоб весь
софт был таким же "неподдерживаемым", как qmail. Тогда можно было бы спать
спокойно.

А не подскажет ли всезнающий ALL не он ли <ПИСАЛЛ> QMAIL
именно писал !!! Или вышла новая версия ?
А то я от qmail отказался по одной причине , чтоб оно нормально работало
IMXO с моей точки зрения надо было ТАКУЮ кучу патчей поставить . И я небыл
уверенн что все патчи он писал и что безопасность ну такая КРУТАЯ будет ?
Вам некажется что Qmail так и умер недоделанный ?

Ну вернемся к действительности !


Уважаемый foreigner без кривой ухмылки !
Вот он я средний класс с сеткой на 9-ть этажей !
И вот нужен ну позарез DDNS динамический апдейт зон , НУ ЗАВЯЗАН я на нем
вот и все . Как я понял эта штука пока никак :-(

Вы можете уверять меня что я могу это написать и прислать патч !
Ну я то могу Зы может . Вы видели сколько патчей на Qmail есть ?
Считать будем или нет !

Безопасность это хорашая штука , дык и автор хороший !
Может у него есть план он щас там наваяет один гордо так , а потом
возьмется за support наберет тонну програмистов и наступит НА ТЕ САМЫЕ
ГРАБЛИ !!!

Вам так некажется ???
А мне кажется что когда djbdns научится DDNS то может уже и DNS - вообще
небудет ! Кто знает что будет завтра нетак-ли ?


Вобщем chattr -R +i /usr/chroot/bind
chroot /usr/chroot/bind named
Угу его еще на отдельный диск в read only :-)

и нежужжжжжит :-) или вобще всякие виртуал машины и прочее !
Кому что больше нравится .

PS: локальные дирректории по понятным причинам изменены , притензии совпадений
с вашими дирректорииями непринимаются . Так как они были выдуманны автором .

Переполнений буфера и в виндах хватает. Беда не в юниксе, беда в С/С++ и самое главное - в модели разработке софта типа "базар", когда прога отлаживается, а не доказывается...

Патч патчу рознь - одно дело дырки затыкать, а другое - функциональность добавить. Весь фокус qmaila и djbdns в грамотном, с точки зрения безопасности, распределения функций между частями системы. Рутовые права получает только тот кусочек системы, которому это действительно необходимо, а та часть, что в инет торчит - под самым безправным узверем работает. Да, по началу я действительно испытал шок - нестолько мелких программок вместо одного монстра и пяток файлов(из оной строчки :) вместо sendmail.conf. А давай патчи таки посчитаем. Начинай!

Уважаемый Aleks IZA, история повторяется и тех же патчей становится все больше
по djbdns. А в чем проблема? Человек дал нам в руки безопасный, проверенный "скелет",
на который можно накладывать любое мясо. Насчет динамического апдейта зон,
то на мой взгляд ничего более приемлимого, чем djbdns найти просто невозможно.
Downtime 0. Старт мгновенный. Что касается инструментария, то это уж как-нибудь
самостоятельно. Можно взглянуть на чужие работы: http://em.ca/~bruceg/sqldjbdns/
А какое количество патчей для qmail вам понадобилось? Мне хватает двух-трех.

Простите, что не в тему:
но по-моему, затронута гораздо более широкая тема, чем просто бинд
против djbdns. В интернете навалом софта, который предназначен для
одного и того же. За редкими исключениями, безусловно признанных
лидеров нет. Вот фрешмет мне сейчас выдал 61 запись на слово dns
server. Опять же по-моему, назрела острая необходимость в каком
то.... ранжировании, что ли... Правда метода tucows.com тоже кажется
сомнительной...(может наблюдаться эффекты толпы: чем больше коровок->
тем больше скачивают ->тем больше коровок)

ПЕрвое, что приходит на ум - по количеству баг фиксов (обратная
зависимость, естественно) и по количеству функциональных апдейтов.
ИЛи по количеству установок с учетом аптаймов. Что думаете?

Саша

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

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

2anonymous (*) (2001-01-30 23:00:48.0): при правильном подходе к разработке можно доказать и правильность реализации...
А вот о затратах времени и сил на переписывания - ктоб спорил. :( Блин, хотя бы новые проекты пытались так как надо делать...:( Ну впрочем необходимость такого подхода была доказана давно, но на практике она так и не применяется увы...:(

Все нормальные запускают bind, естественно, под named и в chroot.
Перекомпилировать и установить с новых исходников - займет максимум полчаса.
О чем спорите то господа?

Gluk, вопросик:

> А при чем тут BSD ? Равно как и Linux c AIX'ом напару.
> Дырка ведь в софтине а не в операционке - да
> пускай ты этот несчастный BIND под chroot'ом
это понятно...
> и под не привелегированным пользователем как
а на самом деле как? BIND bindится к привелигированным портам
(tcp/udp 53 < 1024).

> все
> нормальные люди делают и спать спокойнее будешь.
>
...skip...
> Gluk (*) (2001-01-30 10:19:18.0)

> А что вы, батенька, посоветуете ставить среднему такому провайлеру с 1200-1500 клиентами

Что батенька посоветует - не знаю, но bind 9 - ИМХО неплохой выбор.
А sendmail... Да кому он нужен при наличии Postfix?

Если не ошибаюсь, то в NetBSD Postfix - дефолтный почтовик.

Я не Gluk. А делается очень просто - есть у него ключи командной строки -u user -g group -t root_directory. Все, что нужно, описано в Bind-Chroot-HOWTO. Как это выглядит в исходнике - лично я не смот- рел, просто при старте он пишет в лог, что он все это сменил, а запускается физически из под рута. Порт он занимает, ессно, до того.

Чуть запаздываю ! дак дело-то давно было !
Для начала. А давайте небудем кому оно надо ладно OK ?

Для AffreuxChien коментарии про постфикс ниже OK.

И так чтоб небыло флейма .
Как я выбирал почтовик : поставил Qmail Postfix и Sendmail !
причем не просто поставил а отконфигурировал как надо !
И они втроем замечательно пахали , притензий неимею но выбрал sendmail!

Теперь перейдем к патчам ! :O)
Понеслаь :
Как я понял qmail так и остался 1.03 жаль очень жаль.

И вот где-то на задворках инета я нашел вот такой патч !!!
qmail-UCE он сам состоит из кучки ПАТЧЕЙ - забавно правда ?
читайте
Consolidated anti-spam patches.

As I mentioned before, in addition to integrating mail filtering into
Qmail itself, this patch also includes many other anti-spam patches
from other authors. In no particular order, they are as follows:
* The anti-UCE patch by Lionel Widdifield <lwiddif@spydernet.com>
which adds logging to qmail-smtpd, adds control/badrcptto (which
rejects mail to nonexistent mailboxes that are still on somebody's
spewer list -- this is made partially obsolete by my checklocal
patch, see below), performs simple grammatical checks on the
domain part of the MAIL FROM:, allows wrappers to set the DENYMAIL
environment variable which triggers mail rejection for any of the
following reasons: A) All mail is rejected - if the connection is
from a spam factory domain that you know will never have any
legitimate messages for you; B) All mail with an invalid domain in
the MAIL FROM:, or; C) All mail with an empty MAIL FROM:. Lionel
Widdifield's patch, basically, rejects obvious junk E-mail.
* Rask Ingemann Lambertsen's <rask@kampsax.dtu.dk> patch that allows
RELAYCLIENTS to be set dynamically from control/relayclients and
control/relaydomains. Makes relay controlling to be a bit easier.
* Russ Nelson's <nelson@crynwr.com> patch to access Paul Vixie's
<paul@vix.com> real-time blackhole list via DNS. Paul Vixie
maintains a list of IP addresses that are used by spammers, or
have open relays. See http://maps.vix.com for more information.
* Chuck Foster's <Chuck.Foster@uk.uu.net> patch to fix DNS 512-byte
buffer overflow.

The following patches come from yours truly:
* Additional improvements to the MAIL FROM: patch, improving its
performance, and allowing it to coexist peacefully on machines
with a dialup PPP link.
* Additional enhancement of Russ Nelson's RBL patch that allows for
multiple block lists to be used, in addition to rbl.maps.vix.com.
* A patch to tcpserver 0.84 (and tcp-env), also designed for
peacefull existence on a PPP link, allowing tcpserver/tcp-env to
be conditionally-compiled to use /etc/hosts, via gethostsby...
(currently, DNS is used exclusively to initialize tcp-environ).
Please note that the patch will set the flag in tcp-env to use
gethostsby... functions. If you wish to keep the old behavior of
tcp-env, after applying the patch, set the USE_GETHOSTBY directive
to 0.
* Reject mail for non-existent mailboxes, as opposed to qmail
accepting any message for a local domain, and bouncing
non-existent recipients internally.

А я еще Хачу smtp-auth
А еще rblsmtpd - ну там было уже подключение к марс но я Хачу
в архиве еще валяется daemontools и cmd5checkpw

все это работало еще в связке с maildrop вместо procmail
ну вобщем неплохо работало !

Вот неуспел еще start-tls

Ну вто собственно вроде все !
А почему бы их просто невключить в qmail или безопасность непозволяет ????
А кто скажет что безопасность непострадала ? или вы чесно высмотрели все
исходники? , ну впринципе не очень большие !

Дак как это много патчей или нет ! ооо там на центральной страничке есть патчи
на все случаи жизни - как я понимаю чтоб система была гибкой и имела много
возможночтей !

Вот после этого ненадо говорить что настроить Qmail легче чем Sendmail !
спорить будем ? (оо мне будет сложно спорть яж бросил qmail ).


А теперь главное вот скелет main() {exit(0);}
чесное слово я ничего неимею против но могбы этот классный безопасный
программер позаботится о своем детище ааа ?

PS: А теперь попробуйте меня убедить что мне надо срочно перейти с sendmail на
Qmail или тем более Postfix но для начала затравка !

Да у меня Sendmail работает в chroot вместе с pop и procmail естественно !
Забавно да ?

Вот потставил smtp-autch на Sendmail и проверил РУКАМИ
аутентифицировался как vova а отпроавил письмо mail from:suppot
Непорядок ? ну я то быстро это дело поправил теперь vova может тока от vova !
А у вас как оно ??? проверьте :-)

А вот мое мнение Личное
Qmail
да круто есть куча патчей с непонятной безопасностью есть даже cgi - ки
готовые , установка полный геморой , гибкость администрирования ниже чем у
sendmail.
Postfix хорошо развивается легко ставится легко настрайвается , но негибок
абсолютно.
Sendmail умеет все и больше , классика идеш на sendmail.org месяц читаеш потом настраиваиш и кричиш
ЭВРИКА !


Но вернемся дак как же лучше скилет и куча патчей или динамично развивающаяся
прога ?????
а как насчет скилета к sql например а ?

Да спасибо foreigner за ссылочку !
я обязательнопоисчу патчи для этого djbdns или может у него уже есть
страничка с патчами ? подкинте а то я нашел его стринцу где много
чего написанно но на патчи ссылок небыло :-(

А вобще это идея связать bind с sql ! Честно я сам все вяжу c mysql
гемороя нет с файлами и выборкой чего угодно :-)

Эй! Вы тут exim забыли! Ядерный демон!!!! И я не нашёл фич, НЕ РЕАЛИЗОВАНЫХ в нём... 8-() 2IZA: напиши мне на moon@nwgsm.ru - я никак не могу разобраться с этим долбанутым smtp-auth...

to Aleks IZA:
Где найти страничку со всевозможными патчами догаться совсем нетрудно,
если имелся опыт с qmail. Это конечно же http://www.djbdns.org/ и раздел
"Contribution". Такая же полная аналогия прослеживается с LWQ ("Life with qmail").
Уже есть и "Life with djbdns" - http://www.lifewithdjbdns.org/

Полезные ресурсы в свете последних событий. Сейчас наблюдаю, как идет битва
на freebsd-security. Правда, не очень жестокая. В-отличие от линукса freebsd
имеет djbdns в портах. Но пипл явно на взводе от подарков, которые преподносит ISC.

Для тех, кто сделал chroot, -g и т.д. и успокоился вопрос на засыпку: а как быть
в случае попытки взлома с прямыми обязанностями, для исполнения которых bind и
был собственно установлен. Или он типа члена королоевской семьи? Или по принципу
"спасыбо, что нэ зарэзал" ж-)

Ща дораскажу :-)
диры значит
chroot/bin
chroot/dev
chroot/etc
chroot/var/named
chroot/var/run!

значит заметим что все принадлежит руту !!!!
пермишин r-x-r-x-r-x
OK в bin тока named и xfrer ну там еще скриптик ndc вобщем чисто бинд!

на bin etc var/named мы вобще делаем chattr +i
туда даже рут ничего незарисует без снятия атрибутов !
Ну а dev и /var/run принадлежит руту и бинд со своимим правими туда ничего
незальет и это радует :-)
аа максимум при переполнении буферра можно что то покласть на диск и потом
выполнять ! Ну зависит от размера проги и чего она юзает !

Дык вот ну допустим мы получили прова бинда и дальше можем попробовать
позапускать xfer например :-) ааах да на сам named и nds у нас права r-x------
ой даж себя незадуунит а ежели и запустит то толку !

Далее да возможен выход из chroot есть такая реальность :-((( ежели
переполнить буфер и дать chroot то получится верю ! даже кой чего запишет в
tmp ! ню прикинем ежели мы tmp обломим для кого попало :-) уже радоснее !

Буду рад дальше продолжить тему ! :-) у кого секреты есть ?

Да вобще многоуровневая защита это что-то !