• Please review our updated Terms and Rules here

The Heartbleed bug...

Stone said:
OK, just what do we need to know about this demon and what, if anything, can/should we do ourselves to lessen its impact?

You can check for a server's vulnerability with this Heartbleed test:

http://filippo.io/Heartbleed/
Click to expand...
Checking that is a good idea before logging in to any SSL secured sites.
Our sysadmin was busy yesterday sorting out OpenSSL on all of our servers. Was a bit of an "OH MY GOD" moment - apparently it's been in the code for two years?
 
I wasn't asking from a webmaster's point of view, just as an ordinary user. I let my hosting service worry about it's servers.
 
Stone said:
I wasn't asking from a webmaster's point of view, just as an ordinary user. I let my hosting service worry about it's servers.
Click to expand...

From the little that I know about it, it appears the https:// could have been compromised on the user end, and that would mean you possibly gave up some passwords and account numbers. Since I'm not a big Yahoo user, hopefully all this bypassed me.
 
Last edited:
On my not very important server I'm actually fine, because ssl is still on 0.9.something on that one.. never upgraded to the 1.0x versions which have the error. And that just after we were scolded by someone higher up for not keeping up with the upgrades.. ha! :)

-Tor
 
Stone said:
Not to burst your bubble but Yahoo wasn't the only site that supplied victims. There were hundreds, maybe thousands of sites. :)
Click to expand...

You didn't, my bubble's still intact. Only cited Yahoo because they were known to have some major problems. I wouldn't go into the panic mode just yet.
 
Agent Orange said:
From the little that I know about it, it appears the http:// could have been compromised on the user end, and that would mean you possibly gave up some passwords and account numbers. Since I'm not a big Yahoo user, hopefully all this bypassed me.
Click to expand...

HTTPS I think you mean :)

What's happening is hackers (now script kiddies - because you can download scripts to do it now) are establishing a secure connection to the server, then requesting a heartbeat. Similar to a PING, you send data and it sends it back. But someone forgot to check the string length matches the number that was sent. So it's quite easy to basically download memory contents from the server - which can easily contain un-encrypted stuff from other peoples connections. Hook that to a parsing script to pull out email addresses, session ids, credit card numbers etc

As an end user you're safe if:

- you do not use vulnerable sites (anyone not using the bad versions of OpenSSL)
- or you do not log in or use them until they're patched
- or hacker was busy doing something else, or missed your piece of allocated memory.

Anyone familiar with C can check out the fix for OpenSSL here: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3
 
SpidersWeb said:
HTTPS I think you mean :)

What's happening is hackers (now script kiddies - because you can download scripts to do it now) are establishing a secure connection to the server, then requesting a heartbeat. Similar to a PING, you send data and it sends it back. But someone forgot to check the string length matches the number that was sent. So it's quite easy to basically download memory contents from the server - which can easily contain un-encrypted stuff from other peoples connections. Hook that to a parsing script to pull out email addresses, session ids, credit card numbers etc

As an end user you're safe if:

- you do not use vulnerable sites (anyone not using the bad versions of OpenSSL)
- or you do not log in or use them until they're patched
- or hacker was busy doing something else, or missed your piece of allocated memory.

Anyone familiar with C can check out the fix for OpenSSL here: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3
Click to expand...

https:// exactly.
 
It's a server side issue, nothing to do from the end user point of view. It's an older bug which ironically has happened in other stuff (I think it was quieted down back then due to a lack of good resolution) but was also a similar issue in the firmware of lots of network cards. You sent massive queries requesting the max packet size it supports and it would pad the packet with contents from recent memory/stack. The end result is you COULD *POSSIBLY* get some unencrypted or useful data, or just encrypted data which would be useless or random memory which also may or may not be useless.

It does appear that patches are already out for multiple vendors using openssl code. Here's the bug announcement (I think already referenced in the thread). It looks like if you're on openssl v1.0.1 you'll be vulnerable but 1.0.1g mitigates the issue. The part that has people concerned is appliances and other third party code that was compiled and used the vulnerable openssl code, making it more difficult for admins to know if they're vulnerable.

Here's a link to the network card/driver memory leak issue which was quite similar. This is more so a product announcement (Etherleak) to expose that issue vs the bug report.
 
Last edited:
Most of us probably already know this but since it's such a large scale issue (number of opensource apps that use openssl affected) they're trying to keep tabs on what vendor products are affected on the official CVE-2014-0160 article. Anything compiled with or using openssl 1.0.1 up until 1.0.1g is affected. (Upgrading to 1.0.1g is the fix).

Also old news now but I thought it was funny that xkcd jumped on it with a fairly easy and straight forward description.
 
You must log in or register to reply here.
Back
Top