CVE-2020-8619

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.