Podatności Hickory DNS

W bibliotece Hickory DNS (hickory-resolver 0.26.0-beta.1 przed 0.26.2) występuje nieograniczona pętla ponowień w NameServerPool::try_send, która ponownie kolejkuje obcięte odpowiedzi (TC) bez sprawdzania transportu i liczby iteracji. Złośliwy serwer autorytatywny zwracający TC=1 na każdym transporcie utrzymuje resolver w pętli na trwałym połączeniu TCP aż do wygaśnięcia 5-sekundowego terminu, powodując wyczerpanie zasobów.

hickory-proto i hickory-resolver 0.26.0 przed 0.26.2, hickory-server 0.25.0-alpha.1 przed 0.26.2 oraz hickory-recursor 0.25.0-alpha.3 do 0.26.0-alpha.1 nie kanonikalizują adresów IPv6 mapowanych na IPv4 podczas sprawdzania reguł deny_answers, deny_server lub AccessControlSet. Atakujący mogą użyć adresów mapowanych IPv4, aby ominąć filtrowanie odpowiedzi, wywołać zapytania do zabronionych serwerów nazw lub dotrzeć do wdrożeń biblioteki hickory-server na gniazdach dual-stack IPv6 od zabronionych klientów.

Rekursor Hickory DNS we wszystkich wersjach hickory-recursor oraz w hickory-resolver 0.26.0-beta.1 przed 0.26.2 (funkcja recursor) jest podatny na ataki ghost domain names, ponieważ ponownie wykorzystuje zestawy rekordów NS typu apex po stronie dziecka z pamięci podręcznej zapytań NS strefy do rozwiązywania iteracyjnego. Poprzez wielokrotne odpytywanie rekordów NS strefy atakujący utrzymuje nieaktualny zestaw RR w pamięci podręcznej bezterminowo, pozwalając serwerom nazw, których delegacja została cofnięta przez rodzica, nadal odpowiadać za strefę.

Hickory DNS hickory-proto 0.25.0 do 0.26.0-alpha.1 oraz hickory-net 0.26.0-beta.1 przed 0.26.2 odwracają operatory relacyjne w gałęzi wrap-around funkcji find_covering_record() w nsec3.rs, przez co ostatni rekord NSEC3 w pierścieniu hash strefy obejmuje każdy hash z wyjątkiem swojego właściciela. Atakujący zdolni do wstrzykiwania odpowiedzi DNS mogą odtworzyć ten rekord NSEC3 i jego RRSIG, aby sfałszować negatywne odpowiedzi walidowane przez DNSSEC, odmawiając istnienia legalnych nazw.

Hickory DNS hickory-proto 0.25.0-alpha.3 do 0.25.2 oraz hickory-net 0.26.0-alpha.1 przed 0.26.2 zawierają błąd walidacji DNSSEC w DnssecDnsHandle, który akceptuje odpowiedzi NODATA podpisane NSEC3 dla zapytań o wierzchołek strefy jako bezpieczne bez rekordu NSEC3 pasującego do zahashowanej QNAME. Atakujący pośrednik lub złośliwy serwer autorytatywny mogą odtworzyć prawidłowo podpisany NSEC3 niebędący wierzchołkiem wraz z podpisanym SOA strefy, aby dostarczyć uwierzytelnione (AD=1) zaprzeczenie dowolnego typu RR wierzchołka na czas TTL negatywnej pamięci podręcznej.

Hickory DNS hickory-proto w wersjach przed 0.26.0-beta.1 oraz hickory-net w wersjach przed 0.26.2 zawierają obejście walidacji DNSSEC, ponieważ verify_rrsets() ignoruje klasę DNS przy partycjonowaniu RRsetów, przez co rekordy inne niż IN pomijają weryfikację podpisu, ale są oznaczane jako bezpieczne, gdy rekordy IN przejdą weryfikację. Atakujący mogący dostarczyć odpowiedzi DNS może dołączyć sfałszowane rekordy klasy CH lub HS, w tym rekordy DS, aby uwierzytelnić dowolny DNSKEY i sfałszować odpowiedzi strefy podrzędnej.

Rekursor walidujący w Hickory DNS hickory-recursor 0.25.0 do 0.26.0-alpha.1, hickory-resolver 0.26.0-alpha.1 przed 0.26.2 oraz hickory-net 0.26.0-beta.1 przed 0.26.2 buforuje odpowiedzi uznane za DNSSEC-bogus, używając niezaufanego TTL dostarczonego przez atakującego (ograniczonego do 24 godzin) zamiast krótkiego TTL błędu walidacji. Zdalny atakujący, który podszyje się pod pojedynczą odpowiedź autorytatywną z nieprawidłowym podpisem i długim TTL, może utrzymać fałszywy wynik w pamięci podręcznej przez maksymalnie 24 godziny.

Hickory DNS hickory-proto 0.25.0-alpha.1 do 0.26.0-alpha.1 oraz hickory-net przed 0.26.2 zawierają błąd logiczny w ścieżce pobierania DS w DnssecDnsHandle, który buforuje przejściowe błędy wyszukiwania DS jako werdykty walidacji DNSSEC typu Bogus. Atakujący, który wywoła odpowiedź SERVFAIL, REFUSED lub timeout na podzapytanie DS strefy podrzędnej, powoduje, że walidator zwraca SERVFAIL dla wszystkich nazw w tej strefie do czasu wygaśnięcia wpisu w pamięci podręcznej.

Hickory DNS (hickory-proto do 0.26.0-alpha.1 i hickory-net 0.26.0-beta.1 przed 0.26.2) zawiera błąd walidacji DNSSEC w obsłudze NSEC walidującego rekursora, który akceptuje rekordy NSEC delegacji przodka po stronie rodzica jako dowód nieistnienia nazw poniżej punktu cięcia strefy. Atakujący w ścieżce, złośliwy serwer nazw rodzica lub atakujący wygrywający wyścig portu i TXID może dostarczyć jedną sfałszowaną odpowiedź NXDOMAIN zbudowaną z autentycznie podpisanych rekordów NSEC rodzica, powodując uwierzytelnione zaprzeczenie istniejących nazw strefy podrzędnej w pamięci podręcznej na czas ujemnego TTL.

Hickory DNS (hickory-proto 0.25 do 0.26.0-alpha.1 i hickory-net 0.26.0-beta.1 przed 0.26.2) zawiera błąd walidacji DNSSEC w obsłudze NSEC3 walidującego rekursora, który dopasowuje najbliższy obwód wyłącznie po hashu bez sprawdzania bitmapy typów, akceptując rekordy NSEC3 delegacji przodka po stronie rodzica jako dowód nieistnienia. Atakujący dostarczający jedną odpowiedź zbudowaną z autentycznie podpisanych rekordów NSEC3 rodzica może spowodować zapisanie NXDOMAIN lub NODATA z AD=1, odmawiając rozwiązywania istniejących nazw w punkcie cięcia strefy i poniżej.

Hickory DNS hickory-proto do 0.26.0-alpha.1 oraz hickory-net 0.26.0-beta.1 przed 0.26.2 zawierają błąd walidacji NSEC, który zwraca bezpieczny dowód dla odpowiedzi NXDOMAIN, gdy Next Domain Name pokrywającego NSEC jest ścisłym potomkiem nazwy zapytania, co w rzeczywistości dowodzi, że nazwa istnieje jako pusty nieterminal. Atakujący pośrednik może zmienić niepodpisany kod odpowiedzi autentycznej podpisanej odpowiedzi NODATA z NOERROR na NXDOMAIN, powodując akceptację sfałszowanego nieistnienia nazwy przez walidatory.

Hickory DNS hickory-net 0.26.0-beta.1 przed 0.26.2 oraz hickory-proto 0.24.0 do 0.26.0-alpha.1 porównują klucze publiczne DNSKEY z zaufanymi kotwicami DNSSEC bez sprawdzania nazwy rekordu DNSKEY, więc zestaw RR składający się wyłącznie z zaufanych kluczy jest akceptowany bez weryfikacji RRSIG. Atakujący zdolni do podszycia się lub kontrolowania odpowiedzi serwera nazw mogą zastąpić zestaw DNSKEY bezpiecznej strefy kluczami strefy głównej i użyć dużego TTL, aby utrzymać go w pamięci podręcznej.

Crate hickory-net w Hickory DNS 0.26.0-beta.1 przed 0.26.2 pozwala na obejście walidacji DNSSEC, ponieważ Hash w Name ignoruje długości etykiet, a ValidationCacheKey porównuje tylko ten hash. Atakujący kontrolujący niepodpisaną delegację, której nazwa różni się od podpisanego celu tylko pozycjami kropek, może zainicjować werdykt Insecure, powodując pominięcie weryfikacji podpisu dla sfałszowanych odpowiedzi celu zamiast zwrócenia SERVFAIL.

Hickory DNS (hickory-net 0.26.0-beta.1 przed 0.26.2 oraz hickory-proto do 0.26.0-alpha.1) nie weryfikuje zgodnie z RFC 6840 §4.4, że rekord NSEC lub NSEC3 zaprzeczający zbiorowi DS potwierdza również istnienie rekordu NS delegacji. Atakujący mogą ponownie wykorzystać rekordy NSEC/NSEC3 strony podrzędnej, aby sfałszować niezabezpieczoną delegację i podrobić rekordy strefy podrzędnej.

Hickory DNS (hickory-net 0.26.0-beta.1 przed 0.26.2 oraz hickory-proto do 0.26.0-alpha.1) akceptuje rekordy NSEC i NSEC3 jako dowód nieistnienia w DNSSEC, gdy dowolny inny rekord o tej samej nazwie właściciela przejdzie walidację podpisu. Atakujący mogący dostarczać odpowiedzi DNS mogą mieszać poprawnie podpisane rekordy z fałszywymi rekordami NSEC/NSEC3 tego samego typu w sekcji authority, aby podrobić dowody nieistnienia.

Rekursywny resolver w Hickory DNS (wszystkie wersje hickory-recursor i hickory-resolver 0.26.0 przed 0.26.2) zapisuje pustą pulę połączeń, gdy podąża za skierowaniem bez rekordów glue i wszystkie zapytania o adresy IP serwerów nazw kończą się niepowodzeniem. Atakujący mogący sfałszować odpowiedzi DNS może spowodować niepowodzenie tych wyszukiwań, co prowadzi do niepowodzenia wszystkich kolejnych zapytań dla dotkniętej strefy aż do wygaśnięcia lub usunięcia wpisu z pamięci podręcznej.

Walidacja DNSSEC w bibliotece hickory-net (Hickory DNS) 0.26.0 przed 0.26.2 identyfikuje rekordy NSEC z zawijaniem, porównując następną nazwę domeny z rekordem SOA w odpowiedzi, akceptując ten SOA nawet jeśli nie przechodzi walidacji. Atakujący mogący dostarczać odpowiedzi DNS mogą połączyć prawdziwy rekord NSEC i jego RRSIG ze spreparowanym rekordem SOA, aby podrobić nieistnienie dowolnego zbioru RRset.

Hickory DNS 0.25.0-alpha.3 do 0.25.2 zawiera podatność na amplifikację zapytań w rekursywnym resolverze, który nieprawidłowo obsługuje cykliczne skierowania do siostrzanych serwerów nazw bez rekordów glue. Atakujący kontrolujący dwie strefy, których serwery nazw odwołują się wzajemnie bez rekordów glue, może zmusić rekursor do pętli, wysyłając wiele zapytań w górę, dodatkowo amplifikowanych przez rekordy NS z TTL równym zero.

Komponent hickory-resolver w Hickory DNS 0.25.0 przed 0.26.2 podąża za nieistotnymi rekordami CNAME podczas rozwiązywania zapytań rekurencyjnych, wysyłając zapytania niepotrzebne do odpowiedzi na pierwotne żądanie. Atakujący kontrolujący odpowiedzi DNS mogą umieszczać rekordy CNAME w sekcjach authority lub additional albo poza łańcuchem CNAME pierwotnej nazwy, powodując nadmiarowe zapytania resolvera i zwiększoną amplifikację zapytań.

Biblioteka hickory-net w Hickory DNS 0.26.0 przed 0.26.2 przestaje nasłuchiwać i zwraca błąd, gdy klient UDP otrzyma datagram, którego nie można sparsować jako wiadomości DNS. Zdalni atakujący, którzy odgadną port źródłowy zapytania, bez znajomości identyfikatora transakcji, mogą podszyć zniekształcone odpowiedzi, aby przerwać zapytania klienta i spowodować odmowę usługi.

Rekursor rekurencyjny w Hickory DNS hickory-recursor 0.25.0 do 0.25.2 oraz hickory-resolver 0.26.0 przed 0.26.2 nie stosuje filtrowania out-of-bailiwick do odpowiedzi negatywnych. Atakujący mogący dostarczyć spreparowane odpowiedzi negatywne może dołączyć rekordy spoza strefy, aby ułatwić zatruwanie pamięci podręcznej i łatwiej wykorzystać inne błędy weryfikacji DNSSEC.

Walidujący rekursor rekurencyjny i walidujący forwarder w Hickory DNS (hickory-server) 0.25.0 przed 0.26.2 nie sprawdzają, czy rekord SOA przeszedł walidację DNSSEC podczas składania odpowiedzi NXDOMAIN lub NODATA. Atakujący mogący dostarczyć sfałszowane odpowiedzi DNS może spowodować zwrócenie klientom sfałszowanego rekordu SOA z ustawionym bitem AD, wprowadzając w błąd klientów polegających na walidacji DNSSEC serwera.

Hickory DNS (hickory-proto do 0.26.0-alpha.1 oraz hickory-net 0.26.0-beta.1 przed 0.26.2) zawiera błąd walidacji DNSSEC, który akceptuje odpowiedź jako pozytywną, gdy w sekcji answer pojawi się dowolny poprawny zbiór RRset, bez sprawdzenia, czy odpowiada on zapytaniu. Atakujący mogą dostarczyć podpisane, ale niepowiązane zbiory RRset, aby odpowiedzi bez pasujących rekordów zostały zwalidowane jako pozytywne zamiast jako brak danych.

Hickory DNS (hickory-net 0.26.0-beta.1 przed 0.26.2 i hickory-proto do 0.26.0-alpha.1) wykonuje niewystarczające sprawdzenia nazw rekordów NSEC3 podczas weryfikacji DNSSEC, porównując tylko etykietę hasha bez potwierdzenia, że rekord należy do właściwej strefy. Atakujący może dostarczyć rekordy NSEC3 z innej strefy z pasującą etykietą hasha, aby sfałszować dowody nieistnienia DNSSEC.

Walidacja DNSSEC w Hickory DNS hickory-net 0.26.0-beta.1 przed 0.26.2 oraz hickory-proto do 0.26.0-alpha.1 nie odróżnia odpowiedzi NODATA od pozytywnych odpowiedzi rozwiniętych z wildcard. Dla zapytania, które powinno zwrócić NODATA w strefie z rekordami wildcard, atakujący może połączyć rekord NSEC3 pasujący do nazwy zapytania z podpisanym rekordem wildcard w fałszywą odpowiedź pozytywną, którą walidacja akceptuje.

Hickory DNS hickory-net 0.26.0 przed 0.26.2 oraz hickory-proto 0.25.0 do 0.25.2 pomijają sprawdzenie, czy sekcja pytań odpowiedzi UDP odpowiada zapytaniu, gdy odpowiedź ma pustą sekcję pytań (QDCOUNT=0), a także pomijają sprawdzenie randomizacji wielkości liter. Zdalni atakujący mogący wstrzyknąć sfałszowane odpowiedzi UDP mogą wysyłać odpowiedzi z QDCOUNT=0, aby obejść te sprawdzenia, osłabiając obronę przed podszywaniem się DNS.

Hickory DNS od 0.24.0 przed 0.26.2 zawiera podatność na wyczerpanie zasobów umożliwiającą zdalnym atakującym zużycie pamięci serwera poprzez nieograniczone ciała żądań DoH. Atakujący mogą wysyłać duże ciała żądań przez HTTP/2 lub HTTP/3 do serwera DNS over HTTP, powodując wyczerpanie pamięci i odmowę usługi.

Hickory DNS 0.24.0 do 0.26.1 zawiera podatność na wyczerpanie pamięci umożliwiającą zdalnym atakującym zużycie zasobów serwera poprzez wysyłanie niekompletnych ciał żądań DNS-over-QUIC. Atakujący mogą otwierać wiele połączeń i wysyłać tylko duże prefiksy długości, powodując utrzymywanie wstępnie alokowanych buforów bez limitu czasu i wyczerpanie pamięci serwera.

Hickory DNS przed 0.26.2 zawiera podatność na wyczerpanie zasobów w serwerze DNS-over-HTTPS HTTP/2, który nie ma wystarczających limitów czasu ani ograniczeń dla niekompletnych ciał żądań. Zdalni atakujący mogą otwierać połączenia DoH, wysyłać niekompletne ciała żądań i utrzymywać połączenia otwarte, aby wyczerpać pamięć serwera.

Parser plików stref w crate hickory-proto Hickory DNS 0.24.0 przed 0.26.2 panikuje, gdy pojedynczy token w pliku strefy ma 4096 bajtów lub więcej. Atakujący mogący dostarczyć niezaufane pliki stref do aplikacji korzystającej z parsera może wywołać panikę i spowodować odmowę usługi.

Podatność w parserze formatu prezentacji rekordów SVCB i HTTPS w hickory-proto (hickory-dns) w wersjach od 0.20.1 do 0.26.2. Atakujący może dostarczyć niezaufany plik strefy, w którym pojedynczy lub podwójny cudzysłów zastępuje wartość parametru usługi, co wywołuje panic i crash procesu parsującego.

Podatność w parserze formatu prezentacji rekordów SVCB i HTTPS w hickory-proto (hickory-dns) w wersjach od 0.20.1 do 0.26.2, powodująca panic przy nieprawidłowych wartościach alpn. Atakujący może dostarczyć niezaufane pliki stref z niezrównoważonymi cudzysłowami, kolejnymi przecinkami lub nieprawidłowymi sekwencjami ucieczki w parametrach alpn, co crashuje proces parsujący.

Podatność polegająca na niedomiarze liczby całkowitej w dekodowaniu TSIG RDATA w Hickory DNS w wersjach od 0.26.0 do 0.26.2. Atakujący może wysłać spreparowany rekord TSIG w formacie wire DNS, powodując niezaznaczone odejmowanie z niedomiarem, co crashuje kompilacje z włączonymi sprawdzeniami przepełnienia i prowadzi do odmowy usługi.