See title, this brings development-v6 to the just released dnsmasq v2.90 including a fix against a potential DoS vulnerability when DNSSEC is enabled.
CHANGELOG
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 the is a security vulnerablity only when DNSSEC validation is enabled.
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 interfaces 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 usptream 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.
Related issue or feature (if applicable): N/A
Pull request in docs with documentation (if applicable): N/A
By submitting this pull request, I confirm the following:
I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
I have commented my proposed changes within the code.
I am willing to help maintain this change if there are issues with it later.
I set this PR back into draft mode as we are awaiting the release of the final v2.90 sometime next week. I'll prepare a backport to v5.x in a separate PR.
What does this implement/fix?
See title, this brings
development-v6
to the just releaseddnsmasq v2.90
including a fix against a potential DoS vulnerability when DNSSEC is enabled.CHANGELOG
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 the is a security vulnerablity only when DNSSEC validation is enabled.
--rev-server
introduced in 2.88 which caused breakage if the prefix length is not exactly divisible by 8 (IPv4) or 4 (IPv6).--edns-packet-max
for special circumstances.--no-dhcpv4-interface
and--no-dhcpv6-interface
for better control over which interfaces are providing DHCP service.--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.Related issue or feature (if applicable): N/A
Pull request in docs with documentation (if applicable): N/A
By submitting this pull request, I confirm the following:
git rebase
)Checklist:
developmental
branch.