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 586888
To view parent comment, click here.
To read all comments associated with this story, please click here.
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