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 586780
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

Soulbender,

Having profiled the standard malloc myself on linux+gcc, I actually believe both points are correct. There are very real performance gains to be had by abstracting the allocator behind a caching mechanism, especially in thread local storage.


For a project like OpenSSL, which is both performance sensitive and security sensitive, there can be divergent goals. Optimizing malloc wouldn't ordinarily cause bugs on it's own, however if it eliminated some of the sanity checks, it might allow some alloc/free/memory leak bugs elsewhere in code to go unnoticed and keep running instead of crashing.

In this case the ideal solution seems to be to compile these optimizations conditionally, and run both versions through a comprehensive barrage of unit test cases. I don't know much about OpenSSL's testing procedures, but the source code does reveal that the caching can be enabled/disabled conditionally by defining "OPENSSL_NO_BUF_FREELISTS", so it's possible OpenSSL is already doing the right thing.

This reminds me of the range checking directive in pascal programs {$R+} {$R-}. The idea was a good one, if you develop your program successfully with range checking turned on and it's working, then that increases the confidence the code will be correct even with range checking turned off. The main caveat is that you don't get any assurances for code paths that were not adequately tested when range checking was on.

Edited 2014-04-09 18:22 UTC

Reply Parent Score: 3

Soulbender Member since:
2005-08-18

which is both performance sensitive and security sensitive, there can be divergent goals.


If your project is OpenSSL your first and most important priority is security. If some obscure platform have a shitty malloc you selectively fix it only there, you don't make a nasty hack solution and apply it to all platforms.


so it's possible OpenSSL is already doing the right thing.


No, you can't disable it because openssl won't work then.
It doesn't exactly flatter the OpenSSL team that apparently no-one gave a shit about the bug report filed against this.

Edited 2014-04-11 04:33 UTC

Reply Parent Score: 3

Alfman Member since:
2011-01-28

Soulbender,

If your project is OpenSSL your first and most important priority is security. If some obscure platform have a shitty malloc you selectively fix it only there, you don't make a nasty hack solution and apply it to all platforms.


I don't think it's such a hack in the first place, but regardless of that the point is kind of mute in terms of security because a) malloc guard pages are not used on production servers, and b) a variant of the exploit might still be feasible with the malloc guard enabled anyways.

Quoting the openbsd researchers from cfgr's link earlier: "malloc guarding (world is not ready for this)". The reasoning can be extrapolated from the rest of the paper: "Don't want to break normal/expected behaviors. But maybe change anything else which makes exploits hard/impossible. As long as the performance cost is insignificant/very low...".




No, you can't disable it because openssl won't work then.


Well, it didn't work because there was another bug (which cfgr also pointed out), however in principal there's no reason it won't work. I think it's a good idea to test with guard pages, and clearly OpenSSL was not tested this way. I will learn from this and make changes to my own testing procedures. However I still think it is a stretch to suggest this particular vulnerability would have been caught if not for freelists, but of course that's just my opinion.

Edited 2014-04-11 06:05 UTC

Reply Parent Score: 2