A second vulnerability in BIND's GSSAPI security policy negotiation can be targeted by a buffer overflow attack
ISC · BIND9
In BIND 9.5.0 -> 9.11.29, 9.12.0 -> 9.16.13, and versions BIND 9.11.3-S1 -> 9.11.29-S1 and 9.16.8-S1 -> 9.16.13-S1 of BIND Supported Preview Edition, as well as release versions 9.17.0 -> 9.17.1 of the BIND 9.17 development branch, 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 values for the tkey-gssapi-keytab or tkey-gssapi-credential configuration 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. For servers that meet these conditions, the ISC SPNEGO implementation is vulnerable to various attacks, depending on the CPU architecture for which BIND was built: For named binaries compiled for 64-bit platforms, this flaw can be used to trigger a buffer over-read, leading to a server crash. For named binaries compiled for 32-bit platforms, this flaw can be used to trigger a server crash due to a buffer overflow and possibly also to achieve remote code execution. We have determined that standard SPNEGO implementations are available in the MIT and Heimdal Kerberos libraries, which support a broad range of operating systems, rendering the ISC implementation unnecessary and obsolete. Therefore, to reduce the attack surface for BIND users, we will be removing the ISC SPNEGO implementation in the April releases of BIND 9.11 and 9.16 (it had already been dropped from BIND 9.17). We would not normally remove something from a stable ESV (Extended Support Version) of BIND, but since system libraries can replace the ISC SPNEGO implementation, we have made an exception in this case for reasons of stability and security.
- Exploited
- Not confirmed
- Reports
- 0
- Tactics
- 0/15
Exploitation timelineDated milestones for a CVE: when it was disclosed, when exploit code became public, when exploitation was confirmed, and when threat reports named it.
Disclosed on 29 Apr 2021. No public exploit code or confirmed exploitation is recorded.
MITRE ATT&CKA public catalogue of the techniques attackers use, maintained by MITRE. Patchfirst uses it to describe what attackers do with a vulnerability. techniques
No techniques linkedNo ATT&CK techniques are linked to this CVE yet. MITRE CTID has not mapped it, and no report passage in the corpus ties it to a technique.
What security researchers reported
Not named in any threat report yetAlso mentioned in 1 community threat pulse (AlienVault OTX)
Weaker evidencePulses are indicator collections that anyone can publish. A mention is not confirmation of exploitation.