Linked by Thom Holwerda on Tue 8th Apr 2014 22:06 UTC
Privacy, Security, Encryption

Heartbleed, a long-undiscovered bug in cryptographic software called OpenSSL that secures Web communications, may have left roughly two-thirds of the Web vulnerable to eavesdropping for the past two years. Heartbleed isn't your garden-variety vulnerability, so here's a quick guide to what it is, why it's so serious, and what you can do to keep your data safe.

Serious.

Thread beginning with comment 586850
To view parent comment, click here.
To read all comments associated with this story, please click here.
cfgr
Member since:
2009-07-18

Conceptually sure, but in this particular case it wouldn't have helped. The vulnerability didn't corrupt memory such that free could have detected it, it simply wrote memory out to a socket.

Why not? For example, the OpenBSD malloc (with the G option enabled) may place guards around each allocated block which would prevent this exploit from reading outside the allocated memory within the same application as it would trigger one of the guards and cause a segfault.

The problem here is that rather than using the system malloc/free, it keeps its memory cached to reuse it. Hence why the guards are ineffective.

Edited 2014-04-10 14:07 UTC

Reply Parent Score: 3

Alfman Member since:
2011-01-28

cfgr,

Yes, you could use the mmu for mallocs instead of using a local/caching allocator, but MMUs only work on page sizes (ie 4k and up). That results in lots of wasted memory and probably poor cache utilization too. This is fine for debugging, but on a production system...the negatives are a show stopper, IMHO. Can you name any performance critical production systems that enable this by default?

In any case, if it's important to you, then it already looks like you can generate a version of openssl with the malloc cache disabled.

The reason I don't think it would have helped is because it would not have come up on any testing/debugging build. The normal test cases wouldn't have triggered the conditions. The best shot they'd have to catch bugs like this might be with an input fuzzer (in conjunction with multiple safety checks like malloc page guards). I suspect moving forward this is exactly what they'll do, which they arguably should have been doing all along.

Reply Parent Score: 3

cfgr Member since:
2009-07-18

The impact of malloc guarding on the performance is minimal (according to the OpenBSD developers*), however, there's a lot of software that misbehaves and would crash, which is why it's disabled by default.

In any case, if it's important to you, then it already looks like you can generate a version of openssl with the malloc cache disabled.

The post on the mailing list mentions that it doesn't seem to be that easy. Also, here's a blog post of his, it seems to be worse than previously thought:

http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-re...

The reason I don't think it would have helped is because it would not have come up on any testing/debugging build.

Mayhaps, but an attack would have crashed the service at once, rather than quietly leaking keys for two years.


[*] http://download.cdn.yandex.net.cache-default05d.cdn.yandex.net/comp...

Edited 2014-04-10 18:50 UTC

Reply Parent Score: 3