Heartbleed Bug In OpenSSL Makes It Worse Than No Encryption At All

from the might-want-to-stay-off-the-internet-for-a-bit dept

Last night, while the mainstream press was yammering on about the security implications of Microsoft ending support of Windows XP (it’s already vulnerable, this won’t really change anything), a much bigger issue was concerning security folks. A massive vulnerability in OpenSSL, called Heartbleed, was revealed. As Matt Blaze notes, the bug actually leaks data beyond what it’s protecting, which makes it worse than no crypto at all. The vulnerability likely impacts a huge number of servers — including Yahoo’s (many other major sites, including Google, Facebook, Twitter, Dropbox and Microsoft are apparently not impacted by this). Oh, and the vulnerability has been there for years. Over at the Tor Project, they made the most succinct statement of how serious this is:

If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.

Of course, that also means that if you needed strong anonymity or privacy on the internet, there’s a good chance some of the services you use left you vulnerable for quite some time until now.

Filed Under: , , , , ,

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Heartbleed Bug In OpenSSL Makes It Worse Than No Encryption At All”

Subscribe: RSS Leave a comment
59 Comments
John Fenderson (profile) says:

Yes, it's very serious, but...

It’s a very serious bug, but I don’t understand why it’s worse than not using crypto at all. While I haven’t done an in-depth analysis of the weakness yet, it appears that this bug introduces two primary weaknesses: it allows attackers to obtain the certs used and to decrypt the communications (making it as bad as no crypto), and it allows attackers to read portions of memory outside of what’s being used by SSL itself.

The latter sounds (and is) bad, but memory is still compartmentalized. It doesn’t appear that this vulnerability allows attackers to read the memory being used by other processes, so the intrusion is still limited to the SSL process memory space itself. Conceivably, this could be used to inject executable code into the memory space, but even that would be limited in what it could accomplish (unless an admin was stupid enough to be running the process with admin or root permissions — in which case all bets are off anyway, and the person responsible needs to be fired immediately on grounds of incompetence.)

On first blush, this vulnerability looks like it results in, at worst, the same effect as not using encryption, but no worse than that. And, in fact, it’s not quite as bad as no crypto as it will still stop less determined hackers.

Just to reiterate, I’m not saying this isn’t a very bad thing — it is. But we need to be careful not get get too hyperbolic about it.

John Fenderson (profile) says:

Re: Re: Re: Yes, it's very serious, but...

Replying to myself to mention that obtaining the certs is actually a bit worse than no encryption, as an attacker might be able to obtain your private key. That’s readily resolvable, though, the simple measure of not use the same cert for other things and so limiting the problem to SSL itself.

So, yes, it’s worse. But by a pretty small amount.

Anonymous Coward says:

Re: Re: Re:2 Yes, it's very serious, but...

John, have you browsed the comment thread on arstechnica. That site was unpatched and usernames and passwords were retrieved and used to spoof comment posts.

Finding that the vulnerability affected several of my own hosted sites (cpanel logins could be compromised at the very least) I queried the status of this with my hosts, they hadn’t even realized they were vulnerable, now they are patched. Repeat over the planet.

John Fenderson (profile) says:

Re: Re: Re:3 Yes, it's very serious, but...

Yes, as I said, this is a very serious problem.

But wait a minute…

Are you saying that the vulnerability is allowing people to obtain credentials for data streams other than the ones that are being directly tapped? That sounds like someone was using a single SSL process to service several independent SSL streams. That would be poor practice, vulnerability or not.

As I said, I haven’t done my research on this yet, so my understanding of the details is superficial at this point. It’s starting to sound like the problem was that people were relying on SSL to cover for other poor security practices. If that’s the case, then what’s being revealed is a problem that goes way beyond this particular vulnerability.

Anonymous Coward says:

Re: Re: Re:3 Yes, it's very serious, but...

Right, this is the problem.
With no encryption the data cent to/from the server can be deciphered but only if you are able to see the data being sent back and forth. (eg control a router between user and server)

Since this flaw lets the attacker read the memory they can read any and all data sent to/from the server and even from the server to other backend systems like databases.

This flaw is indeed much worse than just having no encryption.

John Fenderson (profile) says:

Re: Re: Re:4 Yes, it's very serious, but...

“Since this flaw lets the attacker read the memory they can read any and all data sent to/from the server and even from the server to other backend systems like databases.”

If this is the case, then the real vulnerability is not even with SSL itself. It’s with how the system is set up to begin with. A properly designed system will not allow a public facing process to read the memory of any other process no matter how hard it tries. If a compromised SSL server can be used to do this, then the problem goes way deeper than the SSL server itself.

It is incredibly reckless to trust any public facing service to that extent. I hope that sysadmins won’t just install the fixed version of OpenSSL and figure the problem is resolved. They should take this opportunity to fix the deeper underlying security vulnerability of trusting a public-facing service in the first place.

Anonymous Coward says:

Re: Re: Re:5 Yes, it's very serious, but...

It’s a buffer overflow, so basically you are inputting garbage into the heartbeat of the SSL/TLS session, and it’s replying back with other data not meant for you. If you weren’t using SSL/TLS to properly secure connections then it wouldn’t know, but that has it’s own risks.
You can check out the python script I’ve been using to test:
https://gist.github.com/takeshixx/10107280

Pretty serious considering, you really don’t know what it’s going to send back. Admin credentials, DB credentials, other user info, pretty much anything you were using OpenSSL to protect.

Right now, best bet is simply turn off heartbeat responses if possible, and re-keying all your certs just in case.

Anonymous Coward says:

Re: Re: Yes, it's very serious, but...

It was a serious bug, the fix is out now. The problem is that it potentially revealed private certificates, meaning that sites have to replace all their SSL certificates. This also means that third parties could impersonate the site for a man in the middle attack. It also potentially revealed user names and passwords, so users have to reset their passwords.
Oh it is just the sort of backdoor a certain 3 letter agency would use, the system appears secure, but they can read everything, and impersonate the site, and impersonate users.

Anonymous Coward says:

Re: Re: Re: Yes, it's very serious, but...

There is a lot of hype about this bug, but if you actually look at the patch and what it effects you cannot just access any memory chunk on the server.

So the bug will give you back a random 64K chunk. Yes there could be cert keys or passwords in it, but more likely you will get back random data or blank data.

The security company that released it are hyping it up to make them sound important.

No hacker would both with this unreliable vulnerability when so many bugs exist in the likes of Joomla or just people configuring servers badly.

Just update and move on.

That One Guy (profile) says:

Re: Re: Re:2 Yes, it's very serious, but...

This may be a stupid question, but how often would it be possible to trigger the bug and get that 64K chunk of data?

I agree that on it’s own that’s probably going to return fairly useless data simply due to how much you’d be talking about, but if you can trigger it multiple times in a short period of time, and set something up so it keeps doing so, then it seems like you’d be able to gather a pretty extensive amount of data, and comparing the individual chunks you’d have a pretty thorough bit of information.

Anonymous Coward says:

Re: Re: Re:3 Yes, it's very serious, but...

You can keep retrying until you get what you’re looking for. Furthermore, this is not a request that is normally logged by a web server, so there’s no record that it happened. I’m not sure it can be logged, except possibly by running in ?ber-verbose debugging mode, if that.

Craig says:

Re: Re: Re:4 Yes, it's very serious, but...

The fact that one of the tests for the vulnerability was to insert something into memory (via a request) and then try to read it back out again via the exploit trivially proves this assertion wrong. As do the rest of the facts, if you actually bother to read about them. Please, for christs sake, if you don’t know shit, just keep your mouth shut instead of giving advice to people who might not know any better. People like you are dangerous.

Anonymous Coward says:

Re: Yes, it's very serious, but...

There is one significant difference.

Without crypto, the attacker has to be on-path to sniff the connection.

With this bug, an off-path attack can continuously query the server and get snippets of relevant data.

Over at arstechnica, one commenter managed to grab the passwords of two other users, and post as them. He wasn’t, as far as I know, on the victim’s path to the arstechnica server.

(And no, this attack cannot inject anything on the memory, it’s merely an information leak attack. At least that!)

Coyne Tibbets (profile) says:

Re: Yes, it's very serious, but...

This is a flaw in the encryption software that allows you to read the memory of the system on which it is running. You not only have access to encrypted messages, but potentially the ability to look at everything in the machine’s memory. (Basically the ability–at least–to view all user passwords, any other encryption keys in use by the machine, read the network configuration, and so on.)

Broken encryption means that when you sign on to your bank the attacker can read your communication with the bank.

But if you’re running the broken version of this software, you might just as well hand your hard drive to the attacker. That’s why it’s worse.

Craig says:

Re: Yes, it's very serious, but...

No, dumdum, it also people to fetch 64k of the sever’s memory at a time, repeatedly, without leaving any trace whatsoever. So what you’re sayingis, either you think reading the entire contents of memory remotely is no worse than reading just the network traffic or you didn’t bother to do the cursory reading to actually understand the bug, before you formed an opinion and jotted it down on the internet.

Anonymous Coward says:

From what I have read, this exploit first appeared about 2 years ago in version 1.0.1 and has continued through version 1.0.1f. Given numerous other relvelations, like the $10 million payment to RSA to make Dual_EC_DRBG the default in its widely used BSAFE encryption toolkit, to weaken global encryption, I’ve already seen questions about potential NSA/federal government involvement in this vulnerability.

But this is what happens when you’ve been caught with your hand in the cookie jar too many time, when you bend, break and manipulate the rule for nefarious purposes, and ben caught constantly and repeatedly outright lying and manipulating the truth.

Anonymous Coward says:

Re: Re:

Assume for a moment that some ‘security’ agency supported by the government implanted this flaw so they can spy on ‘terrorists’ to make us ‘safe’ from ‘boogeymen’.

The end result is that the ‘security’ agency made all of us LESS secure not more secure. Now my login info everywhere is compromised, my bank accounts at risk and things I would prefer be private like my medical conditions are possibly exposed.

Making things worse, ‘terrorists’ do not scare me, I am more concerned about the tens of thousands of deaths in automobile accidents each year that some panty bomber burning his nuts.

Anonymous Coward says:

Re: Re:

One of the beauties of FOSS (and source control systems) is that we can go back in time and see who injected the flaw in question, and further vet the cause.

If the individual in question is found to have ties to government organizations, then the conspiracy theories may continue. If on the other hand, it is believed that this was an innocent mistake that went unnoticed for a very long time, then we can perhaps put it to rest.

One thing is certain – people who contribute to FOSS projects that are security-sensitive should be extra careful about what they submit – lest they risk having their names attached to huge security disasters in the future.

Anonymous Coward says:

By By Certificates

My take is that someone with access to the major interchanges would just hit this bug over and over until they got the server certificate. Then they can easily do a man in the middle attack and get everything.

It’s exactly what the NSA has been doing. It explains how they were able to break almost all SSL encryption. So far we have

Apple (check)
GnuTLS (check)
OpenSSL (check)

So I would assume there is a bug in Windows SSL that lets the NSA do man in the middle attacks as well.

I’m sort of relieved. I’ve been waiting for the OpenSSL shoe to drop for a while. I had been assuming the attack was via the random number generator. At least now we know the big door has been found. Unfortunately, one must always assume there are more wholes.

Anonymous Coward says:

Hole is closing, test tool

There’s a command line test tool that I used to probe about 500 sites today. Of these, 6 were vulnerable. 4 were non-American focused consumer sites, and 2 were American startups. I tried a lot of American bank/finance/ecommerce sites, and none were vulnerable at this time.

The tool I used was:
https://github.com/titanous/heartbleeder

There’s also a web-based tester:
http://filippo.io/Heartbleed/

John Fenderson (profile) says:

Re: Re: Re: Re:

Because all software, both open and closed source, contains security flaws.

The nature of open source makes it more likely that security flaws will be discovered and fixed. The nature of closed source makes it less likely that security flaws will be discovered and fixed. Every time a flaw is found and fixed, the software containing the flaw becomes safer, not more dangerous.

Also, open source software is auditable. Closed source software is not. If you are deeply concerned about security, this is critical. It’s never a good idea to have to take a company’s word that their software is “safe”.

From a security point of view, I am MUCH more comfortable with open source on the whole than closed source.

Socrates says:

Re: Re: Re:2 Willful sacrifice

” The nature of closed source makes it less likely that security flaws will be discovered and fixed”

It is much worse than “just” glacial improvement and new features with fresh bugs.
Closed source corporations may be served NSLs. They may actively harm their customers. Many US corporations have been served NSLs and is utterly untrustworthy.
Proprietary privacy corporations have been payed to harm those who trust them. The US corporation RSA is an example of this.

blob (profile) says:

so...

I’m stuck with LM15 on a partition (the one I use the most), I installed LMDE2014 and did an update and it indeed seemed to patch openssl among other things.

But I get no updates for LM15 anymore, I figured it wasn’t so bad since I’m massively protected by an iptables setup from hell (bad guys just fly by me, mostly). Is this why a e-commerce place where I bought something yesterday in the UK is saying he’ll process it tomorrow, cos they need to update their servers and stuff?

Am I screwed if I don’t want to update to regular Mint 16 and replace this OS yet? One reason why I don’t want to is that I have maybe 1gb of space left on that partition, all of my data is on other partitions. Well I’ll have more space once I backup all the documents and files i want to back up but customizing LM16 so it is exactly the way I like it right now in LM15 will be a drag…

I’ll do it if it’s totally unwise to stay idle right now. I don’t use LMDE2014 because it can’t start pulseaudio for some reason and I get no sound, which is unnacceptable to me.

Add Your Comment

Your email address will not be published.

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...