CVE-2020-8617: FAQ and Supplemental Information

  • Updated on May 21, 2020
  • Published on May 19, 2020
  • 3 minute(s) read
  • Cathy Almond
 Prev Next

This page provides supplemental information for the CVE-2020-8617 Security Advisory (https://kb.isc.org/v1/docs/cve-2020-8617).

For up-to-date information on this vulnerability, patches, and other operational information, please see the official vulnerability announcement. This article is intended to supplement the information in that announcement and will be updated as needed to further describe the operational impact of this vulnerability.

Both authoritative and recursive BIND servers are affected by this security issue. The vulnerability is present for any server with a TSIG key in its configuration

Your BIND9 server is very likely to be running with a TSIG key loaded

All ISC-distributed versions of BIND9, at the time this Advisory was released, have at least one TSIG key automatically loaded in their configuration.

As at the time of writing this FAQ, there are two ways in which your server will have one or more TSIG keys loaded.

  1. You have any key {}; stanza in your configuration (that is, you have directly configured a shared key in named.conf or one of its include files)
  2. The automatically-generated session key which is used for dynamic updates when using update-policy local;

Potentially yes - it is the key name, not it's value that a potential attacker needs to know. Are all your key names hard to guess? Could your TSIG key names be learned by snooping network traffic?

Unfortunately yes - this key is generated when named starts up (we are going to address this unnecessary key load in a future release of BIND)

Yes. Use of ACLs to restrict access at the same time as using TSIG does not provide any protection for a BIND server; this defect is encountered before ACLs are examined. Therefore it is the presence of TSIG keys alone that exposes a server to this vulnerability. It does not matter what they are used for, and whether or not the attacker is permitted to use them on the target server.

You need to either:

  • Upgrade to a version of BIND that includes the fix for CVE-2020-8617.
  • Apply a patch for this problem to an older version of BIND

Your server is vulnerable if:

  • An attacker is able to send a packet that will reach your BIND server.
  • An attacker knows the name of a TSIG key on your server. (The key value is not needed to exploit this vulnerability)

A server whose clients are known and trusted, and which is protected from unknown clients and spoofed client traffic by effective firewalls is less likely to be affected by this problem, although a compromised trusted client is still a risk.

Making your TSIG keys more difficult to guess may also offer some temporary protection. In particular, you can rename the automatically-generated session key by using the session-keyname option in named.conf.

Yes or no - the answer depends on your configuration. Authentication of control commands (rndc). 'rndc' does not use TSIG, but the name of any shared secret key that has been added to named.conf to be referenced by the 'controls' statement can be used to exploit the vulnerability because it is stored in BIND configuration in the same key format as TSIG keys. Both resolvers and authoritative servers use control commands (rndc).

No. BIND server administrators have the option to automatically generate a local-only rndc key for use over the local loopback addresses (IPv4 and IPv6) using command rndc-confgen -a. This key will be placed in a local copy of the file rndc.conf with key name rndc-key. If this key is automatically loaded by BIND, but never specified in named.conf in a key statement, then it cannot be used to cause named to terminate. This is because it is loaded in a different structure and is unavailable to TSIG processing.