Re: BIND Security Advisory (CVE-2009-0025; Severity: Low)

70 views
Skip to first unread message

David Coulthart

unread,
Jan 8, 2009, 9:10:42 AM1/8/09
to
On Jan 7, 2009, at 2:32 PM, Rob_A...@isc.org wrote:
> Internet Systems Consortium Security Advisory.
> BIND: EVP_VerifyFinal() and DSA_do_verify() return checks.
> 7 January 2009
>
> Versions affected:
>
> BIND 9.0 (all versions)
> BIND 9.1 (all versions)
> BIND 9.2 (all versions)
> BIND 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4, 9.3.5, 9.3.6
> BIND 9.4.0, 9.4.1, 9.4.2, 9.4.3
> BIND 9.5.0, 9.5.1
> BIND 9.6.0
>
> Severity: Low.
>
> Description:
>
> Return values from OpenSSL library functions EVP_VerifyFinal()
> and DSA_do_verify() were not checked properly.
>
> Impact:
>
> It is theoretically possible to spoof answers returned from
> zones using the DNSKEY algorithms DSA (3) and NSEC3DSA (6).

<snip>

Would someone be able to provide some more details as to what
particular configurations of BIND this affects? My interpretation is
it only impacts recursive nameservers that have DNSSEC validation
enabled. Speaking in terms of BIND config options, the dnssec-
validation option would need to be set to yes (so just having the
default of dnssec-enable set to yes isn't enough to make the server
vulnerable). Is this a correct interpretation?

Thanks,
Dave Coulthart
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Steve Shockley

unread,
Jan 9, 2009, 3:37:27 PM1/9/09
to
On 1/8/2009 9:10 AM, David Coulthart wrote:
> Would someone be able to provide some more details as to what particular
> configurations of BIND this affects? My interpretation is it only
> impacts recursive nameservers that have DNSSEC validation enabled.
> Speaking in terms of BIND config options, the dnssec-validation option

> would need to be set to yes (so just having the default of dnssec-enable
> set to yes isn't enough to make the server vulnerable). Is this a
> correct interpretation?

The OpenSSL vulnerability affects DSA and ECDSA certificates; an
attacker is able to bypass validation of the certificate. Since DNSSEC
uses ECDSA, this means an attacker could use a forged certificate in a
man-in-the-middle attack.

If you're not using DNSSEC, then this vulnerability doesn't really
affect you, since you already have no way of knowing if a MITM attack is
occurring.

Rob Austein

unread,
Jan 10, 2009, 11:05:52 PM1/10/09
to
At Thu, 8 Jan 2009 09:10:42 -0500, David Coulthart wrote:
>
> Would someone be able to provide some more details as to what
> particular configurations of BIND this affects? My interpretation is
> it only impacts recursive nameservers that have DNSSEC validation
> enabled.

And not even all of those. It only affects DSA signatures (RSA is not
affected), and only if an attacker can provoke a rather peculiar error
condition.

The root problem, which was also behind the recent OpenSSL release, is
that a couple of the low-level OpenSSL libcrypto library functions
that deal with DSA signatures return a tri-state value rather than a
boolean: 1 == success, 0 == bad signature, -1 == other failure (eg,
malloc() failure). The corresponding RSA functions return boolean
values, this is a peculiarity of the DSA routines. Due to the, um,
minimal nature of the OpenSSL internals documentation, a lot of code
that calls the OpenSSL DSA was not checking the error returns
correctly, and was misinterpreting "other" errors as success. Among
others, affected code included both a few routines in BIND's DNSSEC
code and portions of OpenSSL itself (if you look closely at the recent
OpenSSL release, you'll see that there were a bunch of little changes
in libssl to fix this).

So an attacker trying to exploit this vulnerablity would have to
provoke an "other" error while the victim was validating a DSA
signature. This is pretty freaking unlikely, hence the "Severity:
low" rating on the BIND security advisory, but as nobody can prove
that this can't be done and BIND really wasn't checking the return
code correctly, it seemed best to handle the fix as a security issue.

> Speaking in terms of BIND config options, the dnssec-validation
> option would need to be set to yes (so just having the default of
> dnssec-enable set to yes isn't enough to make the server
> vulnerable). Is this a correct interpretation?

"Vulnerable" in this case means "could be tricked into believing
DNSSEC signatures that should not have passed validation". That is,
we're not talking about named crashing here, we're talking about a
security mechanism not working as expected due to a bug.

If you don't have DNSSEC validation enabled you presumably have no
expectation that DNSSEC signatures will be checked correctly, so,
indeed, you are "not affected", in that without DNSSEC there are
easier ways to feed you bad data.

At Fri, 09 Jan 2009 15:37:27 -0500, Steve Shockley wrote:
>
> The OpenSSL vulnerability affects DSA and ECDSA certificates; an
> attacker is able to bypass validation of the certificate. Since DNSSEC
> uses ECDSA, this means an attacker could use a forged certificate in a
> man-in-the-middle attack.

s/certificate/RRSIG/ (DNSSEC doesn't use certificates).

> If you're not using DNSSEC, then this vulnerability doesn't really
> affect you, since you already have no way of knowing if a MITM
> attack is occurring.

Exactly.

Reply all
Reply to author
Forward
0 new messages