Ed Felten provides good advice on this blog about what to do in the wake of Heartbleed, and I’ve read some good technical discussions of the technical problem (see this for a particularly understandable explanation).
Update Apr 11: To understand what Heartbleed is all about, see XKCD. Best. Explanation. Ever.
In this brief posting, I want to look at a different angle – what’s the scope of the vulnerability? I’m going to be (moderately) optimistic and suggest that within a week, major sites of all shapes and sizes (banks, e-shopping, government) will have installed the patches to their web servers and generated new keys/certificates, so it’s safe to visit them to change your password (if it’s an important account), and move on with your life. [That’s being optimistic – the realist in me says that there will be some sites that will take months to get patched, because the approval process for big corporations and government agencies is some cumbersome that they can’t say “emergency override”, and fix the problem quickly.]
But there’s three other classes of sites we should also be concerned about.
- First, there’s the medium sized companies – too big to use an outsourced hosting provider that will automatically do the patching for them, but not big enough that they have a well-defined process for rolling out an emergency patch to production web servers. A lot of e-commerce sites fit into this category – and these may well be the riskiest sites. Those using hosting providers – like the mom & pop pizza shop – may get upgraded by the provider, but probably won’t know that they need to replace their certificates. Certificate Authorities should reach out to their customers to encourage them to get a replacement – but unless they offer significant discounts, that offer may fall on deaf ears.
- Second, the products out there that aren’t web servers, but still use OpenSSL. There’s lots of these sorts of products, and in many cases the organizations that use them have no idea that OpenSSL is buried deep inside – and the vendor itself may not be aware, since OpenSSL may be embedded in a library that gets embedded, or it may have been inserted by a programmer who left the company years ago. (We saw a scenario similar to this a few years ago when there was a serious vulnerability in a low-end Microsoft database product – and many products had it embedded but no one knew about it.)
- Third, and scariest, are the embedded devices. How many ATMs, manufacturing devices, monitoring cameras, etc use OpenSSL because vendors got burned when it came out that their communications were unencrypted? So they did the “right” thing, embedded OpenSSL – and now perhaps made things even worse. True, these devices aren’t likely to have a lot of passwords to be stolen from memory via the Heartbleed vulnerability, but there may be other sensitive information that can be retrieved.
Obviously there’s some overlap between the second and third of these, but I separate them out because 2 is fundamentally about “computers” in the traditional sense that are not running web servers, and 3 is about embedded devices that happen to be running web servers.
The threat that every password and every private key have been stolen are almost certainly overblown. But at the same time, we shouldn’t draw the line too narrowly – there are a lot of things beyond just “Apache running OpenSSL” that need to be examined.
“The threat that every password and every private key have been stolen are almost certainly overblown.”
Of course it is, just as the threat that Windows XP will be so vulnerable that people have to stop using it last week. When is it the duty of security minded people to go over the top in warnings and when is it less helpful.
I am a very eccentric minded person, clinically paranoid but that doesn’t mean I am wrong. I predicted the likes of Code-Red and ILOVEYOU worms years before their appearance. I didn’t foresee the png vulnerability but after that I predicted many other similar bugs would show up in pretty much any and every other digital format out there and most have been exploited since png.
And, thus, I can totally understand the idea that any given password (not every password), and any given private key (not every private key) could have been compromised. And even one compromised password or key has tremendous exploitation possibilities.
So the paranoia “presumption” of all things compromised is the only “safe” perspective. Paranoid yes, wrong, no.
The realist in me however grants that value of “safety” in such a “presumption” diminishes greatly by painting “to broad a line.” Narrowing the line down some is called for. It makes sense, then, to tell people to change passwords of any websites they use regularly that contain or pass important information. Information they feel is important, which would certainly include for most people PII (personally identifiable information such as birth dates and SSNs) and financial information; but may include things such as Facebook where people post a lot about themselves.
But the ultimate paranoia in me has this one question to ask of those security minded persons. Could this vulnerability have been purposely introduced (by say someone working covertly for the NSA)? We already KNOW for a fact the NSA haa been working to purposely decrypt as much encrypted traffic on the web as possible, and there is a lot of evidence to suggest they also purposely reduced the strength of encryption technologies. It stands to reason to believe they had a hand in this “bug.”
So I am gobsmacked, appalled, astonished… these critical libraries that are so important: surely they use Test Driven Development, and a tested every which way so that they are proven to work. And, of course, they’d always zero any allocated memory so that there was just *no* chance of any leakage…
I do this for my security code. And it’s no where near as important as openSSL (by several orders of magnitude).
There is no excuse for this. People have to stop using openSSL pronto. It’s written by monkeys anyway