A logic error in code which checks TSIG validity can be used to trigger an assertion failure in tsig.c
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 1 on Exploit-DB, 1 Metasploit module, 2 proofs of concept on GitHub
Summary
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.
Timeline
- CVE published
- Public exploit on Exploit-DB
EDB-48521
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- ISC BIND9
Version range not reported