Date: Wed, 9 Apr 2014 22:08:51 +0100
From: Aidan Thornton <makosoft@...il.com>
To: Jeremy Voorhis <jvoorhis@...il.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] heartbleed OpenSSL bug CVE-2014-0160

On Wed, Apr 9, 2014 at 8:52 PM, Jeremy Voorhis <jvoorhis@...il.com> wrote:
> I just read an article titled "Why heartbleed doesn't leak the private key"
> and the claim seems irresponsible and overly broad. Can anyone comment on
> his analysis?
>
> http://blog.erratasec.com/2014/04/why-heartbleed-doesnt-leak-private-key.html#.U0WjNK1dWBg

Pretty sure it's basically wrong about everything. "memory containing
the private key is never freed, and hence allocated heartbleed buffers
can never contain it"? What about all the buffers that are only needed
when loading the key from .pem format and can be freed afterwards?
What's more, even if no memory containing the private key was ever
freed that's still not necessarily an obstacle - if we can get our
buffer allocated earlier in RAM than the private key, OpenSSL is quite
happy to copy data from past the end of the buffer. (The buffer length
is - so far as I can tell, OpenSSL's hard to follow - the maximum TLS
record length of 16KiB plus a few hundred bytes for crypto overhead.
OpenSSL will send us up to 64KiB-1 from it, way past the buffer end;
this doesn't comply with the specification, but neither does failing
to check the length in the first place.)

To be frank it's a rather irresponsible blog post. Also, I've obtained
the private key (unreliably) from a local copy of Apache on Linux and
it actually seems to be less effective with a freshly-started copy of
Apache for whatever reason.

Aidan

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists