Fixing two new DNSSEC vulnerabilities
Today, we have been informed about two DNSSEC vulnerabilities in dnsmasq, which Pi-hole FTL is forked from. Both vulnerabilities, via specially crafted DNSSEC answers, can lead DNSSEC validators down a very CPU intensive and time costly validation/NSEC3 hash calculation path. This results in degraded performance and denial of service in trivially orchestrated attacks. In fact, the discovered vulnerability is not limited to Pi-hole but applies to most (if not all) DNSSEC validating DNS resolvers out there possibly sending the DNS server into nearly endlessly spinning loops.
Quoting Simon Kelley, the author of dnsmasq, the DNS resolver that is at the heart of Pi-hole:
The motivation for this a security announcement today of an attack known as KeyTrap, which is a generic attack on all DNSSEC validators – it’s a failure of the specification rather than of the implementations. If DNSSEC validation is enabled, then an attacker who can force a DNS server to validate a specially crafted signed domain can use a lot of CPU in the validator. This only affects dnsmasq installations with DNSSEC enabled.
The solution for dnsmasq is to impose hard limits on a few measures of the amount of “work” a DNSSEC validation is taking. The new code remembers how close to the limits it has come, and will log that information when it receives a SIGUSR1. The default limits have been set with significant headroom over the maximums that have been achieved in my testing, but the only testing has been done by me, because of embargo on the security disclosure. In the event that I’ve set the limits too small, there is a new option that allows them to be overridden. Hitting the limits logs an error message.
The security cases which refer to this are CVE-2023-50387 and CVE-2023-50868.
Both vulnerabilities are remote exploitable and rated “high” severity.
We have already released these fixes into our currently running beta of Pi-hole v6.0 to get some early testing and are well-prepared for a subsequent release of them into the current stable release as a new FTL v5.25.
Although this is not recommended, disabling DNSSEC validation entirely will remove the vulnerability. We instead strongly advise to upgrade to a fixed version, in which an exceptionally complex DNSSEC validation will no longer impede other server workload.
If you are still using the stable versions of Pi-hole (v5.x) but want to already be safe, we suggest you can either manually check out the development branch or disabling DNSSEC for the moment leaving DNSSEC validation to your upstream server. However, be aware of possible drawbacks and make sure that those are on a sufficiently recent version (e.g., unbound is fixed as of version 1.19.1).