A malformed query response received by a recursive server in response to a query of RTYPE ANY could trigger an assertion failure while named is attempting to add the RRs in the query response to the cache. While the combination of properties which triggers the assertion should not occur in normal traffic, it is potentially possible for the assertion to be triggered deliberately by an attacker sending a specially-constructed answer having the required properties, after having engineered a scenario whereby an ANY query is sent to the recursive server for the target QNAME. A recursive server will itself only send a query of type ANY if it receives a client query of type ANY for a QNAME for which it has no RRsets at all in cache, otherwise it will respond to the client with the the RRsets that it has available.

This vulnerability occurs during the processing of an answer packet received in response to a query. As a result, recursive servers are at the greatest risk; authoritative servers are at risk only to the extent that they perform a limited set of queries.

This description is borrowed from the upstream advisory.

An unusually-formed answer containing a DS resource record could trigger an assertion failure. While the combination of properties which triggers the assertion should not occur in normal traffic, it is potentially possible for the assertion to be triggered deliberately by an attacker sending a specially-constructed answer having the required properties.

This vulnerability occurs during the processing of an answer packet received in response to a query. As a result, recursive servers are at the greatest risk; authoritative servers are at risk only to the extent that they perform a limited set of queries.

This description is borrowed from the upstream advisory.

A query with a specific set of characteristics could cause a server using DNS64 to encounter an assertion failure and terminate. An attacker could deliberately construct a query, enabling denial-of-service against a server if it was configured to use the DNS64 feature and other preconditions were met.

Servers are at risk if they are configured to use DNS64 and if the option "break-dnssec yes;" is in use.

External References:

https://kb.isc.org/article/AA-01465

Mitigation:

Servers which have configurations which require DNS64 and "break-dnssec yes;" should upgrade. Servers which are not using these features in conjunction are not at risk from this defect.

BIND was improperly sequencing cleanup operations on upstream recursion fetch contexts, leading in some cases to a use-after-free error that can trigger an assertion failure and crash in named. Affects BIND 9.0.0 to 9.8.x, 9.9.0 to 9.9.11, 9.10.0 to 9.10.6, 9.11.0 to 9.11.2, 9.9.3-S1 to 9.9.11-S1, 9.10.5-S1 to 9.10.6-S1, 9.12.0a1 to 9.12.0rc1.

The BIND installer on Windows uses an unquoted service path which can enable a local user to achieve privilege escalation if the host file system permissions allow this. Affects BIND 9.2.6-P2->9.2.9, 9.3.2-P1->9.3.6, 9.4.0->9.8.8, 9.9.0->9.9.10, 9.10.0->9.10.5, 9.11.0->9.11.1, 9.9.3-S1->9.9.10-S1, 9.10.5-S1.

An attacker who is able to send and receive messages to an authoritative DNS server and who has knowledge of a valid TSIG key name for the zone and service being targeted may be able to manipulate BIND into accepting an unauthorized dynamic update. A server that relies solely on TSIG or SIG(0) keys with no other address-based ACL protection could be vulnerable to malicious zone content manipulation using this technique.

Workarounds:

The effects of this vulnerability can be mitigated by using Access Control Lists (ACLs) that require both address range validation and use of TSIG authentication in parallel. For information on how to configure this type of compound authentication control, please see:

https://kb.isc.org/article/AA-00723/0/Using-Access-Control-Lists-ACLs-with-both-addresses-and-keys.html.

Administrators who have made use of named.conf option "update-policy local;" should refer to the Administrator Reference Manual (ARM) for details of the automatic update policy that will be established and to assess whether or not this conveys any additional risk to their server. (Note that this option is not enabled by default).

Upstream patch:

https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=581c1526ab

The GeoIP functionality in ISC BIND 9.10.0 through 9.10.1 allows remote attackers to cause a denial of service (assertion failure and named exit) via vectors related to (1) the lack of GeoIP databases for both IPv4 and IPv6, or (2) IPv6 support with certain options.

ISC BIND 9.0.x through 9.8.x, 9.9.0 through 9.9.6, and 9.10.0 through 9.10.1 does not limit delegation chaining, which allows remote attackers to cause a denial of service (memory consumption and named crash) via a large or infinite number of referrals.

Race condition in resolver.c in named in ISC BIND 9.9.8 before 9.9.8-P2 and 9.10.3 before 9.10.3-P2 allows remote attackers to cause a denial of service (INSIST assertion failure and daemon exit) via unspecified vectors.

db.c in named in ISC BIND 9.x before 9.9.8-P2 and 9.10.x before 9.10.3-P2 allows remote attackers to cause a denial of service (REQUIRE assertion failure and daemon exit) via a malformed class attribute.

name.c in named in ISC BIND 9.7.x through 9.9.x before 9.9.7-P1 and 9.10.x before 9.10.2-P2, when configured as a recursive resolver with DNSSEC validation, allows remote attackers to cause a denial of service (REQUIRE assertion failure and daemon exit) by constructing crafted zone data and then making a query for a name in that zone.

It was reported that a problem with trust anchor management can cause named to crash, affecting BIND versions 9.7.0+.

ISC developers believe that it will be very difficult for this to be triggered in most cases, requiring DNSSEC validation amongst other factors.

ISC will not be producing patches specifically for BIND 9.8 or BIND 9.6-ESV, both of which are beyond their End of Life (EOL) and are no longer supported by ISC.

Patches that correct this issue for ISC BIND 9.10.1 and ISC BIND 9.9.6 are attached to this Bugzilla.

A defect in BIND's handling of responses containing a DNAME answer can cause a resolver to exit after encountering an assertion failure in db.c or resolver.c

During processing of a recursive response that contains a DNAME record in the answer section, BIND can stop execution after encountering an assertion error in resolver.c (error message: "INSIST((valoptions & 0x0002U) != 0) failed") or db.c (error message: "REQUIRE(targetp != ((void )0) && targetp == ((void )0)) failed").

A server encountering either of these error conditions will stop, resulting in denial of service to clients. The risk to authoritative servers is minimal; recursive servers are chiefly at risk.

ISC BIND through 9.9.9-P1, 9.10.x through 9.10.4-P1, and 9.11.x through 9.11.0b1 allows primary DNS servers to cause a denial of service (secondary DNS server crash) via a large AXFR response, and possibly allows IXFR servers to cause a denial of service (IXFR client crash) via a large IXFR response and allows remote authenticated users to cause a denial of service (primary DNS server crash) via a large UPDATE message.

ISC BIND 9.x before 9.9.9-P2, 9.10.x before 9.10.4-P2, and 9.11.x before 9.11.0b2, when lwresd or the named lwres option is enabled, allows remote attackers to cause a denial of service (daemon crash) via a long request that uses the lightweight resolver protocol.

buffer.c in named in ISC BIND 9 before 9.9.9-P3, 9.10.x before 9.10.4-P3, and 9.11.x before 9.11.0rc3 does not properly construct responses, which allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a crafted query.

resolver.c in named in ISC BIND 9.10.x before 9.10.3-P4, when DNS cookies are enabled, allows remote attackers to cause a denial of service (INSIST assertion failure and daemon exit) via a malformed packet with more than one cookie option.