Arch Linux Security Advisory ASA-202204-5 ========================================= Severity: High Date : 2022-04-04 CVE-ID : CVE-2021-25220 CVE-2022-0396 CVE-2022-0635 CVE-2022-0667 Package : bind Type : multiple issues Remote : Yes Link : https://security.archlinux.org/AVG-2661 Summary ======= The package bind before version 9.18.1-1 is vulnerable to multiple issues including denial of service and content spoofing. Resolution ========== Upgrade to 9.18.1-1. # pacman -Syu "bind>=9.18.1-1" The problems have been fixed upstream in version 9.18.1. Workaround ========== - CVE-2021-25220 If applicable, modify your configuration to either remove all forwarding or all possibility of recursion. Depending on your use-case, it may be possible to use other zone types to replace forward zones. - CVE-2022-0396 use the default setting of keep-response-order { none; }. - CVE-2022-0635 The failure can be avoided by adding this option to named.conf: synth-from-dnssec no; However we do not recommend disabling this feature other than as a temporary workaround because it provides protection from pseudo-random- subdomain attacks against DNSSEC-signed zones. Description =========== - CVE-2021-25220 (content spoofing) When using forwarders in BIND, bogus NS records supplied by, or via, those forwarders may be cached and used by named if it needs to recurse for any reason, causing it to obtain and pass on potentially incorrect answers. The cache could become poisoned with incorrect records leading to queries being made to the wrong servers, which might also result in false information being returned to clients. Authoritative-only BIND 9 servers are not vulnerable to this flaw. - CVE-2022-0396 (denial of service) ISC recently discovered an issue in BIND that allows TCP connection slots to be consumed for an indefinite time frame via a specifically crafted TCP stream sent from a client. This issue is present in BIND 9.16.11 to 9.16.26 (including S editions), and 9.18.0. This issue can only be triggered on BIND servers which have keep- response-order enabled, which is not the default configuration. The keep-response-order option is an ACL block; any hosts which are specified within it will be able to trigger this issue on affected versions. Specifically crafted TCP streams can cause connections to BIND to remain in CLOSE_WAIT status for an indefinite period of time, even after the client has terminated the connection. - CVE-2022-0635 (denial of service) BIND 9.18.0 stable release refactored the RFC 8198 Aggressive Use of DNSSEC-Validated Cache feature (synth-from-dnssec) and changed the default so that is now automatically enabled for dnssec-validating resolvers. Subsequently it was found that repeated patterns of specific queries to servers with this feature enabled could cause an INSIST failure in query.c:query_dname which causes named to terminate unexpectedly. The vulnerability affects BIND resolvers running 9.18.0 that have both dnssec-validation and synth-from-dnssec enabled. (Note that dnssec- validation auto; is the default setting unless configured otherwise in named.conf and that enabling dnssec-validation automatically enables synth-from-dnssec unless explicitly disabled) When a vulnerable version of named receives a series of specific queries, the named process will eventually terminate due to a failed assertion check. - CVE-2022-0667 (denial of service) In BIND 9.18.0 the recursive client code was refactored that introduced a "backstop lifetime timer". While BIND is processing a request for a DS record that needs to be forwarded, it waits until this processing is complete or until the backstop lifetime timer has timed out. When the resume_dslookup() function is called as a result of such a timeout, the function does not test whether the fetch has previously been shut down. This introduces the possibility of triggering an assertion failure, which could cause the BIND process to terminate. Impact ====== A remote attacker is able to crash the application or force TCP connections to BIND to remain in CLOSE_WAIT status leading to denial of service on the affected host. Furthermore the cache could become poisoned leading to queries being made to the wrong servers, which might also result in false information being returned to clients. References ========== https://kb.isc.org/docs/cve-2021-25220 https://gitlab.isc.org/isc-projects/bind9/-/commit/fc9cb6cf91c1a36b797ffef0a... https://kb.isc.org/docs/cve-2022-0396 https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5987 https://gitlab.isc.org/isc-projects/bind9/-/commit/ae7fa0a3082d1b97b1123a96a... https://kb.isc.org/docs/cve-2022-0635 https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5988 https://gitlab.isc.org/isc-projects/bind9/-/commit/71dd44339f4cf616e514cefa1... https://kb.isc.org/docs/cve-2022-0667 https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5989 https://gitlab.isc.org/isc-projects/bind9/-/commit/7ba3a069355875409fadd0da0... https://security.archlinux.org/CVE-2021-25220 https://security.archlinux.org/CVE-2022-0396 https://security.archlinux.org/CVE-2022-0635 https://security.archlinux.org/CVE-2022-0667