I remember the days when people were worried about using the Internet for purchases because they weren’t convinced their credit card information would be transmitted securely. It now turns out that a version of Open SSL that has been in production for two years, and on which https and other services like instant messaging, e-mail, and other web applications use has a gaping security hole called the Heartbleed bug.
And before you deem the use of “catastrophic” in the headline to be an exaggeration, let me turn the mike over to security expert Bruce Schneier:
Heartbleed is a catastrophic bug in OpenSSL:
“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users.
Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory. This means that anything in memory — SSL private keys, user keys, anything — is vulnerable. And you have to assume that it is all compromised. All of it.
“Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.
Half a million sites are vulnerable, including my own. Test your vulnerability here.
The Verge explains in layperson terms:
If the “Heartbleed” name sounds dramatic, this bug seems to live up to the hype. It’s already far worse than the GoToFail bug that embarrassed Apple earlier this year, both by the scale of computers affected and the depth of the breach. The new bug would let attackers pull the private keys to the server, letting attackers listen in on data traffic and potentially masquerade as the server. Even worse, it’s old: the bug dates back two years, and it’s still unclear how long anyone’s known about it…
Discovered by Google researcher Neel Mehta, the bug allows an attacker to pull 64k at random from a given server’s working memory. It’s a bit like fishing — attackers don’t know what usable data will be in the haul — but since it can be performed over and over again, there’s the potential for a lot of sensitive data to be exposed. The server’s private encryption keys are a particular target, since they’re necessarily kept in working memory and are easily identifiable among the data. That would allow attackers to eavesdrop on traffic to and from the service, and potentially decrypt any past traffic that had been stored in encrypted form.
And the Heartbleed site explains how you can be exposed:
You are likely to be affected either directly or indirectly. OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used to encrypt traffic on the Internet. Your popular social site, your company’s site, commerce site, hobby site, site you install software from or even sites run by your government might be using vulnerable OpenSSL. Many of online services use TLS to both to identify themselves to you and to protect your privacy and transactions. You might have networked appliances with logins secured by this buggy implementation of the TLS. Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services.
The Atlantic warns that the Heartbleed site can deliver false positives, so test a few times to see if you get the same result, but it very rarely delivers false negatives. A more definitive way to test is to use an SSL tracker; check to see whetehr the certificate’s “issued on” date is later than the security patch.
But there’s a bizarre conundrum if a site registers as unsafe:
If a site tests through as Safe, then it makes sense to change your password there. And all of my email and financial sites are now saying Safe, so the changes I am making there will stick.
But even if a site does not say Safe, the people I have asked say that it still makes sense to change — even though you’ll need to change again when the SSL for that site is fully repaired.
Reasoning: If you change it now, it’s possible that a still-active hacker will capture info today. But if you don’t change it now, anything exploited in the past two years is vulnerable. Also, many sites that are not yet fully protected are on higher alert than they would have been before this news, so hackers may have a tougher time in the new environment than when this was an unknown-unknown.
To give an idea of the degree of the damage, the popular Tor “anonymous” browsing service has ‘fessed up that they were vulnerable (hat tip Ricard Smith) and sets out some of the scope of what else might be affected. Their warning: “…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.” Canada has frozen its online tax filing services so it can assess its exposure. Apple, Microsoft, and Google don’t appear to be affected but Yahoo is. They issued this statement this afternoon:
Our team has successfully made the appropriate corrections across the main Yahoo properties (Yahoo Homepage, Yahoo Search, Yahoo Mail, Yahoo Finance, Yahoo Sports, Yahoo Food, Yahoo Tech, Flickr and Tumblr) and we are working to implement the fix across the rest of our sites right now.”
Ugh.
21 comments
Comments are closed.
Changing passwords immediately won’t help until the affected servers are fixed. If you pull the trigger too soon on a password change, you still may need to change the passwords again after a fix is in place. Assuming they even bother to tell you what’s going on. I’ve seen reports that PayPal and Dropbox might be included as possibly affected, PayPal on their forums, and Dropbox on a 3rd party forum for 1Password (this uses Dropbox to sync a database across multiple devices). It’s maddening.
Furthermore, I’m actually more concerned about the capture of email addresses tied to an account, the security questions and answers tied to an account and shared across multiple websites, etc. Knowing those items are nearly as good as knowing a password for a particular target site.
Agreed, the “change all passwords” is a matter of timing.
If you use Thunderbird as an email client with Yahoo, you are in the clear.
Folks, do NOT change your passwords until the service you use has fixed the bug. Otherwise you will need to change it again soon. Yahoo and Google day they’ve patched their servers.
Security researchers are still debating what the bug gave access to. Some say passwords in the clear, others disagree. And because it can’t be traced, nobody knows if the bad guys knew of our exploited it before last week.
What is clear is that (1) Open SSL is used in 2/3s of servers running SSL; (2) the bug has been in Open SSL for two years; and (3) it the communication to companies was limited so while Facebook heard about it and fixed it before it was publicly announced on Monday, Yahoo first heard with the public. And despite the articles, all major web companies including Google, Facebook, Yahoo, and Amazon use open SSL and were vulnerable. Google’s researcher discovered the bug and had its major services updated before it went public in Monday.
The security question business is the worst. Those kinds of identification are permanently compromised. There’s no way to know, even ten years from now, if your answers aren’t sitting in a hacker database somewhere. And in my case they were already up to my third grade teacher. Honestly, I’d have trouble remembering whether a given question is safe anymore.
That kind of concern applies to privacy issues as well. Sure, every hacker in Bulgaria and Russia is probably running Heartbleed 24/7 right now so the risk is elevated, but this bug has been out there for 2 years. Has it been used? Well, while reading up on this I ran across an article from February talking about hackers spoofing Google and some other big sites using real SSL keys. But how were there getting them? It was a mystery. Well, not anymore – so it’s been used on a large scale against the biggest and most popular server on the web. Privacy? It’s gone forever, for anybody alive now.
Changing passwords before the problem gets fixed might actually increase your risk, because data is safe on disk.
Where ever possible, I plan on changing my security question answers to random garbage text strings generated from a password vault application and maintained there. Problem is that changing the security question answers is subject to the same issue as changing passwords now. Pull the trigger too soon and we’ll have to change those again. Assuming we even know.
As this shows, those questions are next to meaningless. And because those questions always ask about favorite things that I am not interested in (cars, sports, blah blah blah) or historical details that I am increasingly too old to easily recall or are none of their business, I started using the same meaningless word for all of those questions (sort of underscores how meaningless the questions are, doesn’t it?). If nothing else, means that specific private info tied to me is somewhat generic.
Another astounding success for the NSA.
Let’s try and get our heads around the historic scale of this NSA cockup. Under the settled law of state responsibility, ASVAB III Keith Alexander has bankrupted the US government. The contingent obligations of his actions could make the Treaty of Versailles look like a fix-it ticket. Poitras and Greenwald are sitting on everything you need for attribution. The state’s best bet is to fry Alexander as a loose cannon acting ultra vires.
This is the first mega-security breach nor the last. Complete security in a connected can’t be achieved. People get sick, cars break down and security holes will be discovered.
Bruce Schneir on how to pick a password.
If the risk of interception is so high, changing passwords at this time may be riskier than standing pat and using your passwords less often.
The fact is that changing your password before a site is fixed is still a good idea. Unless that site is attacked again between the time you change your password and the time the site patches its vulnerability to the bug, and while your new login/pw are in memory on the server (altogether pretty unlikely) your new password will be fine.
Your own smartphone may be exposed if it runs the “Jellybean” version of Android.
http://androidcommunity.com/heartbleed-only-an-issue-for-android-4-1-1-20140409/
1) Develop a society where a few people have all the money and everyone else has none. 2) Move all financial transactions (bill paying, tax payment, general “stuff” buying) on-line by a combination of propaganda, ease of use, and manufactured difficulty in using traditional methods 3) Use tax dollars for a security agency that systematically creates security breaches to spy on its own citizens and a government that passes laws making privacy impossible. 4) Encourage and enforce software and hardware approaches that make and keep people as computer illiterate as possible.
What can go wrong?
Oh yes, almost forgot,
1.5) Train your justice department to never acknowledge and never ever punish theft by these few so as to reward corruption and punish honesty in the system.
Nothing has gone wrong from the kleptocrats’ point of view. We are all living in Cyprus now, and continue to subsist only as long as the corporate overlords don’t see any immediate advantage in our destruction. For the immediate future they find it useful to preserve quaint fictions like rights, laws, and security of private possessions. Yet we don’t have any way of knowing which early morning the door will be kicked in– and the last shred of velvet glove will come off the iron fist as it smashes into our face.
It looks like this was caused by hubris and not the NSA.
Some developer though he could do better than the standard library version of malloc()
http://article.gmane.org/gmane.os.openbsd.misc/211963
It’s kinda a thing where junior (and sometimes not so junior) programmers decide they can do better than the standard library. But my CString (CMyString) implementation saves a byte they always say….
I would then explain that no code (other than maybe malloc()) has be run more than CString. It’s safe. Plus, if there’s a buffer overrun… which there probably will be one day… and someone used your CMyString implementation? It might not even be your bug.. but you’ll get the blame since they used your CMyString class. How are you going to explain it to the CEO? To the public? Sorry I cost you millions… but I saved a byte on each allocation! Using the standard implementations means they don’t knock on your door when things blow up. If you want to write library code… go join the damn library team.
BTW, I’m not sure that changing passwords is going to help here. What is most likely exposed was the encryption keys of the server. That means all “encrypted” data sent to the server is could easily be read. Or worse, someone could set up a man in the middle attack and pretend to be that server.
It’s possible that someone could have saved the last 2 years worth of internet traffic and then post decrypted them. Unlikely? OTOH, it’s very likely that people are probably grabbing as much traffic as possible now just to do so. It also looks likely that this bug was being exploited before it was discovered.
Servers will need to be patched… with new keys. Until then, encryption is broken.
Heh, Theo de Raadt. He is probably right here, but if done correctly managing your own memory heap can be good for performance. But OpenSSL is such an ugly mess, that they should concern themselves with such things when the codebase is more sane.
I would agree with Theo – someone needs to fork this project and clean it up. Or perhaps even rewrite. I would be a fan of breaking it in multiple libraries. TLS is also an ugly overly complicated protocol to deal with, while the cipher/crypto stuff isn’t so bad (I use it). But even that straightforward part (the crypto stuff) the still API sucks (which is a proxy to Theo’s point). It’s certainly cause me a lot of pain.
Relevant commit to fix heartbeat:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=96db9023b881d7cd9f379b0c154650d6c108e9a3
“1 + 2 + 16” – Jesus Christ guys – use a MACRO and/or explain better. And that section is copy-and-pasted – even if not careless (maybe they’ll clean this up later), it shows the rush to get the fix out. I can’t imagine there are no more problems in this rat’s nest.
Wow…. Agreed… would not have passed my code review.
Not only did they use hard coded constant values… they used them the same values in multiple places… without documenting each use. (Is 1+2 the same 1+2 value in every usage? What if these values change?) They should be using sizeof() or #defines. Plus, they allocated stack memory to hold the padding. It’s best to keep that crap off the stack to make overruns less exploitable.
IMHO, this is only the first OpenSSL bug.