http://techcrunch.com/2014/04/07/massive-security-bug-in-openssl-could-effect-a-huge-chunk-of-the-internet/

If you haven't seen it yet, here it is. It's been known for about a week now.

From the article:

The exploit relies on a bug in the implementation of OpenSSL’s “heartbeat” feature, hence the “Heartbleed” name. Security firm Codenomicon has written an in-depth breakdown of the Heartbleed bug here.

To quote their findings:

We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

It is worth noting that this specific buffer overrun bug is not new and is actually several months old, it is thus conceivable some companies which-will-not-be-named have been exploiting it covertly for a very, very long time (even more insidious, this type of server activity does not show up in your server logs unless you are logging literally everything that's going on, and even then it doesn't look suspect if you are not aware of the bug's existence). No tinfoil hats here, but it is important to keep it in mind as a very real possibility.

A major contributing factor has been that TLS versions 1.1 and 1.2 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due to earlier attacks against TLS (such as the BEAST).

Coincidence? :)

this specific buffer overrun bug is not new and is actually several months old,

Over 2 years old, in fact.

Quoting the linked article (emphasis mine):

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

Been reading some of the comments about it on teh intarwebz. A lot of people are missing the point that with a hypothetical .NET or Java program, in a large percentage of cases all you need to do is patch the runtime and every program becomes defended, without needing individual recompilation/reinstallation.

Been reading some of the comments about it on teh intarwebz. A lot of people are missing the point that with a hypothetical .NET or Java program, in a large percentage of cases all you need to do is patch the runtime and every program becomes defended, without needing individual recompilation/reinstallation.

Updating the run-time environment won't help if the bug is in your own code... Or am I missing something? Updating the run-time environment will only fix bugs in it, right? Considering you don't need a run-time environment for a language like C there can hardly be bugs in it... A language like C is also generally faster than managed languages and you should know that that's pretty important on servers. A performance gain of 0,001% will mean 0,001% less servers and costs.

Updating the run-time environment won't help if the bug is in your own code... Or am I missing something? Updating the run-time environment will only fix bugs in it, right?

Exactly, and that's why I didn't say "all cases". But consider a classic buffer overrun. Now, in .NET you're possibly using a MemoryStream, and a bug that gives ownership of the system is highly unlikely to be in your own code: the overrun is going to be in the MemoryStream object, which lives inside the runtime. So patch that and you've no longer got a buffer overrun.

In general managed languages are safer: the worst that they can do is usually just crash themselves. You do make a valid point about performance though, but that's a tradeoff that each person needs to evaluate for themselves (although given the amount of interpreted code that's out there I'm not sure it's something that many people haven't already made a decision on).

Been reading some of the comments about it on teh intarwebz. A lot of people are missing the point that with a hypothetical .NET or Java program, in a large percentage of cases all you need to do is patch the runtime and every program becomes defended, without needing individual recompilation/reinstallation.

There's a much more interesting angle to the problem. While it's true that managed languages are much safer, native code is not entirely defenseless. We have a variety of checked libraries to lean on. Or rather we would have, if OpenSSL hadn't thoroughly circumvented them and used a buggy custom allocator:

http://article.gmane.org/gmane.os.openbsd.misc/211963

http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

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

Which caused the bug to survive despite attempts by the underlying C runtimes to deal with these sorts of problems.

http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

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

That's horrifying.

http://article.gmane.org/gmane.os.openbsd.misc/211963

This one is worse because it gives the reason why:

On some platforms, malloc() performance is bad enough...

This one just positively stinks of developer arrogance. There's a lesson in this for anyone who thinks they can do better. The conclusion says it all:

OpenSSL is not developed by a responsible team.