Vulnerabilidades

*** Pendiente de traducción *** In NLnet Labs Unbound 1.23.0 up to and including 1.25.1, when 'dns-error-reporting: yes' is set, the EDNS Report-Channel option (code 18) from the last upstream response is read and uses the option's length as the length of the agent domain. When a domain name check is performed on the agent domain, the returned lenght is not used and if the agent domain is followed by garbage, those bytes are moved onto the tail of the synthetic '_er.' report query name. That query name is later used in the iterator via a subquery to send out the DNS Error Report and when Unbound tries to walk that query name during 'find_closest_of_type()', it strips labels using the query name length rather than stopping at the embedded root, walks one byte past it, and feeds the first garbage byte to 'dname_query_hash()' as a label length writing over the stack variable 'labuf'. One ordinary upstream response from a delegated zone the attacker controls is sufficient to terminate the daemon.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when the 'dnscrypt:' clause lists more 'dnscrypt-provider-cert:' files than there are matching 'dnscrypt-secret-key:' files, Unbound fills only the matched prefix and leaves the tail slots at the '0xdb' fill that libsodium's allocator writes into every allocation. Unbound would then iterate over the number of cert files, not the actual slots, so it walks into a slot with garbage data filled with '0xdb' bytes. Any unauthenticated client that sends one UDP datagram of ≥ 68 bytes whose first 8 bytes are '0xdb' to 'dnscrypt-port' will use that garbage entry which leads to a garbage dereference killing the server. This is a silent faulty configuration that goes unnoticed until triggered with the right client query. Unbound needs to be compiled with DNSCrypt support ('--enable-dnscrypt').

*** Pendiente de traducción *** In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, a remote unauthenticated client can trigger a libngtcp2 assertion (if compiled with assertions on) and terminate the entire Unbound process using a single DNS-over-QUIC (DoQ) connection and one normal DNS query. This is caused by an erroneous error value passed to libngtcp2. When 'ngtcp2_conn_writev_stream()' returns 'NGTCP2_ERR_STREAM_DATA_BLOCKED', Unbound continues to call 'ngtcp2_ccerr_set_application_error()' with a '-1' error value. The 'int' literal '-1' is implicitly converted to the function's 'uint64_t error_code' parameter as '0xFFFFFFFFFFFFFFFF'. The follow-on 'ngtcp2_conn_write_connection_close()' serialises that value as a QUIC variable-length integer; because '2^64-1' exceeds the 62-bit varint ceiling, 'ngtcp2_put_uvarintlen()' fails 'assert(n

*** Pendiente de traducción *** In NLnet Labs Unbound 1.15.0 up to and including 1.25.1, the TLS server name used for DNS-over-TLS (DoT) forwarded queries is tied to a struct's ('serviced_query') lifetime but also referenced by another struct ('waiting_tcp'). When the owning struct is jostled out of the mesh while the DoT TCP stream is still handshaking it frees the storage behind the referenced string and if the TLS stream then errors out, it dereferences the freed pointer. The dereference is read-only and the practical impact is a daemon crash resulting in denial of service. A malicious actor that knows a DoT forwarding/stub Unbound's configuration could exploit the vulnerability by quering records in the appropriate zone while keeping Unbound uder pressure so that the jostle logic kicks in. If answers for the vulnerable zone are slow, the likelihood of jostling such queries is higher, although the timing of the jostle needs to be precise. Requirements for a vulnerable Unbound is the existence of a stub/forward zone configured for DoT together with a configured '#authname' suffix on the server identification. The connectivity to the server needs to exhibit a transient failure at the correct time in order to kick off the vulnerable error path.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.6.2 up to and including 1.25.1, when Unbound is configured with the 'respip' module in front of the validator together with a 'response-ip' redirect rule or an RPZ file with an RPZ-IP trigger, the rewriting handler does not check the security status of the upstream answer and can instead rewrite a BOGUS A/AAAA answer to point to an operator's configured IP. If the validator finds an expired or otherwise invalid RRSIG on an answer whose A record falls within a 'response-ip'/RPZ configuration, the answer is still rewritten and given a hard coded security level of INSECURE. This results in the client receiving an INSECURE NOERROR reply rewritten by the operator's configured IP. A malicious actor can exploit the possible poisonous effect by spoofing a BOGUS A/AAAA answer that falls inside the operator's configured subnet rewrites. Such DNSSEC protected answers are then insecurely redirected to the operator's configured target.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when an auth/rpz zone has a configured primary hostname that resolves to BOGUS A/AAAA, it is still considered as a possible XFR endpoint. A malicious actor that can spoof the hostname's A/AAAA record (no valid RRSIG required) becomes the zone's XFR primary and can replaces the entire zone/the resolver's entire response policy.

*** Pendiente de traducción *** In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and 127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The counter resets to zero on every cache flush, so the attack loops forever.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.25.0 up to and including 1.25.1, a fix that makes the 'respip' and 'dns64' modules work together, creates a shallow copy of the view name in effect that could lead to memory corruption if the owner of the original view name is jostled out when Unbound is under pressure. Unbound needs to be configured with one of 'respip'/'rpz' modules, together with a module that can attach subqueries (respip CNAME redirection, dns64, subnetcache) and a configured 'access-control-view' while Unbound is under pressure so that joslte logic kicks in and starts dropping slow queries. The subquery is getting a shallow copy of the view name and if the super query which owns the view name is jostled out, memory corruption can occur. Likelihood of a crash is low, since it relies heavily on the underlying memory allocator and the memory layout. Debug memory builds (e.g., ASAN) that catch the free terminate the server.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, insufficient validation of the RRSIG.Labels field combined with premature cache writes during RFC 8198 aggressive NSEC processing leads to cache poisoning that permits a malicious actor controlling a single delegated zone to poison arbitrary sibling zones under NSEC-signed parent domains. A malicious actor with one registered domain under an NSEC-signed TLD can serve malicious insecure DNS responses for unrelated sibling domains (sharing the same parent zone). Arbitrary delegations that do not exist under the parent domain and are covered by the parent's NSEC chain can be brought into insecure existence by fraudulent wildcard DS records (less labels than expected, unknown algorithm) from the malicious sibling domain. This allows the malicious actor to inject insecure wildcard records for those delegations.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is injected into the response, the wildcard rrset will update the expired sibling record with a secure status before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC accompanying rrset.

*** Pendiente de traducción *** In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, a single client query for a deeply nested name under a DNSSEC-signed parent can cause Unbound to send more upstream packets per client query than the configured 'max-global-quota'. This effectively bypasses a security configuration that limits upstream amplification traffic.