| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The query_findclosestnsec3 function in query.c in named in ISC BIND 9.6, 9.7, and 9.8 before 9.8.6-P2 and 9.9 before 9.9.4-P2, and 9.6-ESV before 9.6-ESV-R10-P2, allows remote attackers to cause a denial of service (INSIST assertion failure and daemon exit) via a crafted DNS query to an authoritative nameserver that uses the NSEC3 signing feature. |
| Unspecified vulnerability in ISC BIND 9 9.6.x before 9.6-ESV-R4-P3, 9.7.x before 9.7.3-P3, and 9.8.x before 9.8.0-P4 allows remote attackers to cause a denial of service (named daemon crash) via a crafted UPDATE request. |
| The server in ISC DHCP 3.x and 4.x before 4.2.2, 3.1-ESV before 3.1-ESV-R3, and 4.1-ESV before 4.1-ESV-R3 allows remote attackers to cause a denial of service (daemon exit) via a crafted BOOTP packet. |
| ISC BIND 9.8.x before 9.8.0-P1, when Response Policy Zones (RPZ) RRset replacement is enabled, allows remote attackers to cause a denial of service (assertion failure and daemon exit) via an RRSIG query. |
| ISC DHCP server 4.0 before 4.0.2, 4.1 before 4.1.2, and 4.2 before 4.2.0-P1 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a DHCPv6 packet containing a Relay-Forward message without an address in the Relay-Forward link-address field. |
| ISC DHCP 4.1 before 4.1.1-P1 and 4.0 before 4.0.2-P1 allows remote attackers to cause a denial of service (server exit) via a zero-length client ID. |
| ISC DHCP 4.1.2 through 4.2.4 and 4.1-ESV before 4.1-ESV-R6 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a malformed client identifier. |
| BIND 9.7.1 and 9.7.1-P1, when a recursive validating server has a trust anchor that is configured statically or via DNSSEC Lookaside Validation (DLV), allows remote attackers to cause a denial of service (infinite loop) via a query for an RRSIG record whose answer is not in the cache, which causes BIND to repeatedly send RRSIG queries to the authoritative servers. |
| The DHCPv6 server in ISC DHCP 4.0.x and 4.1.x before 4.1.2-P1, 4.0-ESV and 4.1-ESV before 4.1-ESV-R1, and 4.2.x before 4.2.1b1 allows remote attackers to cause a denial of service (assertion failure and daemon crash) by sending a message over IPv6 for a declined and abandoned address. |
| ISC BIND 9.8.x before 9.8.4-P1 and 9.9.x before 9.9.2-P1, when DNS64 is enabled, allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a crafted query. |
| ISC DHCP 4.1.x before 4.1-ESV-R7 and 4.2.x before 4.2.4-P2 allows remote attackers to cause a denial of service (daemon crash) in opportunistic circumstances by establishing an IPv6 lease in an environment where the lease expiration time is later reduced. |
| Multiple memory leaks in ISC DHCP 4.1.x and 4.2.x before 4.2.4-P1 and 4.1-ESV before 4.1-ESV-R6 allow remote attackers to cause a denial of service (memory consumption) by sending many requests. |
| query.c in ISC BIND 9.0.x through 9.6.x, 9.4-ESV through 9.4-ESV-R5, 9.6-ESV through 9.6-ESV-R5, 9.7.0 through 9.7.4, 9.8.0 through 9.8.1, and 9.9.0a1 through 9.9.0b1 allows remote attackers to cause a denial of service (assertion failure and named exit) via unknown vectors related to recursive DNS queries, error logging, and the caching of an invalid record by the resolver. |
| The Winsock WSAIoctl API in Microsoft Windows Server 2008, as used in ISC BIND 9.6-ESV before 9.6-ESV-R10-P1, 9.8 before 9.8.6-P1, 9.9 before 9.9.4-P1, 9.9.3-S1, 9.9.4-S1, and other products, does not properly support the SIO_GET_INTERFACE_LIST command for netmask 255.255.255.255, which allows remote attackers to bypass intended IP address restrictions by leveraging misinterpretation of this netmask as a 0.0.0.0 netmask. |
| BIND 9 resolver can crash when stale cache and stale answers are enabled, option `stale-answer-client-timeout` is set to a positive integer, and the resolver receives an RRSIG query.
This issue affects BIND 9 versions 9.16.12 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.12-S1 through 9.16.36-S1. |
| Processing of repeated responses to the same query, where both responses contain ECS pseudo-options, but where the first is broken in some way, can cause BIND to exit with an assertion failure.
'Broken' in this context is anything that would cause the resolver to reject the query response, such as a mismatch between query and answer name.
This issue affects BIND 9 versions 9.11.4-S1 through 9.11.37-S1 and 9.16.8-S1 through 9.16.36-S1. |
| Sending a flood of dynamic DNS updates may cause `named` to allocate large amounts of memory. This, in turn, may cause `named` to exit due to a lack of free memory. We are not aware of any cases where this has been exploited.
Memory is allocated prior to the checking of access permissions (ACLs) and is retained during the processing of a dynamic update from a client whose access credentials are accepted. Memory allocated to clients that are not permitted to send updates is released immediately upon rejection. The scope of this vulnerability is limited therefore to trusted clients who are permitted to make dynamic zone changes.
If a dynamic update is REFUSED, memory will be released again very quickly. Therefore it is only likely to be possible to degrade or stop `named` by sending a flood of unaccepted dynamic updates comparable in magnitude to a query flood intended to achieve the same detrimental outcome.
BIND 9.11 and earlier branches are also affected, but through exhaustion of internal resources rather than memory constraints. This may reduce performance but should not be a significant problem for most servers. Therefore we don't intend to address this for BIND versions prior to BIND 9.16.
This issue affects BIND 9 versions 9.16.0 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.8-S1 through 9.16.36-S1. |
| This issue can affect BIND 9 resolvers with `stale-answer-enable yes;` that also make use of the option `stale-answer-client-timeout`, configured with a value greater than zero.
If the resolver receives many queries that require recursion, there will be a corresponding increase in the number of clients that are waiting for recursion to complete. If there are sufficient clients already waiting when a new client query is received so that it is necessary to SERVFAIL the longest waiting client (see BIND 9 ARM `recursive-clients` limit and soft quota), then it is possible for a race to occur between providing a stale answer to this older client and sending an early timeout SERVFAIL, which may cause an assertion failure.
This issue affects BIND 9 versions 9.16.12 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.12-S1 through 9.16.36-S1. |
| A bad interaction between DNS64 and serve-stale may cause `named` to crash with an assertion failure during recursive resolution, when both of these features are enabled.
This issue affects BIND 9 versions 9.16.12 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.16.12-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1. |
| The TLS certificate validation code is flawed. An attacker can obtain a TLS certificate from the Stork server and use it to connect to the Stork agent. Once this connection is established with the valid certificate, the attacker can send malicious commands to a monitored service (Kea or BIND 9), possibly resulting in confidential data loss and/or denial of service. It should be noted that this vulnerability is not related to BIND 9 or Kea directly, and only customers using the Stork management tool are potentially affected.
This issue affects Stork versions 0.15.0 through 1.15.0. |
