** This release is signed by yorgos@nlnetlabs.nl. Please find the relevant key at https://nlnetlabs.nl/people/ **
This security release fixes CVE-2024-8508.
A vulnerability has been discovered in Unbound when handling replies
with very large RRsets that Unbound needs to perform name compression
for.
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.
We would like to thank Toshifumi Sakaguchi for discovering and
responsibly disclosing the vulnerability.
Bug Fixes:
- Fix CVE-2024-8508, unbounded name compression could lead to denial of
service.
This release was exceptional because Wouter is unavailable at this time.
In the future we are thinking of having a dedicated key for signing releases, but this is something that will be properly communicated when time comes.
I may do more releases in the future with the Yorgos key, if you want to store that.
It would be nice, if there were a list of PGP keys, which are considered okay for unbound signatures. In Fedora we try to verify package signatures as part of package build process [1]. But it expects all keys considered okay to sign in code to be in single file. Ideally somewhere at your web servers to download and protected by HTTPS.
I have failed to find such file anywhere on nlnetlabs download close to release. keys [2] at downloads lists some keys, but not something like who is relevant in which project, where code signinig might occur.
By the way, have you considered publishing keys also as an OPENPGP record? As an organization closely related to DNS and with a signed zone, it might be useful. gnupg has some support for it as --auto-key-locate dane. Published as experimental RFC 7929 [3].
It would be nice, if there were a list of PGP keys, which are considered okay for unbound signatures. In Fedora we try to verify package signatures as part of package build process [1]. But it expects all keys considered okay to sign in code to be in single file. Ideally somewhere at your web servers to download and protected by HTTPS.
I have failed to find such file anywhere on nlnetlabs download close to release. keys [2] at downloads lists some keys, but not something like who is relevant in which project, where code signinig might occur.
With the upcoming plans to have a dedicated key for signing released code, the key will have a more prominent appearance on the website, same way as the security key has now.
By the way, have you considered publishing keys also as an OPENPGP record? As an organization closely related to DNS and with a signed zone, it might be useful. gnupg has some support for it as --auto-key- locate dane. Published as experimental RFC 7929 [3].
Good suggestion. Not sure about the discover-ability of those since it is experimental and mainly for email but another thing to consider.
I'll bring it up with the team when the time comes.