The OpenNET Project / Index page

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

Обновление DNS-сервера BIND 9.11.22, 9.16.6, 9.17.4 с устранением 5 уязвимостей

21.08.2020 11:11

Опубликованы корректирующие обновления стабильных веток DNS-сервера BIND 9.11.22 и 9.16.6, а также находящейся в разработке экспериментальной ветки 9.17.4. В новых выпусках устранено 5 уязвимостей. Наиболее опасная уязвимость (CVE-2020-8620) позволяет удалённо вызвать отказ в обслуживании через отправку определённого набора пакетов на TCP-порт, на котором принимает соединения BIND. Отправка на TCP-порт аномально больших запросов AXFR, может привести к тому, что обслуживающая TCP-соединение библиотека libuv передаст серверу размер, приводящий к срабатыванию проверки assertion и завершению процесса.

Другие уязвимости:

  • CVE-2020-8621 - атакующий может инициировать срабатывание проверки assertion и экстренное завершение резолвера при попытке минимизации QNAME после перенаправления запроса. Проблема проявляется только на серверах с включённой минимизацией QNAME, работающих в режиме 'forward first'.
  • CVE-2020-8622 - атакующий может инициировать срабатывание проверки assertion и экстренное завершение рабочего процесса в случае если DNS-сервер атакующего вернёт в ответ на запрос DNS-сервера жертвы некорректные ответы с подписью TSIG.
  • CVE-2020-8623 - атакующий может инициировать срабатывание проверки assertion и экстренное завершение обработчика через отправку специально оформленных запросов зоны, подписанной ключом RSA. Проблема проявляется только при сборке сервера с опцией "--enable-native-pkcs11".
  • CVE-2020-8624 - атакующий, имеющий полномочия изменять содержимое определённых полей в DNS-зонах, может получить дополнительные привилегии для изменения другого содержимого DNS-зоны.


  1. Главная ссылка к новости (https://seclists.org/oss-sec/2...)
  2. OpenNews: Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-соединений
  3. OpenNews: Обновление DNS-сервера BIND 9.11.18, 9.16.2 и 9.17.1
  4. OpenNews: Выпуск DNS-сервера BIND 9.16.0
  5. OpenNews: Обновление DNS-сервера BIND 9.14.3, 9.11.8, 9.15.1 с устранением DoS-уязвимости
  6. OpenNews: Выпуск BIND 9.14.0, разрывающий совместимость с серверами, не отвечающими на запросы с EDNS
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/53577-bind
Ключевые слова: bind, dns
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:52, 21/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    вот бы на расте писали бы его и небыло
     
     
  • 2.2, Аноним (2), 12:01, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А где в новости про переполнение буфера, Фракталушка? Там билиотека корректно определяет размер, а проге большие пакеты не нравятся и она решает корректно завершиться. Т.е. проблема в алгоритмах, от чего Ржавый не спасёт.
     
     
  • 3.3, Аноним (3), 12:58, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > она решает корректно завершиться

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

    Это как если бы ты увидел в этом предложении очепяткуAssertion error: unknown word "очепятку"

     
     
  • 4.4, YAAnonim (?), 14:22, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В расте тоже нет исключений.
     
  • 4.7, Аноним (7), 14:32, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для обработки ошибок не всегда нужны исключения. Но обработчики ошибок надо же писать, проще просто написать assert не задумываясь о последствиях
     
     
  • 5.16, _ (??), 17:21, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Докажешь что не задумываясь?
    Я вот вижу что обмозговали и поставили assert.

    PS: А не с жЫсЫ проггером ли я спорю? Пойду руки помою на всякий ...

     
  • 5.27, Webmonkey (?), 20:12, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это не была обработка ошибок. Ассерт в данном случае использован совершенно корректно для проверки инварианта.
     
  • 2.5, Michael Shigorin (ok), 14:28, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Вы "писали бы его" на расте -- его и нет, что характерно...
     
  • 2.9, Аноним (9), 15:53, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На расте бы это никогда не написали. Да и не напишут.

    Рас это такие розовые очки. "Вот иесли бы да кабы..." но так сказкой и остаётся.

     
     
  • 3.13, НяшМяш (ok), 16:32, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Rust просто неадекватно переусложнён. Хеллоуворлды на нём выглядят красиво, а как что-то сложнее - так даже глаза за символы зацепиться не могут.

    А так DNS сервера даже на JS бывают https://www.npmjs.com/search?q=dns%20server

     
     
  • 4.30, Аноним (30), 20:50, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пиши на Ziglang
     
  • 2.28, microsoft (?), 20:40, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Напиши, а после удали и раст заодно тоже
     

  • 1.6, Аноним (7), 14:30, 21/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Подход долбанов, вместо обработки даже самых простых ошибок сразу крашить приложение
     
     
  • 2.10, Ordu (ok), 15:54, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Подход долбанов -- это когда опыта нет, а мнение есть. Тебе не приходилось сталкиваться с ситуацией, когда в твою функцию через аргументы закидывают указатель, и ты в документации к ней написал, что указатель должен быть !NULL, но тем не менее, зная как это бывает, решил написать:

    if(ptr == NULL) {
        // ???
    }

    Вот ты написал это, и что ты будешь писать вместо ??? ? Какое осмысленное действие можно совершить, кроме уронить приложение к чертям? Как вообще можно осмысленно реагировать на то, что кто-то зачем-то засунул тебе NULL туда, куда NULL пихать нельзя?

    Есть один способ: можно закладывать в API возможность выкинуть совершенно любую ошибку, в надежде что вызывающий код сможет найти способ отреагировать осмысленно. Но для этого а) надо закладывать возможность выкинуть любую ошибку, б) для вызывающего кода эта ошибка, практически наверняка, будет такой же бессмыслицей: то есть если программист даже и допустит возможность такой ошибки, он не сможет найти осмысленного способа отреагировать.

    Обработка ошибок -- это очень занятная штука: если проследить весь путь ошибки от места, где код решил, что это ошибка, и до того места, где есть возможность ошибку обработать осмысленно (а не просто преобразовать к другому типу ошибки и пробросить дальше), то можно много чудных открытий сделать: например, смысл ошибки меняется по мере размотки стека. В момент детекта ошибки, это был unexpected char, потом эта ошибка превратилась в spurious brace, потом в malformed indexing operator invocation, а затем вдруг в YOUR CONFIG FILE HAD BEEN EDITED BY A MORON, GO AND FIX IT NOW.

     
     
  • 3.11, Аноним (9), 16:21, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачёт, нравится читать когда осмысленно пишут и со знанием дела.
     
  • 3.12, Аноним (3), 16:28, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > кто-то зачем-то засунул тебе NULL туда, куда NULL пихать нельзя

    Если контракт нарушен программистом (id est контролируемым источником), крашиться не только можно, но и нужно. Так быстрее обнаружим ошибку. В некоторых языках твои нуллы отловятся еще на этапе компиляции, так что не получится даже запуститься, чтобы закрашиться.

    Если контракт нарушен пользователем (id est неконтролируемым источником), крашиться нельзя.

    Если на ноль делит программист непосредственно в исходниках -- крашимся. Если делит на ноль пользователь в гуйном калькуляторе -- не крашимся и показываем ошибку. Отличаешь ситуации? В новости именно второй вариант.

     
     
  • 4.31, Sw00p aka Jerom (?), 22:18, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Крешиться или нет это вопрос критичности участка кода. Если ситуация такая, что дальнейщее исполнение алгоритма теряет смысл, то останавливаем исполнение. Крах и немедленная остановка процесса исполнения - разные вещи.

    >Если на ноль делит программист непосредственно в исходниках -- крашимся.

    Это должен отловить компилятор, как тоже самое отлавливает ЦПУ или рантайм любого языка. И собственно происходит выброс исключения которое можно обработать.

     
  • 3.14, Аноним (7), 17:11, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил все, вместо того чтобы:
    отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают крашить.
    Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то лучше вернуть ошибку, а не уронить все сразу. Если нет возможности вернуть ошибки, значит тут выхода больше нет.
     
     
  • 4.21, Ordu (ok), 17:44, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил
    > все, вместо того чтобы:
    > отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают
    > крашить.
    > Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то
    > лучше вернуть ошибку, а не уронить все сразу. Если нет возможности
    > вернуть ошибки, значит тут выхода больше нет.

    Ты не думал, что эти ситуации могут жить совместно?

    Пришёл неправильный пакет, ты это обнаружил, но лишь по косвенным признакам: тебе прилетел NULL туда, куда не должен прилетать. Что ты будешь делать?

    Ну, точнее не так, это не ты обнаружил неправильный пакет, всё что ты обнаружил, что твоя программа иногда получает NULL там, где его не должно быть. Копая глубже, ты выяснил, что в процессе разборки запроса был упущен какой-то вариант кривости запроса, и вместо генерации ошибки, была сгенерирована кривая структура, описывающая этот запрос. Кривая структура ушла дальше на выполнение, и там вдруг образовался NULL в переменной, которая NotNULL. Но все эти копания произошли позже, уже после того как программа упала. А упасть она смогла, вместо выхода за границы массива, благодаря тому, что ты поставил assert в том месте, где по идее не могло быть NULL, или len>=size, или ещё чего-нибудь. Ты не видел как такое может случится, ты не знал как реагировать на то, что на твой взгляд не может случится, но на всякий случай подстраховался assert'ом.

     
     
  • 5.24, Аноним (3), 17:49, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > программа иногда получает NULL там, где его не должно быть

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

     
     
  • 6.32, Sw00p aka Jerom (?), 22:29, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот, вот. Нулл всегда можно обработать если есть эдакий "контракт".
     
  • 3.15, Аноним (9), 17:20, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И в коментах ниже каждый смотри с разного уровня. Кто сверху в низ, кто с низу в верх. И каждый пытается конкретный случай притощить как универсальное решение.

    Ребята вы все правы.

     
     
  • 4.20, _ (??), 17:42, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я - прав. By definition (C) ;-p
     
  • 3.29, Аноним (29), 20:49, 21/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Всё верно!
    Фактически assert это своего рода документирование контракта. Т.е. предполагается, что дальнейший код написан с учетом этого допущения, т.е. что ptr != NULL.
    Но это не значит, что он не мог быть написан иначе, просто такой контракт.
    Далее вызывающая сторона должна что-то с этим решать, т.е. либо обеспечить этот контакт самостоятельно или "экспортировать" контракт выше.
    Как видно, в данном случае контракт, что условный ptr != NULL был экспортирован вплоть до обработки входных данных. А в таком случае контракт означает "наш сервер написан с допущением, что к нему приходят только правильные запросы". Наверное и так можно для какой-то поделки, аля тест или proof of concept, но точно не для real world server.

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

     
  • 3.33, Аноним (33), 06:12, 24/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > f(ptr == NULL) {
    >    // ???
    >}

    По обыкновению exit(-1).
    Дальше или пусть сырцы курят или маны дрочат.
    А и комент ставить надо - тут пришла не та хрень, продолжаю работать, а хрень по боку. И дату, и подпись.

     
  • 3.35, я (?), 11:30, 28/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    if(ptr == NULL) {
    ptr = default_ptr;
    }

    например

     
     
  • 4.36, Ordu (ok), 12:24, 28/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > if(ptr == NULL) {
    >  ptr = default_ptr;
    > }
    > например

    size_t strlen(const char *s) {
        if(s == NULL) {
            s = ???;
        }
        // бла-бла-бла
    }

    что надо подставить вместо ???

     

  • 1.8, Аноним (9), 15:52, 21/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это всё фрактал напортил. Поэтому он теперь бегает и кричит про сишные дырени и сам больше ничего не делает.
     
     
  • 2.34, Аноним (33), 06:13, 24/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если Вы вуцчили 32 ключевых слова языка С, то вы еще не программист. ДАЛЕКО не програмист. Програмист это состояние души а не требования по з/п.
     

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



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

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