Because of a defect in handling queries for NSEC3-signed zones, BIND can crash with an "INSIST" failure in name.c when processing queries possessing certain properties. By exploiting this defect an attacker deliberately constructing a query with the right properties could achieve denial of service against an authoritative nameserver serving NSEC3-signed zones.
Please Note: Versions of BIND 9.7 are also affected, but this branch is beyond its "end of life" (EOL) and no longer receives testing or security fixes from ISC. For current information on which versions are actively supported, please see http://www.isc.org/downloads/software-support-policy/bind-software-status/.
Authoritative nameservers serving at least one NSEC3-signed zone are vulnerable to this defect. Recursive-only servers are not at risk. Authoritative servers which do not serve NSEC3-signed zones are not at risk.
Solution: Upgrade to the patched release most closely related to your current version of BIND. These can all be downloaded from http://www.isc.org/downloads.
BIND 9 version 9.6-ESV-R10-P2
BIND 9 version 9.8.6-P2
BIND 9 version 9.9.4-P2
9.9.4-P2 has just been added to the tree.
Arches, please test and stabilize:
Target arches: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Stable for HPPA.
The query_findclosestnsec3 function in query.c in named in ISC BIND 9.6,
9.7, and 9.8 before 9.8.6-P2 and 9.9 before 9.9.4-P2, and 9.6-ESV before
9.6-ESV-R10-P2, allows remote attackers to cause a denial of service (INSIST
assertion failure and daemon exit) via a crafted DNS query to an
authoritative nameserver that uses the NSEC3 signing feature.
*** Bug 499074 has been marked as a duplicate of this bug. ***
Maintainer(s), please cleanup.
Security, please vote.
I know s390 and sh aren't stables arches but I'll add them here anyway.
So guys, please take a look at bind-9.9.4_p2 as we'll drop bind-9.9.3_p2 soonish.
This bug's importance is marked "Normal minor". I don't understand why, hopefully someone can explain.
In my opinion the bug's priority should be more urgent. Our servers were attacked and did crash. The attacks seemed to occur at random and did not take longer than about
five minutes per attack, but as a result our DNS servers did crash quite often.
I don't know if squiddies attacked specifically us.
At first we worked around this by creating a wrapper that kept restarting BIND a second after a crash occur. But attacks increased so we decided to bump to bind-9.9.4_p2
via our private overlay.
But if the bump to p2 could occur via the Gentoo repo quickly, that would be great. Thanks.
We have a policy for setting bug's severity and priority (available at http://www.gentoo.org/security/en/vulnerability-policy.xml). A denial of service, even of high exploitability, is always of minor severity. In this case, the fixed version (9.9.4_p2) has already been committed and stabilized in CVS, so you should just be able to sync the Portage tree (emerge --sync) and emerge the newest version of bind. Thank you for your understanding!
Thanks for the link providing the policy, it's much appreciated.
Also I'm glad that the update has been committed, it sure is a nasty bug.
GLSA vote: yes.
(In reply to Chris Reffett from comment #18)
> GLSA vote: yes.
We already have a GLSA request from prior bug. This was added to it
This issue was resolved and addressed in
GLSA 201401-34 at http://security.gentoo.org/glsa/glsa-201401-34.xml
by GLSA coordinator Sean Amoss (ackle).
Re-open for cleanup.
Still need to clean up
+ 21 May 2014; Mikle Kolyada <email@example.com> -bind-9.9.3_p2.ebuild:
+ Drop insecure version