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

cfgr,

If someone really wants to shoot himself in the foot, there's only so much you can do to stop him. Unfortunately they shot in pretty much everyone's foot with this one. Hopefully this will cause them to reconsider some practices.


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.

clint might have detected it though.

If your goal is to discourage coders from shooting their own feet, then C is probably not the best choice as a language. Not many languages are as notorious as C for things like buffer/stack overruns.

Reply Parent Score: 3

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