The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Опасная DoS-уязвимость в DNS-сервере BIND 9 (доступно обновление)

16.11.2011 21:11

Консорциум ISC уведомил пользователей об обнаружении в DNS-сервере BIND 9 уязвимости, позволяющей удалённо вывести DNS-сервер из строя, отправив специально сформированный рекурсивный запрос. Подробности о методе совершения атаки не сообщаются, известно только то, что данная уязвимость уже активно эксплуатируется злоумышленниками в сети.

Исправление пока недоступно, но в ISC обещает опубликовать патч в ближайшие часы, после завершения его тестирования. В качестве обходного пути защиты можно ограничить выполнение рекурсивных запросов только для доверительных хостов. Уязвимости подвержены все версии BIND 9.x. Определить факт атаки можно по краху named с выводом в лог записи "INSIST(! dns_rdataset_isassociated(sigrdataset))".

Дополнение 1: Выпущены корректирующие версии BIND 9.8.1-P1, 9.7.4-P1, 9.6-ESV-R5-P1, 9.4-ESV-R5-P1 с устранением уязвимости. Статус выпуска обновлений для различных дистрибутивов можно проследить на данных страницах: FreeBSD, Ubuntu, Gentoo, Slackware, Mandriva, openSUSE, CentOS, Fedora, RHEL и Debian.

Дополнение 2: Bind 9.2.x и более старые версии проблеме не подвержены. В Bind 9.3.x уязвимость проявляется только при активной опции dnssec-enable. Начиная с ветки 9.4.x проблема наблюдается независимо от состояния опции dnssec-enable. Пакеты с обновлениями доступны для Debian, Ubuntu и RHEL

  1. Главная ссылка к новости (http://www.isc.org/software/bi...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/32322-bind
Ключевые слова: bind, dns, named
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Mr. Mistoffelees (?), 21:18, 16/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Гм, кто же это держит ra на своем DNS сервере открытым для всего мира?
     
     
  • 2.7, Аноним (-), 22:10, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Гм, кто же это держит ra на своем DNS сервере открытым для всего мира?

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

     
  • 2.24, Vladimir Rusinov (?), 13:14, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Почти все провайдеры, google (8.8.8.8, 8.8.4.4), OpenDNS и еще куча народу.
     

  • 1.9, Аноним (-), 00:34, 17/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Традиция раз в полгода находить в бинде дыры, приводящие к краху.
     
  • 1.10, Аноним (-), 00:58, 17/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Debian, прилетели обновления.
     
     
  • 2.11, pavlinux (ok), 01:16, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я первый увидел!!! :)
     

  • 1.12, Сергей (??), 02:44, 17/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    BIND 9.6-ESV-R1 лёг
    BIND 9.3.4 не лёг
     
     
  • 2.15, solardiz (ok), 05:27, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чем проверяли? Или просто само так вышло?
     
     
  • 3.20, Сергей (??), 11:41, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Сказали лёг dns, как раз читал эту новость. grep'нул логи и нашёл завал сервера после этого сообщения. Кто-то проверил за меня :)
     

  • 1.13, konst (??), 04:05, 17/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >BIND 9.3.4 не лёг

    BIND 9.3.6 даже не соизволил обновится

     
     
  • 2.16, solardiz (ok), 05:32, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > BIND 9.3.6 даже не соизволил обновится

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

    Даже в новых версиях BIND еще сам ISC толком не знает суть проблемы. Предлагаемый для них патч - это workaround.

     

  • 1.14, solardiz (ok), 05:25, 17/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Вот моя попытка понять подвержены ли проблеме версии BIND 9.3.x (официально уже не поддерживаемые ISC) и сборки BIND без поддержки DNSSEC:

    http://www.openwall.com/lists/oss-security/2011/11/17/2

    Пока получается "может быть" и "скорее всего нет", соответственно. Точного ответа пока нет.

     
     
  • 2.36, solardiz (ok), 02:05, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По анализу кода, получается что на 9.3.x проблема проявляется только при включенной опции dnssec-enable, тогда как на 9.4.x+ и без нее тоже:

    http://www.openwall.com/lists/oss-security/2011/11/17/13

    При этом то собран ли BIND с OpenSSL (нужен для полной поддержки DNSSEC) или нет роли не играет.

    Тем временем, Red Hat выпустил обновление для 9.3.6 в RHEL5:

    https://rhn.redhat.com/errata/RHSA-2011-1458.html

    Они патчат как query.c, так и rbtdb.c (аналогично тому как это делается в патче от ISC), хотя maintainer пакета считает достаточными изменения в query.c (и мой вывод о том что требуется опция dnssec-enable на это полагается):

    http://www.openwall.com/lists/oss-security/2011/11/17/11

    Там же - обоснованное мнение, что 9.2.x и старее проблеме не подвержены.

     

  • 1.17, x (?), 07:58, 17/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Что-то в разделе SECURITY ADVISORIES на сайте freebsd.org молчок как про bind, так и про недавно найденый баг в openpam.

    Считают последние две баги несерьёзными что-ли? Или начали перенимать традиции Adobe и M$ неисправлять баги месяцами?

     
     
  • 2.18, Нано анон (?), 10:45, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да уж.. может им некогда-идет работа по девятому релизу?
     
  • 2.19, Аноним (-), 11:08, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Что-то в разделе SECURITY ADVISORIES на сайте freebsd.org молчок как про bind, так и про недавно найденый баг в openpam.

    Баг в openpam проявляется только при установке из портов KDE и не затрагивает базовую систему (т.е. воспринимается как баг, а не как уязвимость). Про корректное исправление дыры в Bind пока мало даже в ISC знают, выпущенный апдейт лишь обходной путь.

     
     
  • 3.21, Аноним (-), 12:37, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Баг в openpam проявляется только при установке из портов KDE и не затрагивает базовую систему (т.е. воспринимается как баг, а не как уязвимость).

    А ничего, что это именно уязвимость, и именно в базовой системе?

     
  • 3.23, Аноним (-), 12:45, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Баг в openpam проявляется только при установке из портов KDE и не затрагивает базовую систему (т.е. воспринимается как баг, а не как уязвимость)

    То есть, тот факт, что можно поиметь рута через дыру _в базовой системе_ - это ни разу не уязвимость?

     
  • 3.31, Аноним (-), 18:09, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Баг в openpam проявляется только при установке из портов KDE и не затрагивает базовую систему (т.е. воспринимается как баг, а не как уязвимость).

    1. Дыра находится в OpenPAM, являющемся компонентом базовой системы.
    2. Кто может гарантировать, что программа kcheckpass является единственным методом эксплуатации этой дыры?

    > Про корректное исправление дыры в Bind пока мало даже в ISC
    > знают, выпущенный апдейт лишь обходной путь.

    Уязвимость активно эксплуатируется в настоящее время. Исправление от вендора есть.
    Команда FreeBSD игнорирует сложившуюся ситуацию. Какими цветистыми словесами это не прикрывай, все равно погано выглядит.

     
     
  • 4.32, qwerty (??), 18:30, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тем более абсурдно ситуация выглядит в том, что в портах бинд пропатчили, а бинд в базовой системе не тронули. Странное какая-то ситуация, первый раз такой пох..зм вижу от разработчиков BSD.

    Может секьюрити офицер в запое? :)

     
     
  • 5.35, J.K. (?), 23:15, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • –5 +/
    о месные оналитеги подтянулись... у них видимо запой как раз закончился..
     

  • 1.27, Аноним (-), 15:30, 17/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какую альтернативу использовать? DJBDNS?
    Спасибо!
     
     
  • 2.28, gyouja (ok), 16:50, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Какую альтернативу использовать? DJBDNS?
    > Спасибо!

    Для обработки рекурсивных запросов и если не нужны views - powerdns.

     
     
  • 3.30, Аноним (-), 18:04, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > powerdns.

    pdns-recursor разве что. В качестве authoritative весьма слаб по фичам.

     
  • 3.33, Клыкастый (ok), 19:12, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    PowerDNS тоже не торт :(
     
  • 2.29, Анонимз (?), 17:52, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Unbound
     
  • 2.34, metallic (ok), 19:30, 17/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Какие требования? DNS-кластер нужен?
     
     
  • 3.37, Аноним (-), 11:31, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Какие требования?

    Требования у всех разные. Абсолютному большинству требований, к сожалению, удовлетворяет только BIND.

     
  • 2.38, ACCA (ok), 07:08, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    djbdns не обрабатывает рекурсивные запросы, для этого у DJ есть dnscache. Работает замечательно.
     
     
  • 3.39, Анонимз (?), 11:53, 21/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    tinydns + dnscache = djbdns
     

  • 1.40, Lol (??), 06:20, 21/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Спасибо собрал Nsd + chroot
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру