[Other] Schwachstelle im ISC BIND 9 DNS Server - CVE-2011-1910

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

Liebe Kolleginnen und Kollegen,

soeben erreichte uns nachfolgende Warnung. Wir geben diese Informationen
unveraendert an Sie weiter.

CVE-2011-1910 – Denial of Service Schwachstelle im ISC BIND 9 DNS Server

Ein BIND 9 DNS Server, der als zwischenspeichernder Resolver
konfiguriert ist, behandelt Anfragen nach nicht existierenden Domaenen
mit sehr grossen Resource Record Sets in unsicherer Weise. Eine Anfrage
die NXDOMAIN oder NODATA/NOERROR zur Antwort erhaelt wird zusammen mit
den “Start of Authority” (SOA) und NSEC/NSEC3 Eintraegen in einem
Negativcache zwischengespeichert, um die Antwortzeiten zu verbessern. In
DNSSEC sind diese Eintraege alle signiert und fuer jeden Eintrag in der
‘authority section’ wird per DNSSEC Schluessel ein zusaetzlicher RRSIG
Eintrag gespeichert. Da in der Ermittlung der Pufferspeichergroesse ein
off-by-one Fehler vorhanden ist, kann der Nameserver zum Absturz
gebracht werden. Ein entfernter Angreifer mit Zugang zu der Anwendung,
kann diese Schwachstelle zu einem Denial of Service Angriff ausnutzen.

Betroffen sind die folgenden Software Pakete und Plattformen:

ISC BIND vor Version 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 oder
9.8.0-P2

Alle Plattformen fuer die ISC BIND verfuegbar ist.

Vom Hersteller werden ueberarbeitete Pakete zur Verfuegung gestellt.

(c) der deutschen Zusammenfassung bei DFN-CERT Services GmbH; die
Verbreitung, auch auszugsweise, ist nur unter Hinweis auf den Urheber,
DFN-CERT Services GmbH, und nur zu nicht kommerziellen Zwecken
gestattet.

Mit freundlichen Gruessen,
Detlev O. Matthies

– —

Detlev O. Matthies, M.Sc. (Incident Response Team)

DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-590
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

Automatische Warnmeldungen https://www.cert.dfn.de/autowarn

– —–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

*Due to the disclosed nature of this vulnerability, we could not send
notice in advance. Consider this vulnerability to be active and known
publicly.
*

*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 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 shoud go to security-officer@isc.org
. Questions on ISC’s Support services
or other offerings should be
sent to info@isc.org More information on
ISC’s support and other offerings are available
at:http://www.isc.org/community/blog/201102/BIND-support

– – —
Larissa Shapiro
Internet Systems Consortium Product Manager
Technology Leadership for the Common Good
+1 650 423 1335
www.isc.org

– —–BEGIN PGP SIGNATURE—–
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla – http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN3zg0AAoJEBOIp87tasiUV70IAJS1NOEWK6gPLkINFZ2KcnjJ
Sb/r3xrjX4dNjoHnoVQ9dHUCjz8ckWqSpYda/ek1QQphp7XrC5NX+f/Ouv6QrVH+
AXdwdccnfFJVjHp/SsyA3yzZ/XWvq+irjxu/jvH/X5qX2oTA5S/Ydlc8aoQtbdGM
09DMZ453IWHUlOt1WGyNOnB7nc5mjrvqnMJjghi+XPaJG7btYXWJfosNIqb1UyQ1
CTAzmwwcM3nj5r8xw3juuzK4/Wocl0A27svtsoOPMXh5vIp+E0/6r6YOdb1vUKoR
I1EYMDv0YdOlLhtz0Sp3cU9TeOG8Je4CdmA6iaWdi7DqG6p37vY6aQLcNIf9JAU=
=9mTB
– —–END PGP SIGNATURE—–

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v2.0.16 (GNU/Linux)

iQEcBAEBAgAGBQJN36g4AAoJEJtyb8U7iGZBT/0H/jp1owV+pVEMH1Qks9tj29Lu
X6aCur78hlfgKRqFlzK64rJA+ifIAo5W2WAEKGE0GP3FwDh4kunbedvFlNS6YYh+
EOf6hnOskUUuurqm2mlxaz1DV06MKo0E+pU2KhvVDIUofGKr9SrXGVzGXl7aKNvH
m/x88j8ARPLVTsvDj/jCL3+r22cPIRSLU9O0g4nzkN9zK/F5XabHAppFC1y4Ho4j
zXyGd7E8uVYwea+IVv+dTN/ejTbhwQAZ8bt8hGHPkMxBkBOmtDyAWFAXuSjFHVWM
yyuXUFybkYNy2OMiV46YH2T1W94i5KFvJBqXFJDoc8AzItpiShShJkz52BhUzeU=
=Fqrt
—–END PGP SIGNATURE—–

Nach oben