UNBOUND

Unbounded name compression could lead to Denial of Service

Malicious upstreams responses with very large RRsets can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks.

The vulnerability can be exploited by a malicious actor querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete.

Unbound version 1.21.1 introduces a hard limit on the number of name compression calculations it is willing to do per packet. Packets that need more compression will result in semi-compressed packets or truncated packets, even on TCP for huge messages, to avoid locking the CPU for long.

This change should not affect normal DNS traffic.

Unbound 1.21.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2024-8508.diff and then run make install to install Unbound.

Unbound vulnerable to the "DNSBomb" pulsing DoS amplification attack

The DNSBomb attack, via specially timed DNS queries and answers, can cause a Denial of Service on resolvers and spoofed targets.

Unbound itself is not vulnerable for DoS, rather it can be used to take part in a pulsing DoS amplification attack.

The DNSBomb attack works by sending low-rate spoofed queries for a malicious zone to Unbound. By controlling the delay of the malicious authoritative answers, Unbound slowly accumulates pending answers for the spoofed addresses. When the authoritative answers become available to Unbound at the same time, Unbound starts serving all the accumulated queries. This results into large-sized, concentrated response bursts to the spoofed addresses.

From version 1.20.0 on, Unbound introduces a couple of configuration options to help mitigate the impact. Their complete description can be found in the included manpages but they are also briefly listed here together with their current default values for convenience:

• discard-timeout: 1900

  After 1900 ms a reply to the client will be dropped. Unbound would still work on the query but refrain from replying in order to not accumulate a huge number of "old" replies. Legitimate clients retry on timeouts.

• wait-limit: 1000 / wait-limit-cookie: 10000

  Limits the amount of client queries that require recursion (cache-hits are not counted) per IP address. More recursive queries than the allowed limit are dropped. Clients with a valid EDNS Cookie can have a different limit, higher by default. wait-limit: 0 disables all wait limits.

• wait-limit-netblock / wait-limit-cookie-netblock

  These do not have a default value but they can fine grain configuration for specific netblocks. With or without EDNS Cookies.

The options above are trying to shrink the DNSBomb window so that the impact of the DoS from Unbound is significantly lower than it used to be and making the attack, and Unbound's participation, less tempting for attackers.

Unbound 1.20.0 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2024-33655.diff and then run make install to install Unbound.

Denial of service when trimming EDE text on positive replies

Unbound 1.18.0 introduced a feature that removes EDE records from responses with size higher than the client's advertised buffer size. Before removing all the EDE records however, it would try to see if trimming the extra text fields on those records would result in an acceptable size while still retaining the EDE codes. Due to an unchecked condition, the code that trims the text of the EDE records could loop indefinitely. This happens when Unbound would reply with attached EDE information on a positive reply and the client's buffer size is smaller than the needed space to include EDE records.

The vulnerability can only be triggered when the 'ede: yes' option is used; non default configuration.

From version 1.19.2 on, the code is fixed to avoid looping indefinitely.

Unbound 1.19.2 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2024-1931.diff and then run make install to install Unbound.

DNSSEC verification complexity can be exploited to exhaust CPU resources and stall DNS resolvers

A DNSSEC validation vulnerability has been discovered in various DNSSEC validating software. The vulnerability has an assigned number of CVE-2023-50387 and is referred here as the KeyTrap vulnerability.

The KeyTrap vulnerability works by using a combination of Keys (also colliding Keys), Signatures and number of RRSETs on a malicious zone. Answers from that zone can force a DNSSEC validator down a very CPU intensive and time costly validation path.

It can force Unbound to spend an enormous time (comparative to regular traffic) validating a single specially crafted DNSSEC response while everything else is on hold for that thread. A trivially orchestrated attack could render all threads busy with such responses leading to denial of service.

From version 1.19.1 on, Unbound introduces suspension on DNSSEC response validations that seem to require more attempts than Unbound is willing to make per response validation run. Suspension means that Unbound will continue with other work before resuming a suspended validation offering CPU time between validation resumptions to other tasks. There is a backoff timer when suspending which is further influenced by the number of suspends already used and the amount of work currently in Unbound.

The introduced builtin limits in Unbound are:

• Max 4 DNSSEC key collissions are allowed when building chain of trust. More than that without a secure key treats the delegation as bogus.
• 8 validation attempts per RRSET (combination of keys + signatures). If more are needed and Unbound has yet to find a valid signature the RRSET is treated as bogus.
• More than 8 validation attempts per answer will suspend validation.
• The limit of total suspensions is 16 after which the query will error out. Any completed RRSET validations populate the cache for use in future queries.

While under attack Unbound could show higher CPU load because of the needed validations but the suspend strategy would guarantee the CPU is not locked on any particular validation task.

Unbound 1.19.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2023-50387_CVE-2023-50868.diff and then run make install to install Unbound.

This is a shared patch with CVE-2023-50868 below

NSEC3 closest encloser proof can exhaust CPU

A DNSSEC validation vulnerability has been discovered in various DNSSEC validating software. The vulnerability has an assigned number of CVE-2023-50868 and is referred here as the NSEC3 vulnerability.

The NSEC3 vulnerability uses specially crafted responses on a malicious zone with multiple NSEC3 RRSETs to force a DNSSEC validator down a very CPU intensive and time costly NSEC3 hash calculation path.

It can force Unbound to spend an enormous time (comparative to regular traffic) validating a single specially crafted DNSSEC response while everything else is on hold for that thread. A trivially orchestrated attack could render all threads busy with such responses leading to denial of service.

From version 1.19.1 on, Unbound introduces suspension on DNSSEC response validations that seem to require more attempts than Unbound is willing to make per response validation run. Suspension means that Unbound will continue with other work before resuming a suspended validation offering CPU time between validation resumptions to other tasks. There is a backoff timer when suspending which is further influenced by the number of suspends already used and the amount of work currently in Unbound.

The introduced builtin limits for the NSEC3 vulnerability in Unbound are:

• 8 NSEC3 hash calculations are allowed before suspension. More than that will suspend validation.
• The limit of total suspensions is 16 after which the query will error out. Any completed RRSET validations populate the cache for use in future queries.

While under attack Unbound could show higher CPU load because of the needed validations but the suspend strategy would guarantee the CPU is not locked on any particular validation task.

Unbound 1.19.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2023-50387_CVE-2023-50868.diff and then run make install to install Unbound.

This is a shared patch with CVE-2023-50387 above

Non-Responsive Delegation Attack

A vulnerability named 'Non-Responsive Delegation Attack' (NRDelegation Attack) has been discovered in various DNS resolving software. The NRDelegation Attack works by having a malicious delegation with a considerable number of non responsive nameservers. The attack starts by querying a resolver for a record that relies on those unresponsive nameservers.

The attack can cause a resolver to spend a lot of time/resources resolving records under a malicious delegation point where a considerable number of unresponsive NS records reside. It can trigger high CPU usage in some resolver implementations that continually look in the cache for resolved NS records in that delegation. This can lead to degraded performance and eventually denial of service in orchestrated attacks.

Unbound does not suffer from high CPU usage, but resources are still needed for resolving the malicious delegation. Unbound will keep trying to resolve the record until hard limits are reached. Based on the nature of the attack and the replies, different limits could be reached.

From version 1.16.3 on, Unbound introduces fixes for better performance when under load, by cutting opportunistic queries for nameserver discovery and DNSKEY prefetching and limiting the number of times a delegation point can issue a cache lookup for missing records.

Unbound 1.16.3 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2022-3204.diff and then run make install to install Unbound.

Novel "ghost domain names" attack by updating almost expired delegation information

NLnet Labs Unbound, up to and including version 1.16.1, is vulnerable to a novel type of the "ghost domain names" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a rogue domain name when the cached delegation information is about to expire. The rogue nameserver delays the response so that the cached delegation information is expired. Upon receiving the delayed answer containing the delegation information, Unbound overwrites the now expired entries. This action can be repeated when the delegation information is about to expire making the rogue delegation information ever-updating. From version 1.16.2 on, Unbound stores the start time for a query and uses that to decide if the cached delegation information can be overwritten.

Unbound 1.16.2 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2022-30698_CVE-2022-30699.diff and then run make install to install Unbound.

This is a shared patch with CVE-2022-30698 below

Novel "ghost domain names" attack by introducing subdomain delegations

NLnet Labs Unbound, up to and including version 1.16.1 is vulnerable to a novel type of the "ghost domain names" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a subdomain of a rogue domain name. The rogue nameserver returns delegation information for the subdomain that updates Unbound's delegation cache. This action can be repeated before expiry of the delegation information by querying Unbound for a second level subdomain which the rogue nameserver provides new delegation information. Since Unbound is a child-centric resolver, the ever-updating child delegation information can keep a rogue domain name resolvable long after revocation. From version 1.16.2 on, Unbound checks the validity of parent delegation records before using cached delegation information.

Unbound 1.16.2 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2022-30698_CVE-2022-30699.diff and then run make install to install Unbound.

This is a shared patch with CVE-2022-30699 above

Local symlink attack

Unbound when writing and later chown'ing the PID file would not check if an existing file was a symlink. This is a local vulnerability that could create a Denial of Service of the system Unbound is running on. It requires an attacker having access to the limited permission user Unbound runs as and point through the symlink to a critical file on the system.

Unbound 1.13.0 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_cve-2020-28935_unbound.diff and then run make install to install Unbound.

Vulnerability in Domain Parse

Fuzzing of the Unbound code made us aware of issues in the parser of received answers. Malformed answers received from upstream servers can result in Unbound entering an infinite loop and thereby becoming unresponsive. When compiled with --enable-debug it is also possible to trigger an assertion, resulting in Unbound to crash.

Unbound 1.10.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p1 < filename, then run make install to install Unbound.

NXNSAttack

Researchers from Tel Aviv University discovered an issue in Unbound and other DNS resolvers that makes it possible to have a single incoming query result in a large number of outgoing queries. This amplification makes it possible for Unbound to be used in a denial of service attack. The researchers discovering this called this attack the NXNSattack.

This attack makes use of cache bypassing using random subdomains in the NSDNAME in NS records. When these delegation records are received during iteration, and the answer does not contain glue records, a resolver has to send out a query to the get the IP address for one of the names. When this query fails (for example because the random name does not exist) a resolver will try the next one. A large set of NS records with random names can result in a large number of outgoing queries going to the same target. More details about this attack will be available in the research paper.

Unbound 1.10.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p1 < filename, then run make install to install Unbound.

Vulnerability in IPSEC module

Due to unsanitized characters passed to the ipsecmod-hook shell command, it is possible for Unbound to allow shell code execution from a specially crafted IPSECKEY answer.

This issue can only be triggered when all of the below conditions are met:

• unbound was compiled with --enable-ipsecmod support, and
• ipsecmod is enabled and used in the configuration (either in the configuration file or using unbound-control), and
• a domain is part of the ipsecmod-whitelist (if ipsecmod-whitelist is used), and
• unbound receives an A/AAAA query for a domain that has an A/AAAA record(s) and an IPSECKEY record(s) available.

The shell code execution can then happen if either the qname or the gateway field of the IPSECKEY (when gateway type == 3) contain a specially crafted domain name.

Unbound 1.9.5 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p1 < filename, then run make install to install Unbound.

Vulnerability in parsing NOTIFY queries

Due to an error in parsing NOTIFY queries, it is possible for Unbound to continue processing malformed queries and may ultimately result in a pointer dereference in uninitialized memory. This results in a crash of the Unbound daemon.

Unbound 1.9.4 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.

Vulnerability in the processing of wildcard synthesized NSEC records

We discovered a vulnerability in the processing of wildcard synthesized NSEC records. While synthesis of NSEC records is allowed by RFC4592, these synthesized owner names should not be used in the NSEC processing. This does, however, happen in Unbound 1.6.7 and earlier versions.

Unbound 1.6.8 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.

A special thanks goes out to Karst Koymans (University of Amsterdam) for sparking the discovery of this vulnerability by Ralph Dolmans (NLnet Labs).

Ghost domain names attack

The resolver in Unbound before 1.4.11 overwrites cached server names and TTL values in NS records during the processing of a response to an A record query, which allows remote attackers to trigger continued resolvability of revoked domain names via a "ghost domain names" attack. To resolve this issue, upgrade to a newer version of Unbound.

Incorrect proof processing for NSEC3-signed zone

validator/val_nsec3.c in Unbound before 1.4.13p2 does not properly perform proof processing for NSEC3-signed zones, which allows remote DNS servers to cause a denial of service (daemon crash) via a malformed response that lacks expected NSEC3 records, a different vulnerability than CVE-2011-4528.

Unbound 1.4.14 contains a patch, but 1.4.14rc1 is vulnerable. If you cannot upgrade you can also apply a patch. For unbound version 1.4.0 - 1.4.13, apply this patch and for version 1.0.1 - 1.3.4 use this patch. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.

Processing of duplicate CNAME records in a signed zone

Unbound crashes when confronted with a non-standard response from a server for a domain. This domain produces duplicate RRs from a certain type and is DNSSEC signed. Unbound also crashes when confronted with a query that eventually, and under specific circumstances, resolves to a domain that misses expected NSEC3 records.

Unbound 1.4.14 contains a patch, but 1.4.14rc1 is vulnerable. If you cannot upgrade you can also apply a patch. For unbound version 1.4.0 - 1.4.13, apply this patch and for version 1.0.1 - 1.3.4 use this patch. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.