Heartbleed - Security leak in OpenSSL

Started by
20 comments, last by Krohm 10 years ago
managed languages

That leaves the possibility out of consideration that, despite what the author says, the exploit was placed deliberately. It is easily conceivable that if Mr. Seggelmann hasn't been "working for an espionage agency", he still may have been blackmailed by one. It's not like you would know if that had happened.

He sure wouldn't be telling Die Welt anything but "it was not deliberate" if e.g. US governmental murderers threatened to kill his wife if he didn't plant a backdoor.

To me, this doesn't look much like an accident, though of course it might be. It's funny that he's assigning the length extracted from the request to a dedicated variable before doing the memcpy, though. Which suggests that he had at least looked at that variable more than just once when typing it down.

But what's more important in raising suspicion is that the entire feature is kind of useless, and its implementation is also somewhat superfluous. Assuming the protocol works as intended, you do not need a heartbeat in the first place. Either TCP reports an destination unreachable error when you send something, or your packets make it through and you get an answer. Presto, the other end is alive. And assuming the protocol is secure, the answer is of such a kind that you can read it, and only the other end could have created it, so no malicious third party could pretend the other end is alive when it isn't (on the other hand, if the crypto doesn't work, then heartbeat won't work any better either).

If you need to know that the other side is still alive (but... why? this is like querying the current CPU that a thread is running on), sending and echoing a random number the length (or less than) of one block would be perfectly sufficient. Assuming the crypto protocol works, nobody but the other end could echo the correct block. Hash it to further "randomize" the traffic if you're super paranoid (though block chaining will hide the pattern anyway). The only observable information, if anything, is "exchanged two blocks of data", which may really be anything.

Assuming that a heartbeat is really useful and important, there is absolutely no need for arbitrarily-sized user-supplied payloads up to 64kB, which is the very source of the exploit. So, why is there a provision for that in the first place? Only one anser seems plausible.

Advertisement

managed languages


That leaves the possibility out of consideration that, despite what the author says, the exploit was placed deliberately. It is easily conceivable that if Mr. Seggelmann hasn't been "working for an espionage agency", he still may have been blackmailed by one.
As crazy as it seems, with all the recent revelations of NSA/UKUSA/five-eyes capabilities and activities, including other instances of them deliberately sabotaging SSL, this seems like a very plausible explanation :(

What I find even more concerning is that this bug was detected and submitted 4 years ago, but was not addressed until 14/04/07.

"I would try to find halo source code by bungie best fps engine ever created, u see why call of duty loses speed due to its detail." -- GettingNifty

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.

Performance is highly overrated. Stability, scalability, security, developer productivity (aka time to launch) etc are usually much more important.

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


Wow! I had already wondered, if the interesting stuff wouldn't be spread out more, but if you write your own allocator to keep everything close together, that 64KB window can be very revealing.


I actually looked at the offending part in the sourcecode and what struck me most was that this didn't show up in some code review. This is not a very elusive bug that works around several corners. In fact, it only spans 25 lines of code. There is control data comming in through the socket and it's not verified. This is the most important and most simple rule: Don't trust anything the other end tells you. And yet, in a software package with the primary goal of security, a value is extracted from a network packet and only 25 lines later stuffed into memcpy without any verification.
Actually, is the underhanded c contest still being held? Because I believe we have a winner!

Just a heads up, it has now been demonstrated that Heartbleed CAN leak the SSL private key.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

Just a heads up, it has now been demonstrated that Heartbleed CAN leak the SSL private key.

so...i get an security error if i try to connect to that link.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

Just a heads up, it has now been demonstrated that Heartbleed CAN leak the SSL private key.

so...i get an security error if i try to connect to that link.

Yeah, seems the certificate's been revoked.

Just a heads up, it has now been demonstrated that Heartbleed CAN leak the SSL private key.

so...i get an security error if i try to connect to that link.

Yeah, seems the certificate's been revoked.

https://blog.cloudflare.com/certificate-revocation-and-heartbleed

-~-The Cow of Darkness-~-

This topic is closed to new replies.

Advertisement