BIND Security - CVE-2020-8616 and CVE-2020-8617

[ventz]

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.

[tcely]

They did. You are welcome to use my branch, if you like but I'm not wasting my time dealing with the inane nonsense there anymore.

tcely/aports@3048daa

I have built packages from this on edge on dockerhub.

docker pull tcely/alpine-aports:builder-bind

[ventz]

I am hitting the same point. I emailed Natanael a few days back btw as a heads up.

Are you planning on maintaining the package + alpine edge port going forward on your own? (I don’t mind doing the same for bind/contributing if you don’t have time.)

I am not sure what is going on with alpine (growing/ops pains under docker?), but I’ve noticed that security is not a priority. I really like the small and light footprint, but the package security really worries me. Considering going back to Ubuntu, which patches within 24-48 hrs, and is 78 MB at this point. While thats not 5-6 MB, the security tradeoff is starting to be worth it.

[tcely]

I'm currently using bind in docker for a few services I rely on so I'll update that as I get around to it. There are no promises though.

Had I gotten the cooperation I was hoping for, I would have moved master and edge to 9.16 by now. That's the next ESV according to ISC.

My biggest regret was that 3.x moved away from ESV too soon.

[elrido]

Quick question: I see that these are fixed in 9.14.12, which is now shipped by Alpine in 3.12. Would you be open to a pull request to get this version bump into the docker image?