ArchLinux: 202204-5: bind: multiple issues | LinuxSecurity.com

Advisories

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

ArchLinux: 202204-5: bind: multiple issues

April 6, 2022
The package bind before version 9.18.1-1 is vulnerable to multiple issues including denial of service and content spoofing

Summary

- 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.

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.

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

Severity
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

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.

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.

Related News

© 2022 Guardian Digital, Inc All Rights Reserved

We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.