OpenSSL heartbleed bug

Unbound
1

(To unbound-users / nsd-users)

Hi,

OpenSSL heartbleed bug (CVE-2014-0160) affects Unbound/NSD?

I believe that unbound-control, ssl-upstream(unbound’s), and nsd-control
depends on OpenSSL to make secure channel.

(though remote control is usually allowed from localhost only…)

Regards,

2

Hi Daisuke,

(To unbound-users / nsd-users)

Hi,

OpenSSL heartbleed bug (CVE-2014-0160) affects Unbound/NSD?

NSD and Unbound have DNSSEC that does not use TLS, so they are not
affected by heartbleed for DNSSEC.

I believe that unbound-control, ssl-upstream(unbound's), and
nsd-control depends on OpenSSL to make secure channel. (though
remote control is usually allowed from localhost only...)

Yes the default is from localhost. Additionally, nsd-control and
unbound-control require a client certificate. This seems to stop the
attack (when we tested it).

Unbound's ssl-upstream, ssl-service and unbound-anchor are options and
tools that create TLS connections. This is vulnerable to heartbleed.
Unbound-anchor is a client side, short lived process with no secrets,
it makes TLS connections in exceptional circumstances. ssl-upstream
makes client connections. Unbound's ssl-service options create a TLS
server, and this is vulnerable. The public TLS dnssec-trigger server
has had openssl upgraded.

Best regards,
   Wouter

3

For clarity to those asking (since Wouter knows this but it wasn't
clear): if you're changing keys/certs in response to Heartbleed (as I
am) then it's because arbitrary server memory can be read.

So if you have ssl-service-key set then you're vulnerable, but you need
to then change _all_ keys and certs used by Unbound, including for those
services which are not part of the attack vector, not _just_
ssl-service-key.

-Phil

4

Yes, we should change all keys/certs after upgrading OpenSSL if HB bug affected.

Regards,