REDHAT-BUG-2503075: High severity Nlnet Labs Unbound vulnerability
When 'dns-error-reporting: yes' is set, the EDNS Report-Channel option (code 18) from the last upstream response is read and uses the option's length as the length of the agent domain. When a domain name check is performed on the agent domain, the returned length is not used and if the agent domain is followed by garbage, those bytes are moved onto the tail of the synthetic 'er.' report query name. That query name is later used in the iterator via a subquery to send out the DNS Error Report and when Unbound tries to walk that query name during 'findclosestoftype()', it strips labels using the query name length rather than stopping at the embedded root, walks one byte past it, and feeds the first garbage byte to 'dnamequeryhash()' as a label length writing over the stack variable 'labuf'. One ordinary upstream response from a delegated zone the attacker controls is sufficient to terminate the daemon. Unbound 1.25.2 includes a fix to use the proper length of the agent domain name instead of the EDNS option length one.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Unboundto a version that resolves this vulnerability.Fixed in 1.25.2 - Configuration
If possible, disable DNS error reporting (dns-error-reporting: no) to avoid using EDNS Report-Channel (option code 18) length as the agent domain length that can lead to garbage being incorporated into the synthetic '_er.' report query name.
Unbound dns-error-reporting = yes/disabled
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments with 'dns-error-reporting: yes' configured are exposed. The issue is in Unbound's handling of EDNS Report-Channel option data from upstream responses.
What does an attacker need to exploit this issue?
An attacker needs control of a delegated DNS zone and only needs to provide one ordinary upstream response from that zone. This can cause the Unbound daemon to terminate.
What version fixes the issue?
Unbound 1.25.2 fixes the issue by using the proper agent-domain name length instead of the EDNS option length.