Podatności BIND

Atakujący może spowodować przerwanie działania named, wysyłając spreparowane żądanie DNS-over-HTTPS z kryptograficznie nieprawidłowym rekordem SIG(0), a następnie przedwcześnie zamykając połączenie transportowe. Problem dotyczy BIND 9 w wersjach 9.20.0–9.20.27, 9.21.0–9.21.25 oraz 9.20.9-S1–9.20.27-S1.

Nieprawidłowo sformułowane rekordy BRID/HHIT mogą spowodować nieoczekiwane zakończenie działania serwera `named`. Podatność dotyczy określonych wersji BIND 9.

named w BIND 8.2 do 8.2.2-P6 pozwala zdalnym atakującym wywołać odmowę usługi poprzez wysłanie rekordu SRV do serwera. Podatność znana jako "srv bug".

named w BIND 8.2 do 8.2.2-P6 pozwala zdalnym atakującym na wywołanie odmowy usługi poprzez wysłanie żądania kompresowanego transferu strefy (ZXFR) i wykonanie zapytania o rekord autorytatywny, który nie jest buforowany (błąd "zxfr").

Podatność CVE-1999-0024 dotyczy złośliwego ataku na pamięć podręczną DNS poprzez oprogramowanie BIND, wykorzystującego przewidywalne identyfikatory zapytań.

Rekurencyjny serwer BIND, który otrzyma zapytanie z żądaniem rekurencji (RD=1), a następnie zapytanie nierekurencyjne (RD=0), może zakończyć działanie z błędem asercji, powodując odmowę usługi. Aby wystąpiła podatność, serwer BIND musi zezwalać na zapytania rekurencyjne i mieć skonfigurowane co najmniej dwie strefy RPZ: jedną z domyślnym ustawieniem "recursive-only yes", a drugą z "recursive-only no". Problem dotyczy BIND 9 w wersjach 9.16.0 do 9.18.50, 9.20.0 do 9.20.29, 9.21.0 do 9.21.26, 9.11.3-S1 do 9.18.50-S1 oraz 9.20.9-S1 do 9.20.29-S1.

Resolver BIND skonfigurowany zarówno ze strefą "redirect", jak i "qname-minimization strict" może przerwać działanie z błędem asercji podczas przetwarzania przekierowania. Problem dotyczy BIND 9 w wersjach 9.16.0 do 9.18.50, 9.20.0 do 9.20.29, 9.21.0 do 9.21.26, 9.16.8-S1 do 9.18.50-S1 oraz 9.20.9-S1 do 9.20.29-S1.

Odtworzenie podpisanych wiadomości UDP GSS-TSIG może spowodować uszkodzenie pamięci w "named". Atakujący, który przechwyci wcześniej podpisaną wiadomość UDP, może ją odtworzyć, gdy klucz TSIG jest nadal ważny, a także wysyłać spreparowane zapytania do strefy pod swoją kontrolą, co może potencjalnie doprowadzić do zdalnego wykonania kodu.

W resolverze BIND przychodzące komunikaty protokołu DNS o określonej strukturze powodują dodatkowe przetwarzanie bez nałożonego przez BIND limitu. Komunikat DNS z złośliwie dużą liczbą takich struktur spowoduje, że BIND zużyje nieproporcjonalnie dużo czasu CPU i pamięci podczas przetwarzania. Problem dotyczy BIND 9 w wersjach 9.11.0 do 9.18.50, 9.20.0 do 9.20.29, 9.21.0 do 9.21.26, 9.11.3-S1 do 9.18.50-S1 oraz 9.20.9-S1 do 9.20.29-S1.

Jeśli resolver BIND wyśle zapytanie do strefy autorytatywnej podpisanej DNSSEC, a serwer autorytatywny odpowie prawidłową odpowiedzią wildcard i podpisanym dowodem NSEC3, a następnie niepodpisanym NSEC o tej samej nazwie właściciela, spowoduje to nieoczekiwane zakończenie programu. Problem dotyczy BIND 9 w wersjach 9.11.0 do 9.18.50, 9.20.0 do 9.20.27, 9.21.0 do 9.21.25, 9.11.3-S1 do 9.18.50-S1 oraz 9.20.9-S1 do 9.20.27-S1.

W BIND 9 poprawnie podpisany rekord NSEC3 pochodzący z niezwiązanej strefy siostrzanej może zostać zaakceptowany jako dowód braku zabezpieczenia. Prowadzi to do obniżenia poziomu bezpieczeństwa delegacji i przepuszczenia sfałszowanej, niepodpisanej odpowiedzi.

Jeśli BIND zostanie załadowany z plikiem named.conf, który nie zawiera globalnego bloku options, atakujący może wysłać zapytanie QTYPE TKEY, co może spowodować błąd asercji i nieoczekiwane zakończenie programu. Problem dotyczy BIND 9 w wersjach 9.20.0–9.20.27, 9.21.0–9.21.25 oraz 9.20.9-S1–9.20.27-S1.

W odpowiedzi na zapytanie atakujący może wysłać do usługi named wiele kopii rekordu, który powinien występować tylko raz (np. SOA). Gdy RDATA jest identyczna we wszystkich kopiach, rekord jest dodawany do zestawu RDATA w pamięci, co zwiększa zużycie pamięci przez negatywny cache.

Rekurencyjny resolver BIND może doświadczyć nadmiernego zużycia zasobów w przypadku napotkania dużej liczby określonego rodzaju nieprawidłowych rekordów DNSSEC. Domyślne limity max-records-per-type i max-types-per-name pomagają ograniczyć ekspozycję.

Na resolverze skonfigurowanym do używania dns64, jeśli odpowiedź z serwera autorytatywnego jest zniekształcona w określony sposób, proces named resolvera zakończy się nieoczekiwanie. Problem dotyczy BIND 9 w wersjach 9.11.0–9.18.50, 9.20.0–9.20.27, 9.21.0–9.21.25, 9.11.3-S1–9.18.50-S1 oraz 9.20.9-S1–9.20.27-S1.

Dla strefy wtórnej z transferami ograniczonymi przez TSIG usługa named może zacząć serwować dane z transferu strefy przed nadejściem końcowej wiadomości z podpisem TSIG. Może to pozwolić atakującemu bez ważnego podpisu TSIG na przesłanie nieautoryzowanej zawartości strefy do serwera wtórnego, a named nie wycofuje się do stanu sprzed transferu.

Jeśli resolver BIND ma w pamięci podręcznej drzewo rekordów SVCB/HTTPS AliasMode, a następnie zostanie zapytany o korzeń tego drzewa, resolver zużywa nieproporcjonalnie dużo czasu CPU na konstruowanie odpowiedzi. Problem dotyczy BIND 9 w wersjach 9.18.0–9.18.50, 9.20.0–9.20.27, 9.21.0–9.21.25, 9.18.11-S1–9.18.50-S1 oraz 9.20.9-S1–9.20.27-S1.

Resolver BIND napotykający rekord SVCB/HTTPS AliasMode odwołujący się do 14 lub więcej rekordów SVCB/HTTPS ServiceMode może nie zwolnić prawidłowo zasobów wewnętrznych. Jeśli sytuacja powtarza się, wyczerpanie zasobów uniemożliwi resolverowi wykonywanie nowych zapytań rekurencyjnych. Problem dotyczy BIND 9 w wersjach 9.18.0–9.18.50, 9.20.0–9.20.27, 9.21.0–9.21.25, 9.18.11-S1–9.18.50-S1 oraz 9.20.9-S1–9.20.27-S1.

Wadliwa strefa może zawierać węzeł NS lub DNAME powyżej swojego pochodzenia, który `named` traktuje jako przecięcie strefy. Jeśli atakujący wstawi wadliwą strefę do autorytatywnego serwera BIND (np. przez transfer strefy), zapytania o nazwy wewnątrz skonfigurowanej strefy tracą status autorytatywny i zwracają delegację poza strefą. Na serwerze, który zapewnia również rekurencję, BIND może podążać za tym lokalnie źródłowym przecięciem i buforować dane dostarczone przez atakującego, wpływając na nazwy poza skonfigurowaną strefą. Sytuacja utrzymuje się tak długo, jak wadliwa strefa pozostaje w bazie stref. Problem dotyczy BIND 9 w wersjach 9.11.0 do 9.18.50, 9.20.0 do 9.20.27, 9.21.0 do 9.21.25, 9.11.3-S1 do 9.18.50-S1 oraz 9.20.9-S1 do 9.20.27-S1.

Nieodpowiedni rekord NSEC może zostać zaakceptowany przez resolver `named` jako dowód, że nie istnieje wildcard, co może pozwolić atakującemu na tym samym lub wyższym poziomie nazwy strefy na maskowanie istnienia rekordu wildcard ofiary. Problem dotyczy BIND 9 w wersjach 9.11.0 do 9.18.50, 9.20.0 do 9.20.27, 9.21.0 do 9.21.25, 9.11.3-S1 do 9.18.50-S1 oraz 9.20.9-S1 do 9.20.27-S1.

Jeśli kontrolowany przez atakującego serwer autorytatywny może zwrócić odpowiedź negatywną o rozmiarze dokładnie 65536 bajtów, wada w named powoduje utworzenie wpisu negatywnego cache o rozmiarze 0 bajtów. Przy późniejszym odczycie tego wpisu named ulega awarii.

Atakujący może spowodować przerwanie działania resolwera `named`. Atak wymaga nakłonienia resolwera ofiary do wysłania wielu zapytań o strefę podpisaną DNSSEC, hostowaną przez autorytatywny serwer kontrolowany przez atakującego. Jeśli serwer odpowie określoną sekwencją spreparowanych odpowiedzi, a odpowiedzi dotrą w określonej kolejności i z określonym czasem, resolver `named` napotka błąd use-after-free i przerwie działanie. Problem dotyczy BIND 9 w wersjach 9.11.0 do 9.18.50, 9.20.0 do 9.20.27, 9.21.0 do 9.21.25, 9.11.3-S1 do 9.18.50-S1 oraz 9.20.9-S1 do 9.20.27-S1.

Resolver BIND akceptuje prawidłowo podpisane rekordy NSEC, w których pole "Next Domain Name" wskazuje poza strefę podpisującego. Problem dotyczy wersji BIND 9 od 9.11.0 do 9.18.50, 9.20.0-9.20.24, 9.21.0-9.21.23 oraz wersji S1.

BIND 9 w określonych wersjach może niespodziewanie zakończyć działanie z asercją podczas walidacji dowodu, jeśli domena objęta jest zarówno rekordem NSEC, jak i NSEC3, a istnieje RRSIG tylko dla jednego z tych typów.

W BIND 9 występuje podatność prowadząca do nieoczekiwanego zakończenia procesu named. Problem pojawia się przy specyficznym zestawieniu odpowiedzi na zapytania o rekordy CNAME, DNAME i A, gdy autorytatywny serwer opóźnia odpowiedź.

W BIND 9 istnieje podatność, w której atakujący może odpowiedzieć na zapytanie rekordem RRSIG z mniejszą liczbą etykiet niż strefa, w której się znajduje. Powoduje to wygenerowanie nazwy wildcard dla krótszej strefy, co może prowadzić do zatrucia pamięci podręcznej (cache poisoning). Atak jest skuteczny tylko przy włączonej opcji synth-from-dnssec (domyślnie włączone).

Resolver DNSSEC podatny na atak losową subdomeną może doświadczyć niekontrolowanego wzrostu użycia pamięci, przekraczającego limit max-cache-size. Atakujący musi wysyłać zapytania szybciej niż resolver może przeprowadzać walidację.

Podatność na wyczerpanie zasobów w BIND związana z walidacją DNSSEC. Serwer zawsze waliduje wszystkie rekordy RRSIG w odpowiedzi, nawet jeśli nie są potrzebne, co prowadzi do nadmiernego zużycia CPU.

W BIND 9 występuje podatność związana z przetwarzaniem RPZ z politykami CNAME z użyciem symboli wieloznacznych. Atakujący może wysłać zapytanie o długą nazwę, wywołując błąd NAMETOOLONG, co może prowadzić do ominięcia reguł RPZ lub nieoczekiwanego zakończenia działania BIND 9.

Błąd w BIND 9: akceptacja nieprawidłowej struktury danych w rekordzie DNS (algorytm PRIVATEDNS z nieprawidłową długością) może prowadzić do przerwania działania serwera przy próbie renderowania rekordu na tekst.

BIND może akceptować nieprawidłowe rekordy NSEC3 strefy podrzędnej jako poprawne, co może pozwolić atakującemu na sfałszowanie uwierzytelnionych odpowiedzi NXDOMAIN. Podatność dotyczy wersji BIND 9 od 9.18.0 do 9.18.50, 9.20.0 do 9.20.24, 9.21.0 do 9.21.23 oraz odpowiednich wersji -S1.

Nieograniczona pętla ponownych wysyłań w resolverze BIND 9 podczas obsługi błędnego serwera. Zdalny, nieuwierzytelniony atakujący może spowodować wyczerpanie zasobów poprzez wysyłanie zapytań wyzwalających określone warunki ponawiania.

W serwerze DNS BIND 9 w wersjach 9.20.0 do 9.20.22, 9.21.0 do 9.21.21 oraz 9.20.9-S1 do 9.20.22-S1 występuje podatność na użycie po zwolnieniu (use-after-free) spowodowana wyścigiem. Podczas walidacji podpisu SIG(0) dla przychodzącej wiadomości DNS, po osiągnięciu limitu 'recursive-clients' i odrzuceniu wiadomości, walidacja może próbować odczytać już odrzuconą wiadomość. Wersje 9.18.28-9.18.49 i 9.18.28-S1-9.18.49-S1 nie są podatne.

Wiele błędów w `named` dotyczących obsługi komunikatów DNS z klasami innymi niż IN (np. CHAOS, HESIOD) lub meta-klasami (ANY, NONE). Specjalnie spreparowane zapytania mogą powodować błędy asercji w `named`.

Podatność use-after-free w implementacji DNS-over-HTTPS w BIND 9 wersje 9.20.0-9.20.22, 9.21.0-9.21.21 oraz 9.20.9-S1-9.20.22-S1. Wersje 9.18.x nie są dotknięte.

Rozwiązania BIND są podatne na atak amplifikacji wyczerpania zasobów. Jeśli resolver ofiary wykona zapytanie do specjalnie spreparowanej strefy, zużyje nieproporcjonalnie dużo zasobów. Podatność dotyczy wielu wersji BIND 9.

Podatność w serwerach BIND skonfigurowanych do uwierzytelniania TKEY z tokenami GSS-API. Otrzymanie spreparowanych pakietów może prowadzić do nadmiernego zużycia pamięci, co skutkuje odmową usługi.

Specjalnie spreparowana domena może spowodować wyciek pamięci w resolverze BIND poprzez samo zapytanie o tę domenę. Podatność dotyczy BIND 9 w wersjach 9.20.0 do 9.20.20, 9.21.0 do 9.21.19 oraz 9.20.9-S1 do 9.20.20-S1.

Podatność na nadmierne zużycie CPU w resolverze BIND 9 podczas walidacji DNSSEC w przypadku złośliwie spreparowanej strefy. Serwery autorytatywne są generalnie niezagrożone, ale mogą wykonywać zapytania rekurencyjne w pewnych okolicznościach.

W określonych okolicznościach, z powodu słabości generatora liczb pseudolosowych (PRNG), atakujący może przewidzieć port źródłowy i identyfikator zapytania (query ID), które BIND będzie używać. Problem dotyczy wersji BIND 9: 9.16.0-9.16.50, 9.18.0-9.18.39, 9.20.0-9.20.13, 9.21.0-9.21.12 oraz wersji -S1 odpowiednio.

W pewnych okolicznościach serwer BIND jest zbyt liberalny przy akceptowaniu rekordów z odpowiedzi, co pozwala atakującemu na wstrzyknięcie sfałszowanych danych do pamięci podręcznej. Problem dotyczy wielu wersji BIND 9.

W resolverze BIND 9 skonfigurowanym z stale-answer-enable yes oraz stale-answer-client-timeout 0 osiągnięcie limitu recursive-clients może wywołać pętlę w named i nieoczekiwane zakończenie działania z powodu przepełnienia stosu.

Instancja named działająca jako walidujący DNSSEC resolver rekursywny z włączoną opcją synth-from-dnssec (RFC 8198) może zostać zdalnie zakończona przez strefę z nieprawidłowym rekordem NSEC.

W BIND 9 rekursywny resolver named utrzymuje bazę cache z limitem max-cache-size. Odkryto, że skuteczność algorytmu czyszczenia cache można poważnie osłabić, wysyłając zapytania o określone RRsety w odpowiedniej kolejności, co pozwala znacząco przekroczyć skonfigurowany limit pamięci.

Poprzez podszywanie się pod resolver docelowy z odpowiedziami zawierającymi nieprawidłowy podpis EdDSA, atakujący może wywołać niewielki wyciek pamięci. Możliwe jest stopniowe wyczerpanie dostępnej pamięci, aż do awarii usługi named z powodu braku zasobów.

Poprzez podszywanie się pod resolver docelowy z odpowiedziami zawierającymi nieprawidłowy podpis ECDSA, atakujący może wywołać niewielki wyciek pamięci. Możliwe jest stopniowe wyczerpanie dostępnej pamięci, aż do awarii usługi named z powodu braku zasobów.

Poprzez zalanie docelowego resolvera zapytaniami wykorzystującymi tę wadę, atakujący może znacznie pogorszyć wydajność resolvera, skutecznie odmawiając legalnym klientom dostępu do usługi rozwiązywania nazw DNS.

W ISC BIND9 w wersjach BIND 9.11.14 -> 9.11.19, BIND 9.14.9 -> 9.14.12, BIND 9.16.0 -> 9.16.3, BIND Supported Preview Edition 9.11.14-S1 -> 9.11.19-S1: Dopóki serwer nazw nie świadczy usług autorytatywnych dla jednej lub więcej stref i co najmniej jedna strefa nie zawiera pustego wpisu nieterminalnego z gwiazdką ("*"), ten defekt nie może wystąpić. Potencjalny atakujący, który ma możliwość zmiany zawartości strefy, mógłby teoretycznie wprowadzić taki rekord, aby wykorzystać ten warunek do spowodowania odmowy usługi, choć uważamy użycie tego wektora za mało prawdopodobne, ponieważ taki atak wymagałby znacznego poziomu uprawnień i byłby łatwy do wyśledzenia.

Funkcja "managed-keys" w BIND umożliwia automatyczne utrzymywanie kluczy używanych przez kotwice zaufania. Z powodu błędu w tej funkcji serwer BIND używający managed-keys może zakończyć działanie z powodu błędu asercji, jeśli podczas rotacji kluczy klucze kotwicy zaufania zostaną zastąpione kluczami używającymi nieobsługiwanego algorytmu. Dotknięte wersje: BIND 9.9.0 -> 9.10.8-P1, 9.11.0 -> 9.11.5-P1, 9.12.0 -> 9.12.3-P1 oraz wersje 9.9.3-S1 -> 9.11.5-S3 BIND 9 Supported Preview Edition. Wersje 9.13.0 -> 9.13.6 gałęzi rozwojowej 9.13 również są dotknięte. Wersje wcześniejsze niż BIND 9.9.0 nie zostały ocenione pod kątem podatności na CVE-2018-5745.

Podatność CVE-1999-0837 dotyczy usługi BIND, która może być narażona na atak typu denial of service (DoS) z powodu niewłaściwego zamykania sesji TCP za pomocą opcji so_linger.