DNS BIND Security Advisory - A BIND 9 DNS server set up to be a caching resolver is vulnerable to a user querying a domain with very large resource record sets (RRSets) when trying to negatively cache a response. This can cause the BIND 9 DNS server (named process) to crash. Versions affected include 9.4-ESV-R3 and later, 9.6-ESV-R2 and later, 9.6.3, 9.7.1 and later, 9.8.0 and later.
fa50a97638e2f7e6a97d4f93201d255bcf855b0b42fd27b17eea562af70dec7f
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
- -----
Posted from: http://www.isc.org/software/bind/advisories/cve-2011-1910
- -----
Title: Large RRSIG RRsets and Negative Caching can crash named.
Summary: A BIND 9 DNS server set up to be a caching resolver is
vulnerable to a user querying a domain with very large resource record
sets (RRSets) when trying to negatively cache a response. This can cause
the BIND 9 DNS server (named process) to crash.
Document ID: CVE-2011-1910
Posting date: 26 May 2011
Program Impacted: BIND
Versions affected: 9.4-ESV-R3 and later, 9.6-ESV-R2 and later, 9.6.3,
9.7.1 and later, 9.8.0 and later
Severity: High
Exploitable: Remotely
CVSS Score: Base 7.8
(AV:N/AC:L/Au:N/C:N/I:N/A:C)
For more information on the Common Vulnerability Scoring System and to
obtain your specific environmental score please visit:
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2
Description:
DNS systems use negative caching to improve DNS response time. This will
keep a DNS resolver from repeatedly looking up domains that do not
exist. Any NXDOMAIN or NODATA/NOERROR response will be put into the
negative cache.
The authority data will be cached along with the negative cache
information. These authoritative Start of Authority (SOA) and
NSEC/NSEC3 records prove the nonexistence of the requested name/type. In
DNSSEC, all of these records are signed; this adds one additional RRSIG
record, per DNSSEC key, for each record returned in the authority
section of the response.
In this vulnerability, very large RRSIG RRsets included in a negative
cache can trigger an assertion failure that will crash named (BIND 9
DNS) due to an off-by-one error in a buffer size check.
The nature of this vulnerability would allow remote exploit. An attacker
can set up an DNSSEC signed authoritative DNS server with a large RRSIG
RRsets to act as the trigger. The attacker would then find ways to query
an organizations caching resolvers, using the negative caches and the
trigger the vulnerability. The attacker would require access to an
organizations caching resolvers. Access to the resolvers can be direct
(open resolvers), through malware (using a BOTNET to query negative
caches), or through driving DNS resolution (a SPAM run that has a domain
in the E-mail that will cause the client to do look up a negative cache).
Workarounds: Restricting access to the DNS caching resolver
infrastructure will provide partial mitigation. Active exploitation can
be accomplished through malware or SPAM/Malvertizing actions that will
force authorized clients to look up domains that would trigger this
vulnerability.
Solution:
Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2
ftp://ftp.isc.org/isc/bind9/9.8.0-P2
ftp://ftp.isc.org/isc/bind9/9.7.3-P1
ftp://ftp.isc.org/isc/bind9/9.6-ESV-R4-P1
BIND 9.4 is less vulnerable than other versions, and a patched version
will be available soon at ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1
Exploit Status: High. This issue has caused unintentional outages.
US CERT is tracking this issue with INC000000152411.
Credits:
Thanks to Frank Kloeker and Michael Sinatra for getting the details to
this issue to the DNS Operations community and to Michael Sinatra, Team
Cmyru, and other community members for testing.
Questions regarding this advisory should go to security-officer@isc.org.
Questions on ISC's Support services or other offerings should be sent to
sales@isc.org. More information on ISC's support and other offerings are
available at: http://www.isc.org/community/blog/201102/BIND-support
-----BEGIN PGP SIGNATURE-----
Version: 10.1.0.860
wsBVAwUBTd87bFVuk3AWv0XzAQjaxgf/Skv9OMW5ri012RUeLT92R70LW1wQ5ZBK
YpDdc3XgsfvNKcfW0zlcrCfmt7nFNWBe6SmAuI8tz6hfgcuYgp3OcuEJHt1UKKl3
E30QSuyjd0Pt/HTHlTd2IlNfpgbp3LzH1yL6phfCUi1CzqY0SmtpJuOUSPJbYfvO
V1S+eARLzfflzwEWUxzZM05LqFo4jqMFWhjvNZdk3lRmZ0bcJv92oEeXHwaWDUKC
qSt2RBCQ6zITydgkK0BvnVQ/SsN/DFv7o809zFpJiqdjpwkL55dkqeI79m0zOMYp
b+luCihB12ukliMdkhfA9iPSDNsghTZayOMQVg0sonCOkWbr1IseSg==
=EcbL
-----END PGP SIGNATURE-----