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