On April 11, 2014 at 11:44 dougb@dougbarton.us (Doug Barton) wrote:

On 04/11/2014 11:35 AM, Barry Shein wrote:

...

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

Cool, good news. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

On 11 Apr 2014, at 21:25, Chris Adams <cma@cmadams.net> wrote:

DNSSEC does not use TLS (or any other kind of transport encryption).

The administrative interfaces controlling the implementation might still do. Grüße, Carsten

On 4/11/2014 5:47 PM, Matt Palmer wrote:

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.

On Fri, Apr 11, 2014 at 6:03 PM, Robert Drake <rdrake@direcpath.com> wrote:

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.

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

-- -JH

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. On Apr 12, 2014 2:24 AM, "Mark Andrews" <marka@isc.org> wrote:

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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Sat, Apr 12, 2014 at 9:17 AM, Michael Thomas <mike@mtcc.com> wrote:

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.

Mike -- -JH