Heartbleed vuln under ACTIVE ATTACK as hackers map soft spots

Hackers are posting massive lists of domains vulnerable to the infamous Heartbleed bug, security researchers warn. The warning comes amidst other evidence that the vulnerability is under active attack from hackers possibly based in China and elsewhere, targeting financial services firms among others. Fraud protection firm …

[Anonymous Coward]

And pray that nobody used a web admin interface

...or that if they did then their SSH password isn't the same, or that if they aren't 100% sure that this has always been true for the past two years then rebuild the server at the same time as changing certificates. Otherwise the paranoid fear remains that someone has quietly owned the server and no longer needs the old passwords, private key, or this vulnerability.

[Anonymous Bullard]

Re: And pray that nobody used a web admin interface

The SSH password will not be exposed, as it is handled in a different process to the webserver.

Also, actually getting the private key is unlikely - as the bug only exposes recently free-d memory. So, unless the private key is being read+free-d for each request, then the odds are pretty slim - but there's still a chance!

Realistically, the only sensitive data would be the traffic in plaintext (containing session ids, application passwords, etc)

Try it yourself: https://www.cloudflarechallenge.com/heartbleed

[I'm not trying to play it down... just keeping it real]

[Alistair]

Re: And pray that nobody used a web admin interface

Absolute kudo's to Cloudflare for making the point that its just plain not internet armageddon.

The data returned are randomized based on where there is free memory - so -- yes its POSSIBLE to get critical data. But -- 64K blocks on a machine with how much memory + where is the free memory.

Most of the stuff you're likely to get back is garbage. And good luck figuring out just what it was you got back.

[Anonymous Coward]

Re: And pray that nobody used a web admin interface

in fact, Cloudflare even tried it themselves (and they know exactly what to look for - they already have the key)

blog.cloudflare.com [a warning to MS devs + windows users: it might be too technical for you]

[Steve K]

Re: And pray that nobody used a web admin interface

Twat

[Anonymous Coward]

Re: a warning to MS devs + windows users

You aren't vulnerable, only the pompous freetards with their blinkered insistence that they are more secure are. Yeah, I'd crow about that if I was you.

Prick..

[BlinkenLights]

Re: And pray that nobody used a web admin interface

A warning to everyone - don't respond to the trolling ignorant f*ckwit.

[Anonymous Coward]

Re: And pray that nobody used a web admin interface

"a warning to MS devs + windows users: it might be too technical for you"

Luckily they don't have to worry about this hole on any server running Microsoft software....

[Dan 55]

Re: And pray that nobody used a web admin interface

Well... two people have found the key so far. One with 2.5 million requests and another with 100,000 requests.

[Simon Harris]

xkcd

Best explanation I've seen so far!

[poopypants]

Obviously open source per se is not sufficient to avoid these problems. I would suggest that rigorous procedures and accountability are also required - things not normally associated with volunteer work.

[Anonymous Coward]

Demand a full refund! I received mine, without even asking.

Actually, if it wasn't open source, then would this bug even have been publicly exposed?

[Anonymous Coward]

"Actually, if it wasn't open source, then would this bug even have been publicly exposed?"

It probably wouldn't have happened in the first place. There would have been actual code reviews, code analysis, testing etc etc.

Even if it did, because of the competition fostered by closed-source companies between each other, the surface of the Internet exposed would have been much smaller and there would be greater accountability on the part of the vendor.

With F/OSS you get a common, part-baked solution applied everywhere and then hung-out to dry.

[Anonymous Coward]

It probably wouldn't have happened in the first place. There would have been actual code reviews, code analysis, testing etc etc.

Of course, all closed projects have code review/analysis! If only they made a ClosedSSL, then it would have been completely bug free...

tosser.

[Nick Ryan]

It probably wouldn't have happened in the first place. There would have been actual code reviews, code analysis, testing etc etc.

Nice troll :) Commercial organisations are much lazier about their validation and testing and code reviews because a) it costs too much and b) nobody else will see the code therefore problems are hidden through obscurity.

This is a functional programming error, a memory bounds checker would not pick this up because there no memory violations taking place. Unless an independent code reviewer thought about the case in enough detail and thoroughly dismantled the code it would be missed. This is a small function of a rather large code base.

On the other hand, this function was evidently not tested to destruction through putting the full combination of extreme values into it.

[Anonymous Coward]

"It probably wouldn't have happened in the first place. There would have been actual code reviews, code analysis, testing etc etc."

I'm so glad Adobe and Microsoft are professional organizations that have code reviews etc, and don't need frequent ( say monthly on a Tuesday) bug-fixes for severe problems.

[Anonymous Coward]

"need frequent ( say monthly on a Tuesday) bug-fixes for severe problems."

Erm - you realise that those fixes are far less frequent than equivalent Open Source OSs like Red Hat or SUSE? And that there are an order of magnitude of so fewer of them for Microsoft OSs? And that on average Microsoft OSs have fewer days at risk?

[Anonymous Coward]

Yeah, well..

...you can prove anything with facts!

[Mystic Megabyte]

"things not normally associated with volunteer work."

Like all those Doctors who volunteer to work in disaster areas.

[Sir Runcible Spoon]

Worst thing you can do right now

Is log in and change your password.

Personally I'm staying well away until they are reported as being patched.

Anyone have a handy site that's listing the major sites and their patch status?

[Anonymous Coward]

Re: Worst thing you can do right now

Did you try reading the article? IVPN.net

[Paul Wells]

Re: Worst thing you can do right now

IVPN.net is probably blocked at a lot of places.

[Eguro]

Re: Worst thing you can do right now

I'm confused about the whole thing.

For instance:

IVPN says Netflix wasn't affected, so doesn't need patching and you don't need a password change.

Mashable says Netflix was affected, has been patched, and thus you need a password change*

There's a fancy quote and everything on the Mashable, but I can't really tell if it's legit. The problem now becomes who do you trust in this regard? I can't find any statement made by Netflix regarding Heartbleed. In this case I'm inclined to trust IVPN for now, but I'm thinking in general I'll assume any site that hasn't posted any "we're not vulnerable to Heartbleed" is still vulnerable.

http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/?utm_cid=mash-com-fb-main-link

[ecofeco]

Suprise surprise

Not.

What's even more galling is the fact that warnings of SSL's vulnerability came out years ago.

[psychonaut]

foss

Thats right. Freely open to read. Freely open to expoit.should be freely open to fix but it wasn't now was it.fuckwits. I LOVE the fact that ms arent effected.

[Anonymous Coward]

Re: foss

Closed source has exactly the same issues you just can't:

- Know exactly where those issues are unless you have a code access agreement or are very good at working with binaries.

- Can't see what a vendor did to fix a problem and thus be sure they A: actually fixed it, B: didn't create more problems in the process.

- Can't fix really old legacy versions that the vendor no longer supports but you depend on.

etc etc.

Humans make mistakes. It's unfortunate but we can't avoid ever making mistakes. The most important thing is to be able to recover from the mistakes. All of the vendors that shipped broken versions of OpenSSL should have put out an update by now. If the setup you are running doesn't have an update you can compile a newer version of OpenSSL or if a newer version won't work on your setup you can backport the fix (I don't think there are any systems out there running the broken versions that couldn't compile the latest though) to a version that works on your system.

All of this "hah! I told you open source is crap" bleh bleh is nonsense either way. Closed source products have been using favourably licensed open source components forever. If closed source vendors really cared there wouldn't be tons of different TLS implementations that are ALL broken in different ways.

[Sander van der Wal]

Re: foss

The discussion is about the claim that in "Open Source all bugs are shallow". Is this claim valid, or not?

This case has shown that that claim is not valid. Nobody has found this defect, even though this particular library is widely used.

Whether other claims made by different parties are valid or not is not the issue here.

[mike2R]

Re: foss

"The discussion is about the claim that in "Open Source all bugs are shallow". Is this claim valid, or not?

"This case has shown that that claim is not valid. Nobody has found this defect, even though this particular library is widely used."

I think that misses the point. This is an incredibly shallow bug. How long would it take someone familiar with the code to find the issue, once it had been pointed out? Two minutes? Open source or close source, that isn't really an issue.

If people are equating shallow with unlikely to happen in the first place and consequently more secure then that is the fallacy, rather than the idea that wide access to the source code can help with locating the problem in difficult to pin down bugs, which is basic common sense.

[ici.chacal]

Re: foss

I expect MS aren't affected because they have their own implementation of SSL with NSA's back door hidden inside...

[Anonymous Coward]

Re: foss

The mistake people seem to be making here is that this issue is somehow down to TLS implementations. It's unfortunate that this issue is in OpenSSL because of the number of apps that depend on it and obviously applications that link to a TLS library will probably have private keys etc in memory.. but lets say that the biggest target of attacks using this issue is Apache. Apache itself could also have similar issues and the end result would be exactly the same.

Ok so Microsoft don't use OpenSSL for their products and MS' TLS implementation apparently doesn't have a bug like this. Is everyone absolutely sure that IIS doesn't have issues that would allow an attacker to read memory they shouldn't and thus have the potential to find private keys etc? There's nowhere in the complete Windows stack that might allow an attacker to become a superuser and read whatever memory they like?

[Anonymous Coward]

Re: foss

"I expect MS aren't affected because they have their own implementation of SSL with NSA's back door hidden inside..."

I think you are confusing Windows with Open BSD.

[Annihilator]

Re: foss

"I LOVE the fact that ms arent effected."

You mean affected, but never mind. It's not like MS have ever been caught with their pants down (Code Red, nimda et al).

One bug doesn't negate the fact that security via obscurity is a bad thing.

[Anonymous Coward]

Re: foss

One bug doesn't negate the fact that security via obscurity is a bad thing.

You're perhaps deliberately implying that closed-source is security through obscurity. This isn't the case. Many closed source software includes all manner of security measures which are published and explained in great detail, even if the source code itself isn't. Closed source is only security through obscurity if there are little or no security measures other than simply hiding how things work and hoping nobody figures it out. Very little major software operates on these lines in reality, though quite a lot used to.

This Heartbleed issue would tend to confirm that there is no silver bullet - code can be open source, and yet serious issues could still lurk in widely deployed code for years.

As someone who has worked on both closed source and open source projects, the level of complacency in the FOSS community is a real concern to me. I hope this issue is a wake up call and that people start to question their assumptions. You simply cannot assume that just because code has been out there in public view and widely deployed for years means it's safe... how many people have *really* looked at it?

[Stoneshop]

Re: foss

You're perhaps deliberately implying that closed-source is security through obscurity. This isn't the case. Many closed source software includes all manner of security measures which are published and explained in great detail, even if the source code itself isn't.

Sure, you can tell your software has all kinds of security measures, but who's to tell they're implemented correctly? It's a bit like a car manufacturer telling you their cars have crumple zones, airbags, seatbelts, etcetera, but would they actually be working as stated in a crash? Does the airbag deploy at the right moment? The crumple zone designed to absorb the right amount of energy? The seatbelt mounting points sufficiently strong? In the case of cars, certification agencies, and often consumer protection organisations, tend to test that they work correctly, so you don't have to rely solely on the manufacturer's say-so

[psychonaut]

Re: foss

I know what I mean. As did you. Twat/pedant. The song remains the same

[All names Taken]

OTT?

Do I detect a whiff of hype in the way Heartbleed has been announced, denounced or pronounced?

[Steven Raith]

Re: OTT?

To be fair, given the potential for problems if it was exploited in a widespread manner, the IT press going batshit insane over it (and admins patching it ASAP) is not a bad thing.

Sometimes hype is a good thing. Not often, but sometimes.

[Jonathan Dieter]

Android app for checking servers

I've written an android app to check whether a server is vulnerable. I originally intended it for use by sysadmins, but I've already got friends using it to make sure their banking sites are secure.

It's in the play store as "Heartbleed Checker" by LES

https://play.google.com/store/apps/details?id=com.lesbg.heartbleedchecker

[pacman7de]

How the Heartbleed bug works ..

Make me wonder if these kind of bugs could even be exploited if the MMU could trap such errors. Just how difficult is it to design a MMU that don't allow a process to access memory that don't belong it.

"How the Heartbleed bug works:"

"Attack of the week: OpenSSL Heartbleed"

[Stoneshop]

Re: How the Heartbleed bug works ..

The exposed memory IS part of the OpenSSL process space, so a MMU or any other form of inter-process memory protection mechanism would do zilch, nada, nothing.

[pacman7de]

Re: How the Heartbleed bug works ..

@Stoneshop: "The exposed memory IS part of the OpenSSL process space" ..

Is it possible to design a MMU so as a pointer can't read/write past a previously assigned buffer, come on .. where's the innovation ?

[Stoneshop]

Re: How the Heartbleed bug works ..

That MMU would have to be programmed with the information that buffer_X is of size buffer_X_size and is to be accessed by pointer_X only while staying within those bounds. Which are extra steps to be performed by every memory allocation and deallocation routine, which people will then want to bypass for speed reasons (if the functionality is available in the first place, which in ALL hardware to date it isn't). That MMU should also take care of zeroing memory on allocation and deallocation.

In short, it's not going to fly.