Podatności CoreDNS

CoreDNS w wersjach przed 1.14.3 nieprawidłowo obsługuje uwierzytelnianie TSIG w transportach gRPC, QUIC, DoH i DoH3. W przypadku gRPC i QUIC serwer sprawdza tylko nazwę klucza TSIG, ale nie weryfikuje HMAC, przez co każde żądanie z pasującą nazwą klucza jest uznawane za uwierzytelnione. W przypadku DoH i DoH3 problem jest poważniejszy – serwer w ogóle nie sprawdza rekordu TSIG, więc każde żądanie z TSIG jest traktowane jako uwierzytelnione.

CoreDNS to serwer DNS napisany w Go. Przed wersją 1.14.7, nasłuchy DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC i DNS-over-gRPC w plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go i core/dnsserver/server_grpc.go wywołują dns.Msg.Unpack bez polityki żądań dns.DefaultMsgAcceptFunc używanej przez UDP, TCP i DNS-over-TLS. Nieuwierzytelniony klient może wysłać aktualizację RFC 2136, którą plugin proxy lub forward przekazuje bez zmian do aktualizowalnego upstreamu. Jeśli ten upstream ufa adresowi źródłowemu lub połączeniu CoreDNS i nie wymaga nieznanego atakującemu end-to-end TSIG, żądanie wydaje się pochodzić z CoreDNS i może dodawać, zastępować lub usuwać rekordy DNS, przekierowywać ruch, przejmować nazwy, zmieniać routing poczty lub zakłócać strefę zapisywalną. Problem został naprawiony w wersji 1.14.7.

CoreDNS to serwer DNS napisany w Go. Przed wersją 1.14.7, ścieżki żądań DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC i DNS-over-gRPC w plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go i core/dnsserver/server_grpc.go wywołują dns.Msg.Unpack na liczbach sekcji kontrolowanych przez atakującego przed walidacją stałego nagłówka przez dns.DefaultMsgAcceptFunc. Nieuwierzytelniony klient może użyć kompresji nazw DNS i nadmiernych liczb sekcji, aby wzmocnić alokację przed łańcuchem pluginów, więc ograniczanie szybkości na poziomie pluginu nie może zapobiec wyczerpaniu pamięci przez równoczesne żądania i zakończeniu działania CoreDNS. Zwykłe nasłuchy UDP i TCP nie są dotknięte, ponieważ najpierw walidują nagłówek. Problem został naprawiony w wersji 1.14.7.

W CoreDNS od wersji 1.9.4 do 1.14.5 wykryto podatność, w której klient DNS żądający transferu strefy AXFR może spowodować panikę (panic) serwera. Problem występuje przy konfiguracji k8s_external z headless-service, gdy endpoint nie ma zadeklarowanych portów. Poprawiono w wersji 1.14.5.

Podatność w CoreDNS przed wersją 1.14.4 pozwala na awarię procesu przez pojedynczy 28-bajtowy datagram UDP, gdy włączona jest wtyczka proxyproto. Błąd występuje w obsłudze nagłówka PROXY v2 z nie-UDP transportem.

CoreDNS przed wersją 1.14.5 zawiera podatność w pluginie rewrite, gdzie brak sprawdzenia wartości NULL po wywołaniu res.IsEdns0() może prowadzić do paniki i awarii procesu. Zdalny, nieuwierzytelniony klient może wysłać pojedyncze zapytanie DNS, powodując panikę i degradację dostępności.

CoreDNS w wersjach przed 1.14.3 zawiera podatność w pluginie transfer, która może wybrać niewłaściwy blok ACL, gdy skonfigurowano zarówno strefę nadrzędną, jak i bardziej szczegółową podstrefę. Funkcja longestMatch() w plugin/transfer/transfer.go używa leksykograficznego porównania stringów zamiast rzeczywistego dopasowania najdłuższego sufiksu. W rezultacie permisywna reguła transferu dla strefy nadrzędnej może nadpisać restrykcyjną regułę dla podstrefy w zależności od kolejności nazw stref (np. "example.org." > "a.example.org." leksykograficznie). Pozwala to nieautoryzowanemu zdalnemu klientowi na wykonanie AXFR/IXFR dla podstrefy i pobranie pełnej zawartości strefy. Problem został naprawiony w wersji 1.14.3.

CoreDNS przed wersją 1.14.3 pozwala na obejście uwierzytelniania TSIG na transportach innych niż czysty DNS (DoT, DoH, DoH3, DoQ, gRPC). Wtyczka tsig ufa metodzie TsigStatus() dostarczonej przez writer transportu, która dla DoH/DoH3/DoQ/gRPC zawsze zwraca nil, a dla DoT nie ustawia TsigSecret. Umożliwia to nieuwierzytelnionemu klientowi dostęp do zasobów chronionych polityką tsig require all.

CoreDNS w wersjach przed 1.14.3 ma lukę, która pozwala na przyjmowanie zbyt dużych wartości parametru dns= w zapytaniach DoH GET, co prowadzi do kosztownego przetwarzania przed odrzuceniem żądania. Problem ten został naprawiony w wersji 1.14.3.

CoreDNS w wersjach przed 1.14.3 ma podatność, która pozwala zdalnemu klientowi na nieograniczony wzrost goroutine i pamięci poprzez otwieranie wielu strumieni QUIC i wysyłanie tylko 1 bajta na strumień. Problem ten został naprawiony w wersji 1.14.3.

W CoreDNS przed wersją 1.14.2 wykryto podatność na atak DoS w pluginie wykrywającym pętle. Atakujący może wysłać specjalnie spreparowane zapytania DNS, które wykorzystują przewidywalny generator liczb pseudolosowych (PRNG) do utworzenia sekretnej nazwy zapytania, co prowadzi do błędu krytycznego i zatrzymania całego procesu serwera.

W CoreDNS przed wersją 1.14.2 wykryto podatność logiczną, która umożliwia ominięcie kontroli dostępu DNS. Wynika to z domyślnej kolejności wykonywania wtyczek, gdzie wtyczki bezpieczeństwa (np. acl) są przetwarzane przed wtyczką rewrite, co prowadzi do błędu typu Time-of-Check Time-of-Use (TOCTOU).

W CoreDNS przed wersją 1.14.0, implementacje serwera gRPC, HTTPS i HTTP/3 nie mają odpowiednich limitów zasobów. Nieuwierzytelniony atakujący zdalnie może wyczerpać pamięć i zdegradować lub zawiesić serwer, otwierając wiele jednoczesnych połączeń, strumieni lub wysyłając zbyt duże ciała żądań.

W coredns wykryto błąd polegający na nieprawidłowej implementacji buforowania, co może prowadzić do zwracania nieprawidłowych wpisów w pamięci podręcznej.