[Dnsmasq-discuss] Announce: dnsmasq-2.90.

[Simon Kelley]

I've just released 2.90.

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.

I'm aware both that a release is well overdue, and that there are 
outstanding patches and issues which I'd hoped to get to before making a 
release and thus far failed to do so. The security issue has forced my 
hand, so we do at least now have a release. I'll continue working in the 
backlog.

The security fixes are conceptually complex, but they ended up touching 
a lot of code, so backporting them is going to be difficult. I'd 
encourage anyone who can to upgrade rather than backporting.

CHANGELOG below, for reference.

Cheers,

Simon.




version 2.90
         Fix reversion in --rev-server introduced in 2.88 which
         caused breakage if the prefix length is not exactly divisible
         by 8 (IPv4) or 4 (IPv6).

         Fix possible SEGV when there server(s) for a particular
         domain are configured, but no server which is not qualified
         for a particular domain. Thanks to Daniel Danzberger for
         spotting this bug.

         Set the default maximum DNS UDP packet sice to 1232. This
         has been the recommended value since 2020 because it's the
         largest value that avoid fragmentation, and fragmentation
         is just not reliable on the modern internet, especially
         for IPv6. It's still possible to override this with
         --edns-packet-max for special circumstances.

         Add --no-dhcpv4-interface and --no-dhcpv6-interface for
         better control over which inetrfaces are providing DHCP service.

         Fix issue with stale caching: After replying with stale data,
         dnsmasq sends the query upstream to refresh the cache
	asynchronously and sometimes sends the wrong packet: packet
	length can be wrong,
	and if an EDE marking stale data is added to the answer that can
        	end up in the query also. This bug only seems to cause problems
         when the upstream server is a DOH/DOT proxy. Thanks to Justin He
         for the bug report.

         Add configurable caching for arbitrary RR-types.

         Add --filter-rr option, to filter arbitrary RR-types.
         --filter-rr=ANY has a special meaning: it filters the
         answers to queries for the ANY RR-type.

         Add limits on the resources used to do DNSSEC validation.
         DNSSEC introduces a potential CPU DoS, because a crafted domain
         can force a validator to a large number of cryptographic
         operations whilst attempting to do validation. When using TCP
	transport a DNSKEY RRset contain thousands of members and any
         RRset can have thousands of signatures. The potential number
         of signature validations to follow the RFC for validation
         for one RRset is the cross product of the keys and signatures,
         so millions. In practice, the actual numbers are much lower,
         so attacks can be mitigated by limiting the amount of
         cryptographic "work" to a much lower amount. The actual
         limits are number a signature validation fails per RRset(20),
         number of signature validations and hash computations
        	per query(200), number of sub-queries  to fetch  DS and DNSKEY
         RRsets per query(40), and the number of iterations in a
         NSEC3 record(150). These values are sensible, but there is, as 	
	yet, no standardisation on the values for a "conforming" domain,
	so a new option --dnssec-limit is provided should they need to 	
	be altered. The algorithm to validate DS records has also been
	altered to reduce the maximum work from cross product of the
	number of DS records and number of DNSKEYs to the cross product
	of the number of DS records and supported DS digest types. As
	the number of DS digest types is in single figures, this reduces
	the exposure.

         Credit is due to Elias Heftrig, Haya Schulmann, Niklas Vogel,
         and Michael Waidner from the German National Research Center for
         Applied Cybersecurity ATHENE for finding this vulnerability.

         CVE 2023-50387 and CVE 2023-50868 apply.
         Note that this is a security vulnerablity only when DNSSEC
	validationis enabled.