In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is injected into the response, the wildcard rrset will update the expired sibling record with a secure status before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC accompanying rrset.

In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is injected into the response, the wildcard rrset will update the expired sibling record with a secure status before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC accompanying rrset.

Affected: openEuler:22.03-LTS-SP4: unbound

Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. Unbound is available for most platforms such as FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows. Unbound is a totally free, open source software under the BSD license. It doesn't make custom builds or provide specific features to paying customers only. Security Fix(es):

With NLnet Labs Unbound up to and including version 1.25.1, applications using libunbound and configured with 'unwanted-reply-threshold', could eventually be abruptly terminated if the threshold is reached and libunbound needs to call 'libworker_alloc_cleanup' since the function is absent from the function call allow list. When an application using libunbound sets 'unwanted-reply-threshold' to any non-zero value and the iterator queries an authoritative that replies with enough wrong-transaction-ID UDP datagrams to cross the threshold, the 'libworker_alloc_cleanup' will eventually be called. Since the function is absent from the function call allow list, this leads to a fatal exit of libunbound and eventual termination of the embedding application.Unbound itself is not affected since its relevant function 'worker_alloc_cleanup' is registed in the allow list and proceeds to…

libunbound8-1.25.2-1.1 on GA media

unbound: Unbound: Denial of Service via assertion failure in DNS-over-QUIC environments unbound: Unbound: Denial of Service via improper validation of DNS-over-QUIC client length unbound: Unbound: Denial of Service via crafted DNSCrypt query unbound: Unbound: Denial of Service via terminated DNS-over-QUIC queries unbound: Unbound: DNS cache integrity issue unbound: Unbound: Denial of Service due to 'harden-below-nxdomain' logic bypass unbound: Unbound: Cache poisoning via insufficient RRSIG.Labels validation and premature cache writes unbound: Unbound: Information disclosure via DNSSEC wildcard replay unbound: Unbound: Denial of Service via DNSSEC query amplification bypass unbound: Unbound: Denial of Service due to freed pointer dereference in DNS-over-TLS handling unbound: Unbound: Insecure DNS redirection via spoofed DNS answers unbound: Unbound: DNS response policy replacement via hostname spoofing unbound: NLnet Labs Unbound: Denial of Service via crafted DNS glue records unbound: Unbound: DNS cache poisoning via UDP source port predictability unbound: Unbound: Denial of service due to memory corruption under specific configurations. unbound: Unbound: DNS Cookie security bypass via incorrect server cookie calculation unbound: Unbound: Information disclosure due to local policy bypass via unbound-control unbound: Unbound: Denial of Service via crafted DNS responses with expired records unbound: Unbound: Denial of Service via malformed EDNS Report-Channel option unbound:…

Security update for unbound

Affected: Ubuntu:Pro:14.04:LTS: unbound, Ubuntu:Pro:16.04:LTS: unbound, Ubuntu:Pro:18.04:LTS: unbound, Ubuntu:Pro:20.04:LTS: unbound, Ubuntu:22.04:LTS: unbound, Ubuntu:24.04:LTS: unbound, Ubuntu:26.04:LTS: unbound

In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is injected into the response, the wildcard rrset will update the expired sibling record with a secure status before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC accompanying rrset.

Ein Angreifer kann mehrere Schwachstellen in Unbound ausnutzen, um einen Denial of Service Angriff durchzuführen, um Informationen offenzulegen, um Daten zu manipulieren, und um Sicherheitsvorkehrungen zu umgehen.