Possible band name. Not.
We have Bruce Schneier weighing in on this.
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.
The bug has been patched. After you patch your systems, you have to get a new public/private key pair, update your SSL certificate, and then change every password that could potentially be affected.
At this point, the probability is close to one that every target has had its private keys extracted by multiple intelligence agencies. The real question is whether or not someone deliberately inserted this bug into OpenSSL, and has had two years of unfettered access to everything. My guess is accident, but I have no proof.
I’m sure that Bruce knows more about security than I do.
Here are the knowns, unknowns and my ruminations. This vulnerability has been around for two years. The attacker can get 64K of information, a RANDOM 64K of information. Nowadays, that isn’t a whole lot. It’s certainly not the millions of cards in the Target hack. It’s untraceable, so we really don’t how many times an attempt has been successful. We don’t even know if any of the attempts have been successful. But I have questions about the data that is retrieved. OK, SSL keys, both private and user. User IDs I guess as well. Anything? I’m not sure anything is a valid concern. User IDs are easy, for at least you know that they are in ASCII or Unicode/UTF-8. They’ll be easy to pick out of the mess that gets retrieved. The SSL keys, on the other hand, I think are problematic. Unless there is some ASCII string that declares “Private key->” followed by the key, I’m not sure that the key can actually be located.
Looking at some recovery files, I see the Microsoft User Account recovery file starts off with RSA2. The other recovery file has “Microsoft Enhanced Cryptographic Provider v1.0 and something that looks like UID, only in hex. So, maybe.
As to getting anything? I’m not sure anything is a valid concern. Again, unless it’s in ASCII, I can’t see how a random 64K block is going to give anything away. Possibly. Password hashes? How are you going to tell if something is a hash, let alone a password hash. I would hope that any passwords given to a program are hashed, and the original values destroyed. Still vulnerable, but then it’s a matter of timing and how lucky the attacker is. Getting the correct 64K block at the time that the password is still visible in memory.
I am NOT going to change my passwords on all of my sites again. Only when forced to (domaintools.com, I’m looking at you, there’s nothing anybody would want to do with my login there!). My financial site does not have the flaw. Google’s stuff does not have the flaw. That’s good enough for me right now, unless I hear about real damage from this bug.