NSEC3
=============================================================================
FreeBSD-SA-10:01.bind Security Advisory
The FreeBSD Project
Topic: BIND named(8) cache poisoning with DNSSEC validation
Category: contrib
Module: bind
Announced: 2010-01-06
Credits: Michael Sinatra
This update restores the PID file location for bind to the location
before the last security update. For reference, here is the original
advisory text that explains the security problems fixed:
Several cache-poisoning vulnerabilities have been discovered in BIND.
These vulnerabilities are apply only if DNSSEC validation is enabled and
trust anchors have been installed, which is not the default.
The Common Vulnerabilities and Exposures project identifies the
following problems:
Some vulnerabilities were discovered and corrected in bind:
The original fix for CVE-2009-4022 was found to be incomplete. BIND
was incorrectly caching certain responses without performing proper
DNSSEC validation. CNAME and DNAME records could be cached, without
proper DNSSEC validation, when received from processing recursive
client queries that requested DNSSEC records but indicated that
checking should be disabled. A remote attacker could use this flaw
to bypass the DNSSEC validation check and perform a cache poisoning
attack if the target BIND server was receiving such client queries
Problem type : remote
Debian-specific: no
CVE Id(s) : CVE-2010-0097 CVE-2010-0290 CVE-2010-0382
Several cache-poisoning vulnerabilities have been discovered in BIND.
These vulnerabilities are apply only if DNSSEC validation is enabled and
trust anchors have been installed, which is not the default.
The Common Vulnerabilities and Exposures project identifies the
following problems:
=============================================================================
FreeBSD-SA-09:04.bind Security Advisory
The FreeBSD Project
Topic: BIND DNSSEC incorrect checks for malformed signatures
Category: contrib
Module: bind
Announced: 2009-01-13
Credits: Google Security Team
Debian-specific: no
CVE Id(s) : CVE-2009-3602
It was discovered that Unbound, a DNS resolver, does not properly
check cryptographic signatures on NSEC3 records. As a result, zones
signed with the NSEC3 variant of DNSSEC lose their cryptographic
protection. (An attacker would still have to carry out an ordinary
cache poisoning attack to add bad data to the cache.)
The old stable distribution (etch) does not contain an unbound
package.
* hosted products are VMware Workstation, Player, ACE, Server, Fusion.
e. vMA and Service Console package bind updated to 9.3.6-4.P1.el5_4.1
It was discovered that BIND was incorrectly caching responses
without performing proper DNSSEC validation, when those responses
were received during the resolution of a recursive client query
that requested DNSSEC records but indicated that checking should be
disabled. A remote attacker could use this flaw to bypass the DNSSEC
validation check and perform a cache poisoning attack if the target
BIND server was receiving such client queries.
https://www.isc.org/node/373
http://groups.google.com/group/comp.protocols.dns.bind/browse_thread/thread/49ef622c8329fd33
Description:
Previous versions of BIND incorrectly interpret the return value of the
OpenSSL DSA_do_verify function. On systems using DNSSEC, a malicious zone
could present a malformed DSA certificate and bypass proper certificate
validation, allowing spoofing attacks.
rPath Linux does not ship with DNSSEC enabled, and therefore is not, by
default, vulnerable to this attack.
Some vulnerabilities were discovered and corrected in bind:
Unspecified vulnerability in ISC BIND 9.4 before 9.4.3-P4, 9.5
before 9.5.2-P1, 9.6 before 9.6.1-P2, 9.7 beta before 9.7.0b3,
and 9.0.x through 9.3.x with DNSSEC validation enabled and checking
disabled (CD), allows remote attackers to conduct DNS cache poisoning
attacks via additional sections in a response sent for resolution
of a recursive client query, which is not properly handled when the
response is processed at the same time as requesting DNSSEC records
(DO). (CVE-2009-4022).
Some vulnerabilities were discovered and corrected in bind:
Unspecified vulnerability in ISC BIND 9.4 before 9.4.3-P4, 9.5
before 9.5.2-P1, 9.6 before 9.6.1-P2, 9.7 beta before 9.7.0b3,
and 9.0.x through 9.3.x with DNSSEC validation enabled and checking
disabled (CD), allows remote attackers to conduct DNS cache poisoning
attacks via additional sections in a response sent for resolution
of a recursive client query, which is not properly handled when the
response is processed at the same time as requesting DNSSEC records
(DO). (CVE-2009-4022).
>
> Perhaps it's more politically convenient to leave blind attacks in place
> in order to push other agenda? It seems invariably those making the
> all-or-nothing argument that 16 bits (in reality 30 bits if you get off
> your ass and think about it) is not enough entropy no matter the
> generator are all too often pushing DNSSEC in the very next sentence.
> I'm not saying DNSSEC is good or bad, and it is designed to remedy more
> than just blind attacks, but it's unethical to ignore a problem that can
> be mitigated in the short term just so a new technology can be forced
> down people's throats in the long term.
necessary changes.
Details follow:
It was discovered that Bind would incorrectly cache bogus NXDOMAIN
responses. When DNSSEC validation is in use, a remote attacker could
exploit this to cause a denial of service, and possibly poison DNS caches.
(CVE-2010-0097)
USN-865-1 provided updated Bind packages to fix a security vulnerability.
The upstream security patch to fix CVE-2009-4022 was incomplete and
Perhaps it's more politically convenient to leave blind attacks in place
in order to push other agenda? It seems invariably those making the
all-or-nothing argument that 16 bits (in reality 30 bits if you get off
your ass and think about it) is not enough entropy no matter the
generator are all too often pushing DNSSEC in the very next sentence.
I'm not saying DNSSEC is good or bad, and it is designed to remedy more
than just blind attacks, but it's unethical to ignore a problem that can
be mitigated in the short term just so a new technology can be forced
down people's throats in the long term.
> de raadt offered me his random number generator to use. bind9 should've
> used that same one but apparently didn't. note that with this fix, the
> difficulty in poisoning someone's cache rises from "a few tens of
> seconds"
> to "a few minutes". it's a 16-bit field. not a lot of room for
> randomness or unpredictability. only DNSSEC, a protocol change, fixes
> this problem, which is fundamentally a protocol problem. but since folks
> just won't leave it alone and keep on reporting it year after decade, we
> will keep on improving our random number generator for this dinky little
> 16-bit field. i just wish the reporters wouldn't be so smarmy and self
> congradulatory about it. it's not like this hasn't been reported, and
way ISC BIND processed certain DNS query responses.
ISC BIND (Berkeley Internet Name Domain) is an implementation of
the DNS (Domain Name System) protocols. Under some circumstances, a
malicious remote user could launch a Denial-of-Service attack on
ESX Server hosts that had enabled DNSSEC validation.
(CVE-2007-0494)
Note: These issues only affect the service console network, and are
not remote vulnerabilities for ESX Server hosts that have been set
up with the security best practices provided by VMware.
> odd to have to keep fixing it-- i fixed it in bind4 and bind8 when theo
> de raadt offered me his random number generator to use. bind9 should've
> used that same one but apparently didn't. note that with this fix, the
> difficulty in poisoning someone's cache rises from "a few tens of seconds"
> to "a few minutes". it's a 16-bit field. not a lot of room for
> randomness or unpredictability. only DNSSEC, a protocol change, fixes
> this problem, which is fundamentally a protocol problem. but since folks
> just won't leave it alone and keep on reporting it year after decade, we
> will keep on improving our random number generator for this dinky little
> 16-bit field. i just wish the reporters wouldn't be so smarmy and self
> congradulatory about it. it's not like this hasn't been reported, and
> typically DNS is provided by an ISP or some other agency with a formal
> legal relationship, and there is the possibility of liability on the
> part of the lax DNS provider. Hopefully we will continue to see rapid
> uptake of the DNS fix over the next few weeks.
In general, DNS is not fixable without deploying DNSSEC.
a) The current "fix" just reduces the probability of an attack. If
attacker and victim have sufficient bandwidth, it can still be done in
under a day.
odd to have to keep fixing it-- i fixed it in bind4 and bind8 when theo
de raadt offered me his random number generator to use. bind9 should've
used that same one but apparently didn't. note that with this fix, the
difficulty in poisoning someone's cache rises from "a few tens of seconds"
to "a few minutes". it's a 16-bit field. not a lot of room for
randomness or unpredictability. only DNSSEC, a protocol change, fixes
this problem, which is fundamentally a protocol problem. but since folks
just won't leave it alone and keep on reporting it year after decade, we
will keep on improving our random number generator for this dinky little
16-bit field. i just wish the reporters wouldn't be so smarmy and self
congradulatory about it. it's not like this hasn't been reported, and
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0290
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0382
Description:
In previous versions of BIND, there have been several vulnerabilities
reported related to cache poisoning of systems where DNSSEC is enabled.
To address these issues, BIND has been updated to 9.4.3-P5 in both
rPath Linux 1 and 2.
For rPL 1, this update includes a library version change, so the
older package versions have been promoted to the rpl:1-compat label.
AOL, VISA etc (really good). An attacker would still be able to setup a 'test'
root CA and make you accept it's cert for that 'test' DNS universe-part (bad).
It seems to me more of a DNS problem than a x509 problem.
If that's the case we should tend in using protocols for securing the DNS system,
like DNSSEC or something better.
x509 and TLS is really nice and helps even in that.
cheers,
Giannis
Synopsis
========
Incomplete verification of RSA and DSA certificates might lead to
spoofed records authenticated using DNSSEC.
Background
==========
ISC BIND is the Internet Systems Consortium implementation of the
David Bryan - Hacking with GnuRadio
Don Ankney - Is XSS Solveable?
Jim O’Gorman - Policy - The Biscuit Game of Infosec
Datagram - Lockpicking Forensics
Kevin Nassery - Diplomatic Security Consulting
Erik Berls - Deploying DNSSEC
Joe McCray - Advanced SQL Injection
Strom Carlson - Why your mother will never care about Linux
Deviant Ollam - Packing and the Friendly Skies
CP, Adam, Frank^2, Vyrus - TwatFS: Surly abuse of social networking bandwidth
Ryan S. Upton, CISSP - Incident Response 101
Michael Sinatra discovered that the DNS resolver component in BIND
does not properly check DNS records contained in additional sections
of DNS responses, leading to a cache poisoning vulnerability. This
vulnerability is only present in resolvers which have been configured
with DNSSEC trust anchors, which is still rare.
Note that this update contains an internal ABI change, which means
that all BIND-related packages (bind9, dnsutils and the library
packages) must be updated at the same time (preferably using "apt-get
update" and "apt-get upgrade"). In the unlikely event that you have
The first vulnerable version, 0.9.8c-1, was uploaded to the unstable
distribution on 2006-09-17, and has since propagated to the testing and
current stable (etch) distributions. The old stable distribution
(sarge) is not affected.
Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key
material for use in X.509 certificates and session keys used in SSL/TLS
connections. Keys generated with GnuPG or GNUTLS are not affected,
though.
A detector for known weak key material will be published at:
CVE Id(s) : CVE-2009-0025
It was discovered that BIND, an implementation of the DNS protocol
suite, does not properly check the result of an OpenSSL function which
is used to verify DSA cryptographic signatures. As a result,
incorrect DNS resource records in zones protected by DNSSEC could be
accepted as genuine.
For the stable distribution (etch), this problem has been fixed in
version 9.3.4-2etch4.
b. Update bind package for the Service Console fixes a security issue.
A flaw was discovered in the way Berkeley Internet Name Domain
(BIND) checked the return value of the OpenSSL DSA_do_verify
function. On systems using DNSSEC, a malicious zone could present
a malformed DSA certificate and bypass proper certificate
validation, allowing spoofing attacks.
The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CVE-2009-0025 to this issue.
necessary changes.
Details follow:
It was discovered that Bind did not properly perform certificate verification.
When DNSSEC with DSA certificates are in use, a remote attacker could exploit
this to bypass certificate validation to spoof DNS entries and poison DNS
caches. Among other things, this could lead to misdirected email and web
traffic.
necessary changes.
Details follow:
Michael Sinatra discovered that Bind did not correctly validate certain
records added to its cache. When DNSSEC validation is in use, a remote
attacker could exploit this to spoof DNS entries and poison DNS caches.
Among other things, this could lead to misdirected email and web traffic.
Updated packages for Ubuntu 6.06 LTS:
that we need to fill, so if you are interested in speaking at this
year’s event please submit a paper via our CFP address of ‘cfp <at>
layerone <dot> info’. Our current selection of speakers covers a wide
range of interests. We will have presentations covering such topics as
Web Application Security, GnuRadio, Lockpicking Forensics, Security
Consulting, and DNSSEC. Our speakers come from a wide variety of
backgrounds and are all subject matter experts in their respective
fields.
Pre-Registration has opened for this year’s event. The
pre-registration price is 100.00USD and is available through our
_______________________________________________________________________
Problem Description:
A flaw was found in how BIND checked the return value of the OpenSSL
DSA_do_verify() function. On systems that use DNSSEC, a malicious zone
could present a malformed DSA certificate and bypass proper certificate
validation, which would allow for spoofing attacks (CVE-2009-0025).
The updated packages have been patched to prevent this issue.
_______________________________________________________________________
|
