[ASA-202204-5] bind: multiple issues
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/fc9cb6cf91c1a36b797ffef0a277dbb3989d43dc
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/ae7fa0a3082d1b97b1123a96a78fbbe39d525be5
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/71dd44339f4cf616e514cefa1ac1794d7a14e7db
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/7ba3a069355875409fadd0da094293cd08d7ccb6
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
