<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Change: BIND 9.4-ESV-R4-P1 is now available.<br>
<br>
Title: Large RRSIG RRsets and Negative Caching can crash named.<br>
<br>
Summary: A BIND 9 DNS server set up to be a caching resolver is<br>
vulnerable to a user querying a domain with very large resource
record<br>
sets (RRSets) when trying to negatively cache a response. This can
cause<br>
the BIND 9 DNS server (named process) to crash.<br>
<br>
Document ID: CVE-2011-1910<br>
<br>
Posting date: 26 May 2011<br>
<br>
Program Impacted: BIND<br>
<br>
Versions affected: 9.4-ESV-R3 and later, 9.6-ESV-R2 and later,
9.6.3,<br>
9.7.1 and later, 9.8.0 and later<br>
<br>
Severity: High<br>
<br>
Exploitable: Remotely<br>
<br>
CVSS Score: Base 7.8<br>
<br>
(AV:N/AC:L/Au:N/C:N/I:N/A:C)<br>
<br>
For more information on the Common Vulnerability Scoring System
and to<br>
obtain your specific environmental score please visit:<br>
<a class="moz-txt-link-freetext" href="http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2">http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2</a><br>
<br>
Description:<br>
<br>
DNS systems use negative caching to improve DNS response time.
This will<br>
keep a DNS resolver from repeatedly looking up domains that do not<br>
exist. Any NXDOMAIN or NODATA/NOERROR response will be put into
the<br>
negative cache.<br>
<br>
The authority data will be cached along with the negative cache<br>
information. These authoritative ?Start of Authority? (SOA) and<br>
NSEC/NSEC3 records prove the nonexistence of the requested
name/type. In<br>
DNSSEC, all of these records are signed; this adds one additional
RRSIG<br>
record, per DNSSEC key, for each record returned in the authority<br>
section of the response.<br>
<br>
In this vulnerability, very large RRSIG RRsets included in a
negative<br>
cache can trigger an assertion failure that will crash named (BIND
9<br>
DNS) due to an off-by-one error in a buffer size check.<br>
<br>
The nature of this vulnerability would allow remote exploit. An
attacker<br>
can set up an DNSSEC signed authoritative DNS server with a large
RRSIG<br>
RRsets to act as the trigger. The attacker would then find ways to
query<br>
an organization?s caching resolvers, using the negative caches and
the<br>
?trigger? the vulnerability. The attacker would require access to
an<br>
organization?s caching resolvers. Access to the resolvers can be
direct<br>
(open resolvers), through malware (using a BOTNET to query
negative<br>
caches), or through driving DNS resolution (a SPAM run that has a
domain<br>
in the E-mail that will cause the client to do look up a negative
cache).<br>
<br>
Workarounds: Restricting access to the DNS caching resolver<br>
infrastructure will provide partial mitigation. Active
exploitation can<br>
be accomplished through malware or SPAM/Malvertizing actions that
will<br>
force authorized clients to look up domains that would trigger
this<br>
vulnerability.<br>
<br>
Solution:<br>
<br>
Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2<br>
<a class="moz-txt-link-freetext" href="ftp://ftp.isc.org/isc/bind9/9.8.0-P2">ftp://ftp.isc.org/isc/bind9/9.8.0-P2</a><br>
<a class="moz-txt-link-freetext" href="ftp://ftp.isc.org/isc/bind9/9.7.3-P1">ftp://ftp.isc.org/isc/bind9/9.7.3-P1</a><br>
<a class="moz-txt-link-freetext" href="ftp://ftp.isc.org/isc/bind9/9.6-ESV-R4-P1">ftp://ftp.isc.org/isc/bind9/9.6-ESV-R4-P1</a><br>
<a class="moz-txt-link-freetext" href="ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1">ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1</a><br>
<br>
Exploit Status: High. This issue has caused unintentional outages.<br>
<br>
US CERT is tracking this issue with INC000000152411.<br>
<br>
Credits:<br>
<br>
Thanks to Frank Kloeker and Michael Sinatra for getting the
details to<br>
this issue to the DNS Operations community and to Michael Sinatra,
Team<br>
Cmyru, and other community members for testing.<br>
<br>
Revision History: Added the 9.4-ESV-R4-P1 download. 2011-May-27<br>
<br>
Questions regarding this advisory should go to
<a class="moz-txt-link-abbreviated" href="mailto:security-officer@isc.org">security-officer@isc.org</a>.<br>
Questions on ISC's Support services or other offerings should be
sent to<br>
<a class="moz-txt-link-abbreviated" href="mailto:sales@isc.org">sales@isc.org</a>. More information on ISC's support and other
offerings are<br>
available at:
<a class="moz-txt-link-freetext" href="http://www.isc.org/community/blog/201102/BIND-support">http://www.isc.org/community/blog/201102/BIND-support</a><br>
<br>
- -- <br>
Larissa Shapiro<br>
Internet Systems Consortium Product Manager<br>
Technology Leadership for the Common Good<br>
+1 650 423 1335<br>
<a class="moz-txt-link-abbreviated" href="http://www.isc.org">www.isc.org</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)<br>
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a><br>
<br>
iQEcBAEBAgAGBQJN36ZpAAoJEBOIp87tasiUTpcIAKJ3c3dt+DmlHu98OxiLcDEZ<br>
PCdAjEKKqLc4jc/M0W/kyIQst4hRA3UzVNQVzlGtiwUn4qaTldtraPVeIfJmN3OE<br>
QgqaqA3357QUnyWjgo4jyva/0F1SSNnyb3swt7XpFHKki7V/xlhJqYKM9juoc9pI<br>
BWVJD/GwDKv/OhdR2bUBXUSJ8YvDuZUIVV/XIHxBZPufI60/PAXB8yab+BvOXtJ3<br>
5U4V8duvUK36YaGTY6qMnnHQZTy2EP6kr5nvVo6f5odUsCWlSYph7se4ar1M2nZJ<br>
Nq6aK6Xz5gQ/PEKNCdT9oiQwP9/dhZ7UYcDW3xMtbVGJjDoMCOmVRASjFNCFuzg=<br>
=4WMW<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>