Heartbleed Bug: Serious Hole in Internet Security

[PowerEngineer]

There's already a thread started in the security forum about this bug, but I'm thinking that a posting here in OT will alert more people to the threat. Anyone who does on-line banking or purchasing (and who doesn't?) should pay attention to this.

http://money.cnn.com/2014/04/09/technology/security/heartbleed-bug/index.html?iid=s_mpm

 

[lozina]

They call it a bug, but it's probably a "feature" designed by NSA

 

[spidey07]

This is a REALLY big deal. An attacker can get the root cert's private key rendering SSL and anything cert based encryption worthless. I won't be doing any online banking for a while.

If they get the private key not only can they decrypt your stuff, they can issue bogus certs that your browser would see as valid and trust.

 

[Brian Stirling]

They call it a bug, but it's probably a "feature" designed by NSA

Bingo!

And, looking forward, I expect hackers will look more closely at the tools the NSA has provided for "net security" and be looking for backdoor access. I would not be shocked at all if intentional vulnerabilities wind up costing you and me billions in the long run.

Happy days indeed...


Brian

 

[alkemyst]

I have a NDA, but there are a few other exploits that have been in the wild for years now and just being discovered.

I'd recommend everyone get a password 'vault' and generate secure passwords unique to any site.

 

[Lean L]

So I am not as familiar with encryption as I pretend to be.

This is not a fault with SSL but rather with the library that handles ssl that apache and many servers use?

So... Apache <=> openssl <=> raw data ?

Does openssh use openssl libraries?

SSH is not affected correct?

 

[Jeff7]

This is a REALLY big deal. An attacker can get the root cert's private key rendering SSL and anything cert based encryption worthless. I won't be doing any online banking for a while.

If they get the private key not only can they decrypt your stuff, they can issue bogus certs that your browser would see as valid and trust.

Don't worry, someone else will be doing your online banking for you.



It's an impressive little "oopsie" there.
Direct access to the server's memory.

"Hey, this is a heartbeat packet, just to let you know I'm still here. Oh, and while you're there, please access memory address 0x29A94F43 and read me back whatever's stored in it.

"It's funny, this is the 234,523,587th time I've had that same kind of data request in just this past day. Oh well, there's no rule against it, so here you go!"

 

[monkeydelmagico]

"It's funny, this is the 234,523,587th time I've had that same kind of data request in just this past day. Oh well, there's no rule against it, so here you go!"

So much for heuristics. What's worse is people flocking to change their passwords on systems that haven't been fixed.

 

[Markbnj]

Bingo!

And, looking forward, I expect hackers will look more closely at the tools the NSA has provided for "net security" and be looking for backdoor access. I would not be shocked at all if intentional vulnerabilities wind up costing you and me billions in the long run.

Happy days indeed...


Brian

As dramatic as the possibility is, the reality is that the bug is rather mundane, and they already know exactly where it came from and what programmer introduced it. A UK-based developer was adding a feature and decided to roll his own memory dealloc rather than handing the block back to free. The library routine had code in place that would have seg faulted on his error, but his own code did not.

The bug is very serious, category 11 as Schneier put it, because everyone has to assume everything was taken. The reality is probably that very little was taken. Hunting for keys by grabbing random 64k blocks isn't all that efficient, given that there may be more than a half-million or so such blocks available in a typical server (rough estimate).

Still, doesn't matter much. We all have to respond as if every try was successful.

 

[Markbnj]

So I am not as familiar with encryption as I pretend to be.

This is not a fault with SSL but rather with the library that handles ssl that apache and many servers use?

So... Apache <=> openssl <=> raw data ?

Does openssh use openssl libraries?

SSH is not affected correct?

SSH is not affected, as openSSH is a different (and from what I hear, better run) project.

 

[palswim]

There's already a thread started in the security forum about this bug, but I'm thinking that a posting here in OT will alert more people to the threat. Anyone who does on-line banking or purchasing (and who doesn't?) should pay attention to this.

http://money.cnn.com/2014/04/09/technology/security/heartbleed-bug/index.html?iid=s_mpm

We talking about this thread, or another one?

 

[Crusty]

So I am not as familiar with encryption as I pretend to be.

This is not a fault with SSL but rather with the library that handles ssl that apache and many servers use?

So... Apache <=> openssl <=> raw data ?

Does openssh use openssl libraries?

SSH is not affected correct?

OpenSSH uses OpenSSL for key storage and management, not for transport encryption. That's why it is not vulnerable.

The bug basically allowed someone to craft a Heartbeat message, lie about how large the 'payload' is which would fool OpenSSL into giving up sensitive memory.

It's all due to a poorly thought-out custom memory allocator.

You basically say as an attacker, the payload is 64K, but only provide 1byte of data in your heartbeat packet. OpenSSL creates 64K of memory to store the payload, but only 1byte of it is actually copied into it and overwritten. Because of the bad memory allocator, this would leave around 65355 bytes worth of memory that were never zeroed out. Further, due to the way the memory allocator works, most often this memory being leaked was something that was most recently used and freed up by OpenSSL. This could be any data that is being encrypted/decrypted or it could actually be the keys being used to perform the encryption.

 

[spidey07]

I'm calling my banks and having them disable online stuff for the time being.

The worst part is if private keys have been compromised then they'll have to redo the entire cert chain - bad mojo and not easy to do.

 

[spidey07]

Here's a site that will test if the site is vulnerable. But this can't tell you if the site has been compromised or any information retrieved previously.

http://filippo.io/Heartbleed/

 

[Hugo Drax]

As dramatic as the possibility is, the reality is that the bug is rather mundane, and they already know exactly where it came from and what programmer introduced it. A UK-based developer was adding a feature and decided to roll his own memory dealloc rather than handing the block back to free. The library routine had code in place that would have seg faulted on his error, but his own code did not.

The bug is very serious, category 11 as Schneier put it, because everyone has to assume everything was taken. The reality is probably that very little was taken. Hunting for keys by grabbing random 64k blocks isn't all that efficient, given that there may be more than a half-million or so such blocks available in a typical server (rough estimate).

Still, doesn't matter much. We all have to respond as if every try was successful.

Well they had 2 years to try it out.

 

[Crusty]

Here's a site that will test if the site is vulnerable. But this can't tell you if the site has been compromised or any information retrieved previously.

http://filippo.io/Heartbleed/

Nobody can tell you that, that's what's scary about it. You simply don't know you've been compromised, so it is best to assume you were.

 

[spidey07]

Nobody can tell you that, that's what's scary about it. You simply don't know you've been compromised, so it is best to assume you were.

Yes.

1) Check if your important sites are vulnerable
2) Change passwords

Ideally the sites would re-issue their certs. That wouldn't matter though if the root's private key was compromised. The root's private key should never be obtained though because any real cert authority is not going to have the roots even powered up let alone connected to a network.

If they got a hold of the key for the cert on the box/load balancer then they could decrypt your traffic or setup a spoof/man in the middle attack at wifi hotspots and the site would look totally legit to the user.

I read that F5 is vulnerable which load balances a heavy percentage of the Internets larger sites.

 

[mrjminer]

OpenSSH uses OpenSSL for key storage and management, not for transport encryption. That's why it is not vulnerable.

The bug basically allowed someone to craft a Heartbeat message, lie about how large the 'payload' is which would fool OpenSSL into giving up sensitive memory.

It's all due to a poorly thought-out custom memory allocator.

You basically say as an attacker, the payload is 64K, but only provide 1byte of data in your heartbeat packet. OpenSSL creates 64K of memory to store the payload, but only 1byte of it is actually copied into it and overwritten. Because of the bad memory allocator, this would leave around 65355 bytes worth of memory that were never zeroed out. Further, due to the way the memory allocator works, most often this memory being leaked was something that was most recently used and freed up by OpenSSL. This could be any data that is being encrypted/decrypted or it could actually be the keys being used to perform the encryption.

I know I've heard of a similar bug with something else large a few years go... can't recall. Or maybe it was just a warning I came across somewhere when researching some coding. Regardless, whatever it was definitely wasn't an issue nearly this big, though.

Seems like you would have to be a complete retard to have this bug in your code or you would have to do it intentionally. I don't think even the dumbest people I know would write code that sent raw, unfiltered contents of xxxxx block when prompted with any amount of meaningless data.

I guess it could have just been a quick fix that he forgot to go back and do the right way. It's just surprising and alarming that it's been around this long.

 

[Crusty]

I know I've heard of a similar bug with something else large a few years go... can't recall. Or maybe it was just a warning I came across somewhere when researching some coding. Regardless, whatever it was definitely wasn't an issue nearly this big, though.

Seems like you would have to be a complete retard to have this bug in your code or you would have to do it intentionally. I don't think even the dumbest people I know would write code that sent raw, unfiltered contents of xxxxx block when prompted with any amount of meaningless data.

I guess it could have just been a quick fix that he forgot to go back and do the right way. It's just surprising and alarming that it's been around this long.

Well, without the custom memory allocator, the actual coding bug, when introduced two years ago, would have caused at the bare minimum an exception if not a full on segfault during runtime. So it was the compounding of mistakes that led to the bug being in the wild.

The guy that wrote the Heartbeat code also wrote the RFC for it, go figure. So it's not like there was anybody else around at the time that would be even capable of finding the bug through a code audit.

 

[mrjminer]

Well, without the custom memory allocator, the actual coding bug, when introduced two years ago, would have caused at the bare minimum an exception if not a full on segfault during runtime. So it was the compounding of mistakes that led to the bug being in the wild.

The guy that wrote the Heartbeat code also wrote the RFC for it, go figure. So it's not like there was anybody else around at the time that would be even capable of finding the bug through a code audit.

Ah, I missed that first part about it being some sort of component/module within a greater system. Also makes more sense now how they missed it with the RFC info. You, sir, have the wealth of knowledge

 

[Crusty]

Ah, I missed that first part about it being some sort of component/module within a greater system. Also makes more sense now how they missed it with the RFC info. You, sir, have the wealth of knowledge

Here are links to the commits to OpenSSL that introduce the bug and then fixes it.

https://github.com/openssl/openssl/commit/4817504d069b4c5082161b02a22116ad75f822b1

https://github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead

To fix the bug they basically check the actual length of the data received to ensure that it is at least the size that was reported. If it is not large enough, the entire request is ignored it looks like.

It really all comes down to this, don't trust user input.

The initial implementation assumed that the client would never lie about the size of the payload, which is just incredibly naive....

 

[mrjminer]

Here are links to the commits to OpenSSL that introduce the bug and then fixes it.

https://github.com/openssl/openssl/commit/4817504d069b4c5082161b02a22116ad75f822b1

https://github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead

To fix the bug they basically check the actual length of the data received to ensure that it is at least the size that was reported. If it is not large enough, the entire request is ignored it looks like.

It really all comes down to this, don't trust user input.

The initial implementation assumed that the client would never lie about the size of the payload, which is just incredibly naive....

Ah, yes, the ole' "trust the user" (intentionally or through naivety) fallacy

Good to know this info. Going to have to forward this over to my friend with some OpenSSL stuff running. Thanks

 

[Jeff7]

Ah, yes, the ole' "trust the user" (intentionally or through naivety) fallacy

Good to know this info. Going to have to forward this over to my friend with some OpenSSL stuff running. Thanks

"Please enter your age."


¤&#9579;þ


"Beginning memory dump."

 

[fjmeat]

http://heartbleed.com/

 

[ussfletcher]

By the way you should all be aware that the mitigation for this bug takes quite a bit of effort on the part of administrators. Thus, only expect large companies to actually address the issue in the near term, possibly ever.