Someone has to say it. Yes, Heartbleed could potentially cripple previous SSL/TLS communications, but the chance of your password being compromised is a million to one (literally!)
So how does Heartbleed work? To avoid reinventing the wheel, here’s an XKCD comic that sums it up pretty well.
Looks pretty scary, huh? Well, it shouldn’t be. Let’s go back to basics on how memory allocation works on a modern system. Each process in a system is allocated an initial block of memory, in a totally random space. The kernel denies read access outside this block (or any other).
SEVERE HEALTH WARNING: This post gets into a LOT of technical detail, so if you don’t understand it, or are scared of it, skip to the conclusion!
So, in comes a legitimate SSL request. The web server stores the body of this request in a random memory location in its block (where it can fit, thanks to a feature called Address Space Layout Randomization enabled in most modern operating systems). In a lot of cases, if any new blocks are created (say a lot of time has passed, we’re storing initial configuration values in the first block - nginx does this, and is virtually immune), they’re in a completely different memory location, and most likely will stay there (unless something is deallocated).
So, as memory allocation is done randomly, and new allocations are located (usually) as far away from active memory as possible, an attacker probably won’t read anything useful, perhaps a few response headers or static files, or the top of a dynamic page containing nothing important. If they do read a header, they’ll most likely just read a cookie with a session key, which can easily be voided by logging out, and the chance of an attacker doing anything with this is almost zero. The only potential attack vector, the one in which a single key has been extracted, is if a machine is freshly rebooted and hasn’t accepted any legitimate requests.
If you’re still not convinced that Heartbleed isn’t that critical, every time you make a Heartbleed request, it’s stored in another part of “dirty memory”, likely overwriting anything that could be useful. So, if we’re only reading random memory, what’s the chance that we’re going to find something useful, like a SSL private key, or an administrator password? About 1 in 50,000 for the first attempt, the probability getting exponentially smaller every further request.
Another important fact to note is that most web servers (on big sites, anyway) spawn child CGI processes to actually handle the data, so nothing, like database credentials, or encryption keys, can be read by an attacker, as unless the SSL daemon is running as root it can’t access the memory of any other process. And if a process uses a separate daemon for SSL, like a lot of IRC servers, or mail servers, an attack couldn’t touch anything like a password, as it’s in a different process.
So, what’s the actual risk of any of my stuff being compromised as a result of Heartbleed? It’s virtually non-existent. Unless a secret agent has recorded every single SSL transaction made by yourself, and somehow managed to extract the private key in the several hours after the attack was publicised (if you look at the statistics, the chance of this happening is one in millions). If your browser (and the server) support Perfect Forward Secrecy, nothing can be leaked.
But what if someone’s spied on my HTTPS requests, and logged them? Am I screwed then? If someone has the power to do that and retrieve the private key during the very short window (unless they were aware of the bug before disclosure), they’ve probably already got you. The NSA have a bag of exploits which can get them root/administrator access on virtually any machine, so this is nothing to them. If a virus was installed on your machine, it would probably read data directly from the browser instead of relying on Heartbleed to extract data.
If a private key is stolen, the worst that could happen is that we’d get a Man-in-the-Middle attack. Considering most providers have revoked the old keys, this will soon be useless. If they haven’t, an attacker would do this on a near-individual basis, due to resource problems and obvious latency. And any good intrusion systems would see requests for 100s of users coming from one IP.
So there’s no need to actually change your password unless you’re extremely paranoid. Unless this exploit was discovered by the NSA (which is quite unlikely), no Government spies would be able to use this to conduct mass surveillance, neither would your ISP, neither your employer (unless you work for the NSA, perhaps).
Please correct me if I’m factually incorrect. I’ve done my research, and I believe this to be, but if it’s not, I’ll happily amend this post :)