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 586775
To view parent comment, click here.
To read all comments associated with this story, please click here.
cfgr
Member since:
2009-07-18

Indeed, I was about to post the same link. Some systems have these checks in place but when people actively work around them...

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.

Reply Parent Score: 3

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