CVE-2020-8617: ISC BIND DoS Vulnerability

CVE-2020-8617 Overview

CVE-2020-8617 is a Denial of Service vulnerability affecting ISC BIND, one of the most widely deployed DNS server software packages. Using a specially-crafted message, an attacker may potentially cause a BIND server to reach an inconsistent state if the attacker knows (or successfully guesses) the name of a TSIG key used by the server. Since BIND, by default, configures a local session key even on servers whose configuration does not otherwise make use of it, almost all current BIND servers are vulnerable.

In releases of BIND dating from March 2018 and after, an assertion check in tsig.c detects this inconsistent state and deliberately exits. Prior to the introduction of the check, the server would continue operating in an inconsistent state, with potentially harmful results.

Critical Impact

This vulnerability enables remote attackers to crash BIND DNS servers via specially-crafted TSIG messages, causing denial of service for all DNS-dependent services and potentially disrupting network infrastructure at scale.

Affected Products

• ISC BIND (multiple versions including 9.9.x, 9.10.x, 9.11.x, 9.12.x supported preview editions)
• Debian Linux 8.0, 9.0, 10.0
• Fedora 31, 32
• openSUSE Leap 15.1, 15.2
• Canonical Ubuntu Linux 12.04, 14.04 ESM, 16.04 ESM, 18.04 LTS, 19.10, 20.04 LTS

Discovery Timeline

• May 19, 2020 - CVE-2020-8617 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2020-8617

Vulnerability Analysis

This vulnerability targets the Transaction Signature (TSIG) authentication mechanism in BIND DNS servers. TSIG is a protocol extension that provides authentication for DNS messages using shared secret keys. The vulnerability exists because BIND's handling of specially-crafted TSIG messages can cause the server to enter an inconsistent internal state.

The critical aspect of this vulnerability is the default configuration behavior: BIND automatically configures a local session key even when TSIG is not explicitly configured by the administrator. This means that virtually all BIND installations are susceptible to this attack, regardless of whether they intentionally use TSIG for DNS authentication.

The attack requires the attacker to either know or successfully guess the name of a TSIG key used by the target server. Given that default key names are often predictable, this requirement does not significantly limit exploitability.

Root Cause

The root cause lies in improper state management within the tsig.c module when processing malformed TSIG messages. The assertion check that was introduced in March 2018 (CWE-617: Reachable Assertion) causes the BIND process to terminate when an inconsistent state is detected. While this is safer than continuing execution in a corrupted state, it still results in a denial of service condition.

Prior to this assertion check, the server would continue operating despite the inconsistent state, which could lead to unpredictable behavior and potentially more severe security implications.

Attack Vector

The attack is conducted over the network without requiring authentication or user interaction. An attacker sends a specially-crafted DNS message containing malicious TSIG data to a vulnerable BIND server. The attack flow proceeds as follows:

1. Attacker identifies a target BIND server
2. Attacker determines or guesses a valid TSIG key name (often predictable defaults)
3. Attacker crafts a malicious DNS message with manipulated TSIG authentication data
4. The malformed message triggers an inconsistent state in the TSIG processing logic
5. The assertion check in tsig.c fires, causing named to terminate
6. DNS resolution services become unavailable until the server is restarted

The attack complexity is considered high because the attacker must know or guess the TSIG key name, though default configurations often use predictable names.

Detection Methods for CVE-2020-8617

Indicators of Compromise

• Unexpected termination of the named process with assertion failure messages
• Log entries in /var/log/syslog or BIND logs indicating TSIG-related errors
• Core dump files generated by BIND containing assertion failure stack traces
• Repeated DNS service restarts or high-availability failover events

Detection Strategies

• Monitor BIND logs for assertion failure messages containing references to tsig.c
• Implement alerting on named process crashes or unexpected restarts
• Deploy network intrusion detection rules to identify malformed TSIG messages
• Track DNS query patterns for anomalous TSIG authentication attempts

Monitoring Recommendations

• Configure log aggregation for all BIND servers to centralize crash detection
• Set up process monitoring to detect named service interruptions
• Implement DNS availability monitoring with automated alerting
• Review BIND server logs regularly for TSIG-related warning messages

How to Mitigate CVE-2020-8617

Immediate Actions Required

• Update BIND to the latest patched version from ISC immediately
• Review and restrict network access to DNS servers where possible
• Ensure BIND server processes are configured with automatic restart policies
• Verify TSIG key names are not using predictable default values

Patch Information

ISC has released security patches addressing this vulnerability. Organizations should consult the ISC CVE-2020-8617 Documentation for specific version information and patch details. Major Linux distributions have also released updates:

• Debian: DSA-4689 Security Advisory
• Ubuntu: Security notices USN-4365-1 and USN-4365-2
• Fedora: Package updates available through standard repositories
• openSUSE: Security announcements with updated packages

Workarounds

• Implement firewall rules to restrict DNS access to trusted networks only
• Configure rate limiting on DNS queries to reduce attack impact
• Use non-default, complex TSIG key names to increase attack difficulty
• Deploy redundant DNS servers to maintain availability during attacks

# Example: Restrict DNS access to trusted networks via iptables
iptables -A INPUT -p udp --dport 53 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP