Heartbleed bug

Post Reply New Topic

Heartbleed Bug

I don't know if I should be worried about this or not--change passwords? Wait a bit for the owners of various sites to "fix" the problem, whatever that means?

Any advice? I'm still confused.

I'm going to change some passwords, yeah. At least the ones I care about. Before doing that I'd wait until a site is patched, but the major sites should all be patched by now. You can check whether a given site is vulnerable or not at http://filippo.io/Heartbleed/

Ideally, vulnerable sites should really get new SSL certificates, too, but I wouldn't hold my breath for that. The issuer of my SSL certificate has kindly offered to re-issue it for free, though, so I'm going to take them up on that offer.

A quick google gives me the feeling this is something to worry about indeed but as it has been going since 2011 so it might be a bit late to worry for some.

Here's another place to check
https://lastpass.com/heartbleed/

Is this related to the ending of support for Windows XP?

You can check the patch out here.

The code is quite horrible, but it's quite interesting to see.

Thanks, everyone.

I read about it on my Flipboard app this morning. Apparently it's been going on for a little while.

I change my passwords frequently, though, and they're all difficult to guess. I'm not too worried. The only part that bothers me is that they'll be able to hack you as you're putting your password in. I guess... get it wrong on purpose a couple times and then do it right the third time?

No, completely unrelated. Windows XP doesn't use OpenSSL... or open-anything.



Before this bug was fixed - yes, it could have been used to get your password and not only as you were entering it. I don't think getting it wrong a few times would be help if you eventually put in the right one.

Is this related?

I think this might be related

http://xkcd.com/


PS - just look at it

Heartbleed only exposes information in memory, which generally means that only websites that you actually visit can expose your user data.

So, the irony here is that changing your password to a site that you don't regularly visit may actually put you at greater risk if that website is still vulnerable when you change it.

The big risk of this vulnerability, that it has the capability to expose the SSL private key data, is really the problem - and it appears that the risk of exposure, if not practically impossible, is at least extremely difficult.

The wide publicity was meant for system admins like me to understand the gravity of the issue on *our* side and get it patched as quickly as possible - unfortunately, huge awareness is a bit of a double-edged sword and there's been a lot of FUD directed at users.

Glad I asked before overreacting. Thank you.

I'm concerned about an article I read today saying that "some" routers and other home based hardware may also be vulnerable.
Any comments on this sliqua?
http://www.washingtonpost.com/national/heartbleed-could-harm-a-variety-of-systems/2014/04/11/e47a08fc-c1b3-11e3-9ee7-02c1e10a03f0_story.html?tid=pm_pop

It's definitely true, and I know of a handful of my colleagues who have had to patch SSL vpns and such - but generally speaking the only real problem are VPN devices that use SSL. The other big attack vector in that space are management web pages - which, while obviously serious, are generally protected by firewalls to keep the Internet at large out, so the exposure is somewhat minimized.

SOHO routers might have a vulnerable management page, but again that's not something the Internet at large has access to - and to be perfectly frank most people don't change their default admin passwords on those devices anyway so who cares about heartbleed.

As I understand it, the fundamental problem is that those who wrote the OpenSSL code sacrificed security for efficiency. Instead of allocating and freeing memory through operating system calls when desired, they would not free it but would keep the space available for the next time they needed memory that would fit within that space. If they had the memory available, they would then reuse it instead of issuing a new operating systems call to allocate memory. It's much more efficient, but it also means that what was written into that memory remains there.

If they had allocated and deallocated the memory normally, when someone requested that it return more bytes than were necessary, it could still only return whatever was allocated in the request.

I think that the approach they took is not at all bad when security is not an issue. After all, I've been doing something very similar since the early 1990s to increase efficiency. Their problem was that they did it to store sensitive data.

No, that wasn't the case with this bug. The memory was allocated properly, they just read more than they allocated.

As far as I know that's correct.
The reason it went undetected for so long is that it wasn't at all obvious from the code what was happening, it took a company running extensive memory tests on the software to stumble across it.
So no, it wasn't a result of a deliberate action of any sort or even negligence on the part of the coders, but of a coding snafu in which there was a flaw in the code that stayed there for a long time because from a coding perspective it didn't look flawed & it was only through extensive, rigourous testing of the system that the bug came to light.

This is why I'm always telling people that no system with data flowing in & out can be completely secured: the systems are always too big and complicated & heterogeneous for any one person to see the whole picture, and so there will always be holes that can be exploited and people who do so.
Blaming coders, sysadmins, hosting services and/or techs happens when lay people fail to realize the ridiculously complicated nature of the whole setup, how difficult & time comsuming it is to test for all contingencies and how easy it is to inadvertantly make a mistake without ever knowing it or even realizing that it was a mistake because no one else does either, it looks right, and as far as you know it tests right.

That's what happened here, and it's kind of sad to see people pointing fingers for a problem that was really no one's fault.