So, DNSSEC is also compromised by this heartbleed bug, right?
There is nothing in the DNSSEC protocol that requires the Heartbeat functionality. However whether a specific implementation of DNS software is vulnerable or not depends on how it's compiled. I would expect that most would not be. ISC for example just released a statement that BIND is not:
https://lists.isc.org/pipermail/bind-users/2014-April/092944.html
hth,
Doug
Nope, apples and oranges.
http://www.afilias.info/webfm_send/32
The only point of intersection I can think of is an indirect one, and unfortunately not much used yet: DANE certificates for TLS/SSL connections.
-Bill
Once upon a time, Barry Shein <bzs@world.std.com> said:
So, DNSSEC is also compromised by this heartbleed bug, right?
No, wrong. The OpenSSL bug involves an extension to the TLS protocol
called "heartbeat" (basically like a TCP or PPP keepalive).
DNSSEC does not use TLS (or any other kind of transport encryption).
Cool, good news.
The administrative interfaces controlling the implementation might still do.
Grüße, Carsten
(But you should change your DNSSEC password)
/troll (so I don't get lots if mail like my procmail question caused)
That's not DNSSEC that's broken, then.
- Matt
You're correct about that, but everything depends on your level of paranoia.
The bug has a potential to show 64k of memory that may or may not be a part of the TLS/SSL connection*. In that 64k their may be ssh keys, dnssec keys, pictures of cats, or anything else that needs to be safely protected. If something is very important to keep secure and it was on a box that has a TLS/SSL connection then you should regenerate keys for it, but largely this effort would be just in case and not because it's compromised.
* technically it is part of the connection, it's just malloc() and not zeroed so whatever data was in it before was not cleared. If you can be sure all your cat picture applications zero memory on exit and none of them exited uncleanly then this isn't a problem. At high levels of paranoia this isn't really something that you can be sure of though. I'm not even sure if it's done in most crypto apps aside from gpg. OpenSSL is double-faulted here for both not checking the length and not zeroing the memory on malloc**.
** probably making this all up since I haven't done a real look at the library, I'm just going by what I've read on the internet.
I expect we may see more bugs revealed in openssl soon. It's getting lots of scrutiny from this so I expect the code is being audit by everyone and that's good.
> That's not DNSSEC that's broken, then. - Matt
You're correct about that, but everything depends on your level of
paranoia.The bug has a potential to show 64k of memory that may or may not be a
part of the TLS/SSL connection*. In that 64k their may be ssh keys,
dnssec keys, pictures of cats, or anything else that needs to be safely
protected. If something is very important to keep secure and it was on
a box that has a TLS/SSL connection then you should regenerate keys for
it, but largely this effort would be just in case and not because it's
compromised.
That bug has the potential to show what is in them memory of the
process it is connecting to. Note I said process not machine. Now
unless you are using SSL to take to a process that is signing DNSSEC
keys there is no exposure of the private keys.
Named doesn't use ssl. There are however nameservers that do use
ssl to work around broken middle boxes. If they are also signing
zones then there is potential to expose private keys. That said
it also depends on how the process manages the memory it frees.
Named for example overwrites freed memory with 0xde. It also
initialises allocated memory with 0xbe. Doing so help detect use
after free and use of uninitialised structure elements. We want
to catch these sorts of bugs before they get to the internal review
stage.
* technically it is part of the connection, it's just malloc() and not
zeroed so whatever data was in it before was not cleared. If you can be
sure all your cat picture applications zero memory on exit and none of
them exited uncleanly then this isn't a problem. At high levels of
paranoia this isn't really something that you can be sure of though.
I'm not even sure if it's done in most crypto apps aside from gpg.
OpenSSL is double-faulted here for both not checking the length and not
zeroing the memory on malloc**.** probably making this all up since I haven't done a real look at the
library, I'm just going by what I've read on the internet.I expect we may see more bugs revealed in openssl soon. It's getting
lots of scrutiny from this so I expect the code is being audit by
everyone and that's good.
I also expect to see more bugs revealed in MacOS, Windows, FreeBSD and
any other program written by humans or written by programs written by
humans.
Mark
The bug has a potential to show 64k of memory that may or may not be a part
of the TLS/SSL connection*.
It has the potential to show various pieces of memory 64K at a time
that may be related to ANY of the data the OpenSSL library works with
associated with the same process.
In that 64k their may be ssh keys, dnssec keys,
pictures of cats, or anything else that needs to be safely protected. If
Unlikely. For this vuln to be an issue: You need to have a
vulnerable application or service that uses the SSL or TLS protocol
and is sending or receiving those SSH or DNSSEC keys.
something is very important to keep secure and it was on a box that has a
TLS/SSL connection then you should regenerate keys for it, but largely this
In most cases, this would be an unwarranted excessive response. For
instance a SSL vuln affecting apache is not ordinarily an information
leak risk equivalent to a full on root compromise.
Most simply need to address secret credentials that may have been used
by, transmitted, or received through a vulnerable client, server
program, or app running on a vulnerable runtime framework (e.g. PHP
script running on Apache with OpenSSL based mod_ssl, not Apache if
using mod_nss/LibNSS instead of OpenSSL's libssl).
BIND and SSH were unaffected, so... efficient and effective
mitigation would not entail routinely treating these applications as
if they were affected, in the absence of other issues.
* technically it is part of the connection, it's just malloc() and not
zeroed so whatever data was in it before was not cleared. If you can be
sure all your cat picture applications zero memory on exit and none of them
exited uncleanly then this isn't a problem. At high levels of paranoia this
The memory leaked is not arbitrary memory spanning the entire box ---
it is going to be memory belonging to the heap space of the same
process instance, and almost certainly memory buffers which the
OpenSSL library previously allocated for purposes such as
sending/receiving data; therefore has a chance of containing data
previously sent or received -- encrypted or not, such as HTTP headers,
cookies, HTML content, POST forms, etc.
It doesn't matter if your application exited, or if it's still
running, even if it's on the same box. Protected mode and the
secure memory manager on modern OSes makes what you are suggesting
quite infeasible --- different processes cannot directly read each
other's memory, AND on modern OSes, memory pages are always initially
zero'd out some time after allocation to a process -- whenever the
malloc() memory manager needs to call brk() to expand the program's
data size, before the application can actually successfully read
any newly mapped memory pages, the operating system will zero any
existing content of that memory, just as it would do when reading
unallocated sections of a file (instead of showing previous disk
contents).
The vulnerability is related to re-used memory pages within the same process.
It also does not help that OpenSSL has its own wrapper around malloc()
And instead of using the standard system libraries for memory
allocation, apparently uses a high-risk memory allocation policy,
that maximizes the exploitability of vulns like the Heartbeat
extension issue, and prevents security mitigations from working
that would otherwise be effective.....:
see: http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
vv. http://article.gmane.org/gmane.os.openbsd.misc/211963
Generally free() doesn't actually release pages from a program
back to the OS, the
freed memory just becomes available for a later malloc within the same program.
This is also what OpenSSL's homebrewed "malloc" implementation
does ---- buffers not needed anymore are not actually free()'d;
OpenSSL reuses buffers later to satisfy future internal memory
allocation requests, bypassing the system's malloc()/free() the
entire time.
Don't think for one second that using malloc directly would have
saved OpenSSL here. By default malloc does not zero freed memory
it returns. It is a feature that needs to be enabled. If OpenSSL
wanted to zero memory it was returning could have done that itself.
The only difference is that *some* malloc implementations examine
the envionment and change their behaviour based on that.
That OpenSSL used its own memory allocator was a problem does not
stand up to rigourous analysis.
Mark
But it doesn't really matter if you zero out freed memory. Maybe it'll
prevent you from gaining some stale session info and the like. But even if
that were the case, this would still be a serious bug - you're not going to
reread your private key before encrypting each bit of data after all -
that'd just be wasteful.
In other words, this is kind of moot.
Malloc doesn't write over to-be allocated memory, calloc does. Using a
wrapper is hardly unusual or controversial -- malloc can be expensive, and
keeping lookaside list for, say, commonly used and fixed sized blocks is, or
at least used to be, a big performance win.
Far from getting rid of evul wrappers, it seems to me that if they were smart with
their wrappers they'd have wrapper routine for anything vaguely associated
with wire output that zeros the allocated memory.
Mike
Malloc doesn't write over to-be allocated memory, calloc does. Using a
Zero'ing newly allocated memory is not the desired behavior. The
desired behavior is that a segmentation fault occurs, when an
application breaks the rules --- so the bug is detected, instead of
being hidden.
The system free() can be configured to write junk bytes to the entire
freed region, and malloc can be configured to align some allocations
to the end of a page (Which is a default on OpenBSD), and allocate
guard pages to cause a segmentation fault to occur if an attempt is
made to double free() or read past the end of the allocated buffer.
wrapper is hardly unusual or controversial -- malloc can be expensive, and
keeping lookaside list for, say, commonly used and fixed sized blocks is,
Use of the wrapper is both unusual and a bit controversial.
The openssl devs found some neat rope, decided to tie the noose, and
leave it permanently mounted around their neck, just praying some
script kiddie doesn't find the other end of the rope and tie it to
something.
at least used to be, a big performance win.
A very small possible performance win, with an extreme potential
decrease in safety.
Far from getting rid of evul wrappers, it seems to me that if they were
smart with their wrappers they'd have wrapper routine for anything vaguely associated with wire output that zeros the allocated memory.
This doesn't help with reading beyond the allocated memory.
Of course........ if they correctly implement the same security
mitigations that are available from the malloc() library that the
system admin chose to install and link the application against,
then there would have been no security complaint.
Malloc doesn't write over to-be allocated memory, calloc does. Using a
Zero'ing newly allocated memory is not the desired behavior. The
desired behavior is that a segmentation fault occurs, when an
application breaks the rules --- so the bug is detected, instead of
being hidden.
There is no such memory manager. Writes can be caught that way,
reads, not so much.
The system free() can be configured to write junk bytes to the entire
freed region, and malloc can be configured to align some allocations
to the end of a page (Which is a default on OpenBSD), and allocate
guard pages to cause a segmentation fault to occur if an attempt is
made to double free() or read past the end of the allocated buffer.
Yes, I'm a little surprised to hear that such a heavily scrutinized security software don't use those
usual suspect mechanisms to cover their butts. The flip side, though, is that you don't want
to start then *counting* on those CYA mechanisms.
wrapper is hardly unusual or controversial -- malloc can be expensive, and
keeping lookaside list for, say, commonly used and fixed sized blocks is,Use of the wrapper is both unusual and a bit controversial.
Bologna. It's very common. There are lots and lots and lots of reasons to
wrap bare system calls in wrappers. I haven't seen their wrappers in particular
but it's nonsense to say that it's unusual.
The openssl devs found some neat rope, decided to tie the noose, and
leave it permanently mounted around their neck, just praying some
script kiddie doesn't find the other end of the rope and tie it to
something.at least used to be, a big performance win.
A very small possible performance win, with an extreme potential
decrease in safety.
Depending on what you're doing, the difference can be huge. Malloc is a general
purpose allocator with all of the heavyweight machinery general purpose requires.
There's plenty of perfectly valid reasons to do your own memory management.
Mike