BIND Security - CVE-2020-8616 and CVE-2020-8617 #35
Description
Reporting two vulnerabilities - both are High severity and exploitable Remotely
CVE-2020-8616: BIND does not sufficiently limit the number of fetches performed when processing referrals
In order for a server performing recursion to locate records in the DNS graph it must be capable of processing referrals, such as those received when it attempts to query an authoritative server for a record which is delegated elsewhere. In its original design BIND (as well as other nameservers) does not sufficiently limit the number of fetches which may be performed while processing a referral response.
A malicious actor who intentionally exploits this lack of effective limitation on the number of fetches performed when processing referrals can, through the use of specially crafted referrals, cause a recursing server to issue a very large number of fetches in an attempt to process the referral.
This has at least two potential effects:
- The performance of the recursing server can potentially be degraded by the additional work required to perform these fetches, and
- The attacker can exploit this behavior to use the recursing server as a reflector in a reflection attack with a high amplification factor.
and
CVE-2020-8617: A logic error in code which checks TSIG validity can be used to trigger an assertion failure in tsig.c
An error in BIND code which checks the validity of messages containing TSIG resource records can be exploited by an attacker to trigger an assertion failure in tsig.c, resulting in denial of service to clients.
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.
@tcely ping. I think the alpine project moved to Gitlab a while back.