DNSSEC?

Sat Apr 12 05:45:20 UTC 2014

On Fri, Apr 11, 2014 at 6:03 PM, Robert Drake <rdrake at 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