Critical SSL vulnerability

[NutmegCT]

Is there any way to tell which hosts *never* had the problem? (So you only have to change passwords on the "problem" sites?)

 

[drooartz]

Is there any way to tell which hosts *never* had the problem? (So you only have to change passwords on the "problem" sites?)

Short of asking their tech folks, not really. It's a complicated vulnerability, and unfortunately has been in the wild for two years. It is not clear (and will not ever be clear) if there has been an EXPLOIT of this issue before, partly as the issue at hand is not something that has been logged by servers.

I run a series of servers where I work (I'm a programmer, webmaster, DBA, etc) and we got lucky -- our version of the OpenSSL library involved was an older one and not impacted by this bug.

If you have a site you are concerned about, contact them. Changing your password before they have solved the issue does not help.

A reminder on good password usage that this issue has brought back up: you should NEVER reuse passwords for multiple sites, especially for ones that are critical (bank, email). Yes, this means you will have to have a list somewhere. However, if one of those sites gets compromised, your others remain safe. if your passwords were unique for each system.

This bug/exploit will have implications going forward for quite some time. Lots of folks in my industry have been having a very busy week...

 

[TR3driver]

It is not clear (and will not ever be clear) if there has been an EXPLOIT

Well, it could be clear, if they ever find one. No one has yet though.

Of course, then the next question would be how useful the information would be. As I understand it, there is only a small amount of server memory that could be scraped, and depending on the particular build running, it might not have any sensitive data in it at all. So it's more of an unknown wrapped in an enigma hiding behind a theoretical discovery.

 

[drooartz]

Well, it could be clear, if they ever find one. No one has yet though.

Of course, then the next question would be how useful the information would be. As I understand it, there is only a small amount of server memory that could be scraped, and depending on the particular build running, it might not have any sensitive data in it at all. So it's more of an unknown wrapped in an enigma hiding behind a theoretical discovery.

The issue is that the particular action is not logged (could be, just hasn't been). So there is no trace on the server if someone has been able to get access to things they shouldn't. There are already scripts to do the exploit, we just don't have a good idea if there were active groups doing this prior to the information release earlier this week. I've seen a dump from Yahoo that clearly had user accounts and passwords included.

And while the memory dump is limited to a small amount at a time, there is NO limit to the number of times you can request it -- you'll get a different piece of memory each time. The danger is that you can see what ever is in the server's memory at that time, which can include other users passwords (bad) and sometimes even the private keys that are used for encryption (catastrophically bad). If those keys get compromised, a man-in-the-middle attack becomes very easy for someone -- the bad guy can unencrypt the traffic.

This is why changing a password BEFORE a site patches the hole is pointless -- the attacker can keep scraping the server's memory and could be able to get your new password anyways, or may just be reading your encrypeted traffic (where the password is often sent in the clear, since the idea is that the connection is secured). It's a big mess.

The best description I've seen yet of how this works is on today's XKCD comic:

https://xkcd.com/1354/