CVE-2024-0874

CoreDNS before version 1.14.0 has a vulnerability in gRPC, HTTPS, and HTTP/3 server implementations that lack critical resource-limiting controls. An unauthenticated remote attacker can exhaust memory and degrade or crash the server by opening many concurrent connections.

CoreDNS versions prior to 1.14.3 incorrectly handle TSIG authentication in gRPC, QUIC, DoH, and DoH3 transports. For gRPC and QUIC, the server only checks the TSIG key name but does not validate the HMAC, so any request with a matching key name is considered authenticated. For DoH and DoH3, the issue is more severe – the server never inspects the TSIG record at all, so any request with TSIG is treated as authenticated.

CoreDNS is a DNS server written in Go. Prior to 1.14.7, the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners in plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go call dns.Msg.Unpack without the dns.DefaultMsgAcceptFunc request policy used by UDP, TCP, and DNS-over-TLS. An unauthenticated client can send an RFC 2136 UPDATE that the proxy or forward plugin passes unchanged to an update-capable upstream. If that upstream trusts CoreDNS's source address or connection and does not require an attacker-unknown end-to-end TSIG, the request appears to originate from CoreDNS and can add, replace, or delete DNS records, redirect traffic, take over names, alter mail routing, or disrupt the writable zone. This issue is fixed in version 1.14.7.

CoreDNS is a DNS server written in Go. Prior to 1.14.7, the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC request paths in plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go call dns.Msg.Unpack on attacker-controlled DNS section counts before dns.DefaultMsgAcceptFunc validates the fixed header. An unauthenticated client can use DNS name compression and excessive section counts to amplify allocation before the plugin chain, so plugin-level rate limiting cannot prevent concurrent requests from exhausting memory and terminating CoreDNS. The ordinary UDP and TCP listeners are not affected because they validate the header first. This issue is fixed in version 1.14.7.

In CoreDNS from version 1.9.4 to 1.14.5, a network DNS client requesting AXFR zone transfer can trigger a panic when configured with k8s_external headless-service zone transfers and a headless service endpoint with no declared ports. Fixed in version 1.14.5.

Vulnerability in CoreDNS before version 1.14.4 allows a single 28-byte UDP datagram to crash the process when the proxyproto plugin is enabled. The bug is in handling PROXY v2 headers with non-UDP transport.

CoreDNS prior to 1.14.5 has a vulnerability in the rewrite plugin where a missing nil check after calling res.IsEdns0() can cause a panic and crash the process. A remote, unauthenticated client can send a single DNS query to trigger this, degrading availability.

CoreDNS versions prior to 1.14.3 have a vulnerability in the transfer plugin that can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. The longestMatch() function in plugin/transfer/transfer.go uses a lexicographic string comparison instead of an actual longest-suffix match. As a result, a permissive parent-zone transfer rule can override a restrictive subzone rule depending on zone name ordering (e.g., "example.org." > "a.example.org." lexicographically). This allows an unauthorized remote client to perform AXFR/IXFR for the subzone and retrieve its full zone contents. This issue has been fixed in version 1.14.3.

CoreDNS before version 1.14.3 allows TSIG authentication bypass on non-plain-DNS transports (DoT, DoH, DoH3, DoQ, gRPC). The tsig plugin trusts the transport writer's TsigStatus(), which always returns nil for DoH/DoH3/DoQ/gRPC and does not set TsigSecret for DoT. This lets an unauthenticated client access resources protected by a tsig require all policy.

CoreDNS versions prior to 1.14.3 have a vulnerability that allows oversized dns= query parameter values in DoH GET requests, leading to expensive processing before rejecting the request. This issue has been fixed in version 1.14.3.