They’re right - if you change your password before the problem is fixed, there’s no way to be sure the new one isn’t compromised too.
It’s not all that likely that your password has been leaked by the problem. But it is likely that someone’s has, and there’s simply no way to know who is and is not safe.
And once again, if you’ve used duplicate or similar passwords across multiple sites, your risk is much higher.
I just checked our servers at work, and we’re using a version of OpenSSL older than the bug, so we’re fine. Whew!
The bug is returning RAM only. I haven’t seen this posted anywhere, but that should mean that leaked user credentials, should only be compromised on sites you used while or just before the bug was being exploited which is going to be heavily, heavily tilted to the last few days. So I would change the password on all sites that I’ve used in the last say month, preferentially tilted towards site I used in the last few days. Don’t forget any sites possibly accessed by another site you gave your password to like mint.com.
The thing is, OpenSSL uses a custom memory allocator. What that ultimately means is that the heartbeat over-read does not read random chunks of memory (which would tend to be uninteresting or cause a crash) but rather only other pieces of memory recently used by OpenSSL. That means it’s significantly more likely to contain “interesting” data (recently decrypted URLs, passwords, form data, etc).
I wouldn’t bother to change your passwords on sites that don’t use encryption.
Plus in three months time there’ll be another web scandal shouting the sky is falling.
FWIW, here’s an article in The Atlantic that gives links to some ways of testing individual sites.
Terrific. Even with the testing tools and all that, I’m getting conflicting info on the status of the ISP for my primary e-mail and whether (or even if — it’s a huge company) it’s fixed.
Just a note on passwords: there are some indications that bad guys are sending phishing emails disguised as password reset warnings prompted by Heartbleed. Take extra care clicking links in emails.
I should note for my last post that I check my e-mail through Thunderbird 99% of the time instead of the Web interface (which I usually use for bill paying, if that), so I have no idea what I should be checking and when.
Thunderbird still uses SSL/TLS encryption.
Which means…?
I’ve poked around with these 2 diagnostic websites:
http://filippo.io/Heartbleed/
A number of websites appear to have patched their OpenSSL, but have not updated their certificate. Lastpass provides language like, “Possibly Unsafe (created X months ago at xxx nn 00:00:00 2013 GMT)”. What are the consequences of changing the password on a no longer vulnerable server which has old certificates? Does a residual security vulnerability remain for the user? Why and how do old certificates matter?
Admittedly, I haven’t tried this recommended diagnostic:
If the site changed its implementation of openssl to a secure version, then it’s safe from any future incursions.
But it was unsafe in the past. That means at some point in the past, an enemy could have plucked information from the site, including your credentials, and (more alarmingly) the site’s private key. This private key is what makes https secure – when you see the locked icon on your browser, you’re supposed to be able to conclude that no one in the middle of your communication can intercept it. But if the server’s private key is compromised, then that guarantee is no longer true. Someone could even impersonate that server – pretend to be your bank, for example, by running a fake server on the local WiFi at your coffee shop.
In order to completely their fix, not only must the old certificate be replaced with a new one, but the old certificate should be revoked. Until that has been done, there is still risk associated with using that site.
Thanks much Bricker: that was helpful. Under such circumstances should I change my password on a site with solid OpenSSL but dubious certificates? James Fallows seems to think so. I’m inclined to agree - but I see now that it might be better to avoid routine logins to websites that are not 100% secured if possible and practical. Or so I very very very tentatively hypothesize.
In other news, the author of the bug steps up, mans up and fesses up.
Bloomberg reports that the NSA has allegedly known about the bug for a while and has exploited it:
http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html
I believe it reasonable to question whether the NSA conducted an accurate, proper and comprehensive cost/benefit analysis.
Cloudflare has been testing the exploit and has been unable to use it to steal a private key. Which doesn’t mean no keys were stolen, but at least means that, for certain configurations, it’s not trivial.
The’ve put up vulnerable server as a challenge, to see if anyone can steal its keys.
To be clear:
The nature of the bug is explained in this xkcd cartoon.
Cloudflare notes that hackers can obtain user passwords in this manner: it’s just a lot harder for them to extract private SSL keys: The major problem (and cause of heartbleed) is that the code does not check that this length is the actual length sent in the heartbeat request, allowing the request to ask for more data than it should be able to retrieve. The code then copies the amount of data indicated by the length from the incoming message to the outgoing message. If the length is longer than the incoming message, the software just keeps copying data past the end of the message. Since the length variable is 16 bits, you can request up to 65,535 bytes from memory. The data that lives past the end of the incoming message is from a kind of no-man’s land that the program should not be accessing and may contain data left behind from other parts of OpenSSL. …
Previous requests could contain password data, cookies or other exploitable data. Private keys are a different story; due to the way the heap is structured. The good news is this means that it is much less likely private SSL keys would be exposed.
ETA: Caveat! There have been reports of a private key being stolen from Apache servers, but only on the first request. This fits with our hypothesis that restarting a server may cause the key to be revealed briefly. Apache also creates some special data structures in order to load private keys that are encrypted with a passphrase which may make it more likely for private keys to appear in the vulnerable portion of the stack.
ETA2: So maybe some hacker got lucky months ago with a small number of websites (eg. one SOL website).
I find arguments based on the behaviour of the heap to be pretty dubious. The problem is that the behaviour of a malloc implementation will vary greatly between operating systems. The best that you can say based on CloudFlare’s analysis is that on the processor architecture that CloudFlare uses (probably x86-64), running whatever Linux release CloudFlare uses, using whatever libc version CloudFlare uses (and not replacing malloc with an alternative version like Facebook does with jemalloc), running with the OS configuration that CloudFlare uses (e.g. address space layout randomization would presumably change that argument a lot?), it’s unlikely for private keys to have been leaked.
Also, in the of a determined attacker with huge resources and 2 years to play with (i.e. the NSA) they could still catch you in a maintenance window and screw you. Remember, they only have to get the private keys once.
That didn’t take long: two people have broken it already.
I’d like to sincerely and publicly thank Cloudflare for presenting this challenge. Now we know.
Just to be crystal clear: what can a bad guy do with an SSL key?
A bad guy can do the following:
[ul]
[li]Launch a man in the middle attack.[/li][li]Create a fake version of the target’s website, complete with lock.[/li][li]Possibly intercept traffic between user and target. Or rather if they have intercepted such traffic, they can translate it. [/li][/ul] I’m assuming the bad guy can’t use the SSL certificate to break into the target’s database. Right?
(I’m assuming that the target has changed its internal passwords this week. That would be good practice and standard practice, right? )