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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: cryptography, encryption, heartbleed, openssl, ssl, vulnerability
Reader Comments
Subscribe: RSS
View by: Time | Thread
Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Re: Yes, it's very serious, but...
So, yes, it's worse. But by a pretty small amount.
[ link to this | view in chronology ]
Re: Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Yes, it's very serious, but...
Everybody does that. Using "prefork" is so last century.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Yes, it's very serious, but...
It’s my understanding that you can’t without recompiling, in which case you may as well just install the patch.
[ link to this | view in chronology ]
Re: Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Yes, it's very serious, but...
Except that serious hackers in the wild have already been using it to successfully retrieve critical data such as private keys.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Yes, it's very serious, but...
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!)
[ link to this | view in chronology ]
Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Yes, it's very serious, but...
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.
[ link to this | view in chronology ]
Re: Re: Yes, it's very serious, but...
Except you hard disk is not usually stored in RAM.
[ link to this | view in chronology ]
Re: Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
Re: Yes, it's very serious, but...
[ link to this | view in chronology ]
I wonder...
[ link to this | view in chronology ]
Re: I wonder...
[ link to this | view in chronology ]
Re: Re: I wonder...
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Well....
[ link to this | view in chronology ]
Re: Well....
[ link to this | view in chronology ]
By By Certificates
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.
[ link to this | view in chronology ]
Thanks Snowden!
You are a true American Patriot!
[ link to this | view in chronology ]
Re: Thanks Snowden!
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Hole is closing, test tool
The tool I used was:
https://github.com/titanous/heartbleeder
There's also a web-based tester:
http://filippo.io/Heartbleed/
[ link to this | view in chronology ]
Re: Hole is closing, test tool
Works like a charm.
[ link to this | view in chronology ]
Re: Re: Hole is closing, test tool
https://www.ssllabs.com/ssltest/
(One of my banks scored an F (aaaahhhh) but wasn't vulnerable to Heartbleed so that's okay (not).
[ link to this | view in chronology ]
Re: Hole is closing, test tool
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
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.
[ link to this | view in chronology ]
Willful sacrifice
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.
[ link to this | view in chronology ]
Has anyone tested other sites?
[ link to this | view in chronology ]
Re: Has anyone tested other sites?
[ link to this | view in chronology ]
so...
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.
[ link to this | view in chronology ]