On Sat, Apr 12, 2014 at 11:33:36AM -0700, Ben Reser wrote:
> On 4/12/14, 1:30 AM, Thorsten Schöning wrote:
> > Are you sure about that? From my understanding it is necessary that
> > data passes OpenSSL's memory to get retrieved because it implements
> > it's own malloc. I had the feeling that in case of heartbleed only
> > sending passwords over http would have been the "more secure" way
> > because in that case they wouldn't have been retrievable because they
> > never passed memory allocated using OPENSSL_malloc() at all.
>
> No that's not accurate at all. The malloc implementation doesn't matter at
> all, the process can read memory that's allocated by any memory allocator.
> Ultimately all of them have to use the same kernel interfaces to request the
> memory.
>
> The requirements are that the memory be allocated in a larger memory address
> than the memory being used for the heartbeat feature and that it be within 64k
> of that memory space. With memory fragmentation and a lot of requests just
> about anything can be retrieved.
One point raised about malloc is that some malloc implementations
might put junk into freed memory space. So the application would
read junk when reading past the (shorter than specified) payload data.
Instead of a chunk of memory that looks like this:
0................................64k
[hearbeat payload; interesting data]
you'd have something like his:
0..............................64k
[hearbeat payload; junk junk junk]
But since OpenSSL doesn't actually ask the OS to free the memory
before reusing it this mitigation strategy was ineffective.
See http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
So I asked myself the same question about APR pools and found that
APR pool debugging does exactly this. It overwrites pool memory with
a junk byte (0x41) when the pool is cleared or destroyed.
I've now enabled pool debugging by default for OpenBSD's APR packages.
This might cause a performance hit. But in case Subversion or HTTPD ever
have a similar problem it will be mitigated on OpenBSD.
I'm not sure how many SVN/HTTPD deployments run on OpenBSD servers though,
and how much performance matters for them vs mitigation. I'll be watching
for user feedback about this change.
Another point is guard pages, i.e. holes in address space created by
malloc, so the application would segfault when trying to read memory
within the hole.
0...............................................64k
[hearbeat payload] NOT MAPPED [interesting data]
It has been suggested various times that this would have defeated
heartbleed if it were not for OpenSSL's malloc. However, it seems that
in practice this situation didn't occur for the small buffers used by
the heartbeat code, at least not with OpenBSD's malloc. (Again, see the
above link.)
Received on 2014-04-12 23:57:06 CEST