On 26/05/2011 22:53, Jan Ingvoldstad wrote:
Hi.
At $workplace, two of our internal, caching DNS servers, running Bind
9 experienced crashes in quick order today.
Hello, may be it has something related to this?
***
*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
*Document Status:* Draft
*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 organization?s caching resolvers, using the negative
caches and the ?trigger? the vulnerability. The attacker would require
access to an organization?s 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 on May 27th at ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1
*Exploit Status:* High. This issue has caused un-intentional outages.
US CERT is tracking this issue with INC00152411.
***
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ddf5af3.7000...@securitylabs.it
