<!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>
*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<br>
cause the BIND 9 DNS server (named process) to crash.<br>
<br>
*Document ID:* CVE-2011-1910<br>
<br>
*Document Status:* Draft<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,<br>
9.6.3, 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<br>
will keep a DNS resolver from repeatedly looking up domains that
do<br>
not exist. Any NXDOMAIN or NODATA/NOERROR response will be put
into<br>
the 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.<br>
In DNSSEC, all of these records are signed; this adds one
additional<br>
RRSIG record, per DNSSEC key, for each record returned in the<br>
authority 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<br>
attacker can set up an DNSSEC signed authoritative DNS server with
a<br>
large RRSIG RRsets to act as the trigger. The attacker would then
find<br>
ways to query an organization?s caching resolvers, using the
negative<br>
caches and the ?trigger? the vulnerability. The attacker would
require<br>
access to an organization?s caching resolvers. Access to the
resolvers<br>
can be direct (open resolvers), through malware (using a BOTNET to<br>
query negative caches), or through driving DNS resolution (a SPAM
run<br>
that has a domain in the E-mail that will cause the client to do
look<br>
up a negative cache).<br>
<br>
*Workarounds:* Restricting access to the DNS caching resolver<br>
infrastructure will provide partial mitigation. Active
exploitation<br>
can be accomplished through malware or SPAM/Malvertizing actions
that<br>
will force authorized clients to look up domains that would
trigger<br>
this 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>
BIND 9.4 is less vulnerable than other versions, and a patched
version<br>
will be available on May 27th at
<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 un-intentional
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,<br>
Team Cmyru, and other community members for testing.<br>
<br>
Questions regarding this advisory shoud go to
<a class="moz-txt-link-abbreviated" href="mailto:security-officer@isc.org">security-officer@isc.org</a><br>
<a class="moz-txt-link-rfc2396E" href="mailto:security-officer@isc.org"><mailto:security-officer@isc.org></a>. Questions on ISC's
Support services<br>
or other offerings should be<br>
sent to <a class="moz-txt-link-abbreviated" href="mailto:info@isc.org">info@isc.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:dhcp-bugs@isc.org"><mailto:dhcp-bugs@isc.org></a> More
information on<br>
ISC's support and other offerings are available<br>
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>
iQEcBAEBAgAGBQJN3zgqAAoJEBOIp87tasiU0RgH/1eOHonKvvh3gcAfzzhWezNr<br>
0X+ERXldJnylLYUrVPoVdzFXCsKkReY6qrTDUJnO6qvB62oYQNfZnO21fkM17m6Z<br>
wA/HTnnu5YlnmHZQVabCJptLWsJ7nGwFygKdwgJbu/npWmSaEoKgNWIdcWbnVlm6<br>
xk9XXdjc25rJLIqTgXXWWnyAsFc0SvNomOFd2zkuPsa7vuJczpdWw1Rdn9TP1vOo<br>
BF1gS2GR7O9ewghTQGXCAcNNdezconkE7moxTZx6y8qGGyP8nvfRwGWneXKjy49r<br>
8rY1ABo92rly60E8uCs4S8tiFQxTlwWsGBfyREk0SClvT1PFDM+Yz11U/FmBG2E=<br>
=QKvu<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>