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.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
