Jump to content

  • Log In with Google      Sign In   
  • Create Account


Heartbleed - Security leak in OpenSSL


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
22 replies to this topic

#1 TheComet   Members   -  Reputation: 1382

Posted 10 April 2014 - 06:45 AM

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.


YOUR_OPINION >/dev/null


Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8133

Posted 10 April 2014 - 06:59 AM

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.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Erik Rufelt   Crossbones+   -  Reputation: 3030

Posted 10 April 2014 - 07:02 AM

 

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? :)



#4 Lactose!   GDNet+   -  Reputation: 2416

Posted 10 April 2014 - 07:16 AM


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.



#5 mhagain   Crossbones+   -  Reputation: 7413

Posted 10 April 2014 - 01:57 PM

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.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#6 ProtectedMode   Members   -  Reputation: 1072

Posted 10 April 2014 - 02:11 PM

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.



#7 mhagain   Crossbones+   -  Reputation: 7413

Posted 10 April 2014 - 02:23 PM

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).


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#8 Promit   Moderators   -  Reputation: 6061

Posted 10 April 2014 - 02:33 PM

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.



#9 Chris_F   Members   -  Reputation: 1937

Posted 10 April 2014 - 02:53 PM


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

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

 

That's horrifying.



#10 mhagain   Crossbones+   -  Reputation: 7413

Posted 10 April 2014 - 03:47 PM

 

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.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#11 samoth   Crossbones+   -  Reputation: 4495

Posted 11 April 2014 - 04:08 AM

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.


Edited by samoth, 11 April 2014 - 04:08 AM.


#12 Hodgman   Moderators   -  Reputation: 27466

Posted 11 April 2014 - 04:40 AM

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 :(

#13 TheComet   Members   -  Reputation: 1382

Posted 11 April 2014 - 05:09 AM

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.


YOUR_OPINION >/dev/null


#14 DvDmanDT   Members   -  Reputation: 745

Posted 11 April 2014 - 06:06 AM

 

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.



#15 Ohforf sake   Members   -  Reputation: 1441

Posted 12 April 2014 - 03:33 PM

[...]
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.

#16 Ohforf sake   Members   -  Reputation: 1441

Posted 12 April 2014 - 03:57 PM

Actually, is the underhanded c contest still being held? Because I believe we have a winner!

#17 Promit   Moderators   -  Reputation: 6061

Posted 12 April 2014 - 05:14 PM

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



#18 slicer4ever   Crossbones+   -  Reputation: 3173

Posted 12 April 2014 - 09:00 PM

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.

#19 Ectara   Crossbones+   -  Reputation: 2763

Posted 12 April 2014 - 11:30 PM

 

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.



#20 cowsarenotevil   Crossbones+   -  Reputation: 1939

Posted 13 April 2014 - 02:22 AM

 

 

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-~-




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS