CVE-2020-8617: FAQ and Supplemental Information

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

How can I identify the TSIG keys in my server's 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;

My shared-secret key values are very random and would be hard to guess - am I vulnerable?

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?

I'm not using update-policy local; for any of my zones, do I still have the automatically-generated session key?

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)

I don't allow dynamic updates to any of my zones - is my server vulnerable?

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.

How can I fully protect my server against an attacker using the automatically-generated TSIG session key?

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

What can I do to protect my server until I'm able to run a version of BIND that is not vulnerable?

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.

Can the shared key used by the rndc control utility expose my server to this vulnerability?

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

I'm using the rndc control utility, but only locally from the server itself and I don't have the key directly defined in named.conf; does the local rndc key expose my server to this vulnerability?

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.