It was reported that a defect in how BIND handled queries for NSEC3-signed zones could cause a crash of the named daemon with an "INSIST" failure when processing queries that possessed certain properties. A remote attacker could exploit this defect by constructing a carefully-crafted query against an authoritative nameserver that served NSEC3-signed zones. Note that this flaw affects BIND versions 9.6.0 and higher (NSEC3 was introduced in BIND 9.6.0 but is not automatically enabled). Authoritative nameservers that are serving at least one NSEC3-signed zone are vulnerable. Authoritative nameservers that are NOT serving at least one NSEC3-signed zone are not vulnerable, nor are recursive-only servers. Servers running versions of BIND older than 9.6.0 are also not vulnerable. There are no workarounds for this issue.
Created attachment 848662 [details] bind 9.8.6 patch This is a diff of 9.8.6-P1 vs 9.8.6-P2 which includes the fix. It also includes one unrelated fix as well: 3693. [security] memcpy was incorrectly called with overlapping ranges resulting in malformed names being generated on some platforms. This could cause INSIST failures when serving NSEC3 signed zones. [RT #35120] 3658. [port] linux: Address platform specific compilation issue when libcap-devel is installed. [RT #34838]
Created attachment 848664 [details] bind 9.9.4 patch This is a diff of 9.9.4-P1 vs 9.9.4-P2 which includes the fix. It also includes one unrelated fix as well: 3693. [security] memcpy was incorrectly called with overlapping ranges resulting in malformed names being generated on some platforms. This could cause INSIST failures when serving NSEC3 signed zones. [RT #35120] 3658. [port] linux: Address platform specific compilation issue when libcap-devel is installed. [RT #34838]
The second reference below has a FAQ, one of which is the question of what caused the flaw. The answer is: "The bug (which causes an INSIST crash in name.c) is caused by a misuse of the standard memcpy() function which is, by happenstance, safe on most platforms: in this case a memory buffer was being copied to an overlapping buffer. The bug went undetected until recently because most implementations of memcpy() do handle this situation safely, but the standard does not require them to do so. Recent optimizations to glibc have removed the safetly net, exposing a long-existing but previously harmless coding error in named." This is related to newer implementations of glibc's memcpy() function. External References: https://kb.isc.org/article/AA-01078/0 https://kb.isc.org/article/AA-01085
Created bind tracking bugs for this issue: Affects: fedora-all [bug 1052708]
bind-9.9.3-14.P2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
bind-9.9.4-11.P2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2014:0043 https://rhn.redhat.com/errata/RHSA-2014-0043.html
As discussed in comment #10, this flaws would affect bind only if used with glibc versions which have newer implementation of the memcpy() function. Therefore it does not directly affect the version of bind97 shipped in Red Hat Enterprise Linux 5. Nevertheless, to protect against this flaw appearing in future builds of bind97 (possibly done with different compiler or C library optimization), Red Hat Security Response Team has decided to address this issue. There is no plan for an immediate update correcting this issue, it will be corrected with future bind97 packages updates.
Statement: This issue does not affect the version of bind and bind97 as shipped with Red Hat Enterprise Linux 5. For a technical explanation please see https://bugzilla.redhat.com/show_bug.cgi?id=1051717#c25
Note: The following references pertain to "memcpy() optimizations" mentioned in the previous comments on this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12518 http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278 https://bugzilla.redhat.com/show_bug.cgi?id=638477
IssueDescription: A denial of service flaw was found in the way BIND handled queries for NSEC3-signed zones. A remote attacker could use this flaw against an authoritative name server that served NCES3-signed zones by sending a specially crafted query, which, when processed, would cause named to crash.
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2014:1244 https://rhn.redhat.com/errata/RHSA-2014-1244.html