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
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
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
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.