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: cryptography, encryption, heartbleed, openssl, ssl, vulnerability
Comments on “Heartbleed Bug In OpenSSL Makes It Worse Than No Encryption At All”
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.
Re: Yes, it's very serious, but...
A data tap allows you to read the inputs and outputs of the memory. This constant stream can be sent to a database in cleartext. And that’s the key. The fact that it can then be read at the attacker’s leisure.
Re: Re: Yes, it's very serious, but...
Yes, exactly. Just as if there was no encryption. So how is this worse than no encryption?
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.
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.
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.
Re: Re: Re:4 Yes, it's very serious, but...
Re: Re: Re:5 Yes, it's very serious, but...
And even with “prefork”, after the connection ends the same process is reused for another connection.
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.
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.
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.
Re: Re: Re:6 Yes, it's very serious, but...
?turn off heartbeat responses if possible?
It?s my understanding that you can?t without recompiling, in which case you may as well just install the patch.
Re: Re: Re: Yes, it's very serious, but...
Because you can make a legitimate, trusted website install malware for you.
Re: Re: Re:2 Yes, it's very serious, but...
In a manner other than I already acknowledged above?
Re: Re: Re: Yes, it's very serious, but...
“So how is this worse than no encryption?”
People who think they’re safe via encryption will send data that they’d never normally send in plain text. So, data will be exposed that wouldn’t be if it was known that the connection was insecure.
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.
Re: Re: Re: Yes, it's very serious, but...
Yeah, I thought of that after I posed my original question.
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.
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.
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.
Re: Re: Re:3 Yes, it's very serious, but...
You will never get the complete picture and you will never know where about in memory you are reading.
I think retrieving useful info is a long shot and so most serious hackers would not bother using it.
Re: Re: Re:4 Yes, it's very serious, but...
“I think retrieving useful info is a long shot and so most serious hackers would not bother using it”
Except that serious hackers in the wild have already been using it to successfully retrieve critical data such as private keys.
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.
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!)
Re: Re: Yes, it's very serious, but...
OK, I stand corrected. Disregard my previous post. I read it differently yesterday.
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.
Re: Re: Yes, it's very serious, but...
“you might just as well hand your hard drive to the attacker”
Except you hard disk is not usually stored in RAM.
Re: Re: Re: Yes, it's very serious, but...
The frequently/recently accessed stuff is cached in memory, but in theory virtual memory should limit access to just what the openssl process can see.
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.
Re: Re: Yes, it's very serious, but...
“it also people” = it also allows people
Re: Yes, it's very serious, but...
I finished my research. I just wanted to acknowledge that yes, this is indeed more than very serious. This is a critical flaw.
I wonder...
How long the NSA knew about this.
Re: I wonder...
I wonder, if they planted it in the first place.
Re: Re: I wonder...
It’s very unlikely they planted it. It’s not at all unlikely that they’ve known about it for a while, though.
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.
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.
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.
Re: Re: Re:
The source has already been discovered. apprently. Now the debate is how deliberate or not it was.
Re: Re: Re: Re:
I think what ends up happening is that everyone assumes that if there is a bug someone else would have found it by now. So all this code gets pushed through with everyone figuring that it’s been highly scrutinized by everyone else when no one even looked at it.
Well....
…. no porn for me this week then.
Re: Well....
We’re onto you, son.
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.
Thanks Snowden!
Your leaks have inspired people to search for these flaws and many have been found.
You are a true American Patriot!
Re: Thanks Snowden!
Security researchers were around long before Snowden came along. Snowden is a brilliant man but let’s not insult his intelligence with idolatry.
Mojang tweeted about this today. Their servers weren’t compromised by this, but the load balancers from Amazon were. That suggests that the Amazon cloud was at risk and anything that used it should probably have their users change their passwords.
Re: Re:
amazon.com reported vulnerable from http://filippo.io a few minutes ago, now reporting ok, probably just depended what server I hit. Indicative of possible patch rolling out.
It’s not a bug, it’s a feature, courtesy of your friendly neighborhood NSA.
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/
Re: Hole is closing, test tool
Yep, just used the latter to test 4 separate servers after updating them.
Works like a charm.
Re: Re: Hole is closing, test tool
Just parking this link here
https://www.ssllabs.com/ssltest/
(One of my banks scored an F (aaaahhhh) but wasn’t vulnerable to Heartbleed so that’s okay (not).
Re: Hole is closing, test tool
There’s also https://www.ssllabs.com/ssltest/, which is the best SSL tester on the market.
A year of NSA revelations, 2 major POSIX security flaws and not a peep about CryptoAPI. However it shakes out with IIS, the debate about open vs closed source security is close to being settled for good.
Re: Re:
What an utterly moronic premise for such a statement.
Re: Re: Re:
What? I think its pretty clear that anyone using Apache does so at their own peril now. Why is it moronic to assume that administrators interested in their users security will let go of ideology and begin using IIS.
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.
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.
Has anyone tested other sites?
For instance, was HealthCare.gov vulnerable?
Re: Has anyone tested other sites?
I don’t know – I’m still waiting for the screen to refresh.
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.