bind9 bind 9.16.12 (security update)

[Douglas R. Reno]

New point versions

CVE rated 8.2/10:

CVE-2020-8625: A vulnerability in BIND's GSSAPI security policy negotiation can be targeted by a buffer overflow attack

CVE: CVE-2020-8625

Document version: 2.0

Posting date: 17 February 2021

Program impacted: BIND

Versions affected: BIND 9.5.0 -> 9.11.27, 9.12.0 -> 9.16.11, and versions BIND 9.11.3-S1 -> 9.11.27-S1 and 9.16.8-S1 -> 9.16.11-S1 of BIND Supported Preview Edition. Also release versions 9.17.0 -> 9.17.1 of the BIND 9.17 development branch

Severity: High

Exploitable: Remotely

Description:

GSS-TSIG is an extension to the TSIG protocol which is intended to support the secure exchange of keys for use in verifying the authenticity of communications between parties on a network.

SPNEGO is a negotiation mechanism used by GSSAPI, the application protocol interface for GSS-TSIG.

The SPNEGO implementation used by BIND has been found to be vulnerable to a buffer overflow attack.

Impact:

BIND servers are vulnerable if they are running an affected version and are configured to use GSS-TSIG features.

In a configuration which uses BIND's default settings the vulnerable code path is not exposed, but a server can be rendered vulnerable by explicitly setting valid values for the tkey-gssapi-keytab or tkey-gssapi-credentialconfiguration options.

Although the default configuration is not vulnerable, GSS-TSIG is frequently used in networks where BIND is integrated with Samba, as well as in mixed-server environments that combine BIND servers with Active Directory domain controllers.

The most likely outcome of a successful exploitation of the vulnerability is a crash of the named process. However, remote code execution, while unproven, is theoretically possible.

CVSS Score: 8.1

CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score, please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H&version=3.1.

Workarounds:

This vulnerability only affects servers configured to use GSS-TSIG, most often to sign dynamic updates. If another mechanism can be used to authenticate updates, the vulnerability can be avoided by choosing not to enable the use of GSS-TSIG features.

On some platforms it may be possible to build a working BIND installation that is not vulnerable to CVE-2020-8625 by providing the --disable-isc-spnego command-line argument when running the ./configure script in the top level of the BIND source directory, before compiling and linking named.

Choosing to configure and build BIND without the ISC SPNEGO implementation does not produce a vulnerable BIND on any platform, but on platforms where GSSAPI support in the system is lacking, building without the ISC SPNEGO implementation may result in unusable GSSAPI features (such as an inability to use GSS-TSIG-signed DDNS updates).

Active exploits:

We are not aware of any active exploits.

Solution:

Upgrade to the patched release most closely related to your current version of BIND:

    BIND 9.11.28
    BIND 9.16.12

BIND Supported Preview Edition is a special feature-preview branch of BIND provided to eligible ISC support customers.

    BIND 9.11.28-S1
    BIND 9.16.12-S1

[Douglas R. Reno]

Notes for BIND 9.16.12
Security Fixes

    When tkey-gssapi-keytab or tkey-gssapi-credential was configured, a specially crafted GSS-TSIG query could cause a buffer overflow in the ISC implementation of SPNEGO (a protocol enabling negotiation of the security mechanism to use for GSSAPI authentication). This flaw could be exploited to crash named. Theoretically, it also enabled remote code execution, but achieving the latter is very difficult in real-world conditions. (CVE-2020-8625)

    This vulnerability was responsibly reported to us as ZDI-CAN-12302 by Trend Micro Zero Day Initiative. [GL #2354]

New Features

    When a secondary server receives a large incremental zone transfer (IXFR), it can have a negative impact on query performance while the incremental changes are applied to the zone. To address this, named can now limit the size of IXFR responses it sends in response to zone transfer requests. If an IXFR response would be larger than an AXFR of the entire zone, it will send an AXFR response instead.

    This behavior is controlled by the max-ixfr-ratio option - a percentage value representing the ratio of IXFR size to the size of a full zone transfer. The default is 100%. [GL #1515]

    A new option, stale-answer-client-timeout, has been added to improve named’s behavior with respect to serving stale data. The option defines the amount of time named waits before attempting to answer the query with a stale RRset from cache. If a stale answer is found, named continues the ongoing fetches, attempting to refresh the RRset in cache until the resolver-query-timeout interval is reached.

    The default value is 1800 (in milliseconds) and the maximum value is limited to resolver-query-timeout minus one second. A value of 0 causes any available cached RRset to immediately be returned while still triggering a refresh of the data in cache.

    This new behavior can be disabled by setting stale-answer-client-timeout to off or disabled. The new option has no effect if stale-answer-enable is disabled. [GL #2247]

Feature Changes

    As part of an ongoing effort to use RFC 8499 terminology, primaries can now be used as a synonym for masters in named.conf. Similarly, notify primary-only can now be used as a synonym for notify master-only. The output of rndc zonestatus now uses primary and secondary terminology. [GL #1948]

    The default value of max-stale-ttl has been changed from 12 hours to 1 day and the default value of stale-answer-ttl has been changed from 1 second to 30 seconds, following RFC 8767 recommendations. [GL #2248]

    The SONAMEs for BIND 9 libraries now include the current BIND 9 version number, in an effort to tightly couple internal libraries with a specific release. This change makes the BIND 9 release process both simpler and more consistent while also unequivocally preventing BIND 9 binaries from silently loading wrong versions of shared libraries (or multiple versions of the same shared library) at startup. [GL #2387]

    When check-names is in effect, A records below an _spf, _spf_rate, or _spf_verify label (which are employed by the exists SPF mechanism defined in RFC 7208 section 5.7/appendix D.1) are no longer reported as warnings/errors. [GL #2377]

Bug Fixes

    named failed to start when its configuration included a zone with a non-builtin allow-update ACL attached. [GL #2413]

    Previously, dnssec-keyfromlabel crashed when operating on an ECDSA key. This has been fixed. [GL #2178]

    KASP incorrectly set signature validity to the value of the DNSKEY signature validity. This has been fixed. [GL #2383]

    When migrating to KASP, BIND 9 considered keys with the Inactive and/or Delete timing metadata to be possible active keys. This has been fixed. [GL #2406]

    Fix the “three is a crowd” key rollover bug in KASP. When keys rolled faster than the time required to finish the rollover procedure, the successor relation equation failed because it assumed only two keys were taking part in a rollover. This could lead to premature removal of predecessor keys. BIND 9 now implements a recursive successor relation, as described in the paper “Flexible and Robust Key Rollover” (Equation (2)). [GL #2375]

    Performance of the DNSSEC verification code (used by dnssec-signzone, dnssec-verify, and mirror zones) has been improved. [GL #2073]

[Douglas R. Reno]

Fixed at r24232