Heartbleed and You

[Vekseid]

Important Bits

Since there is a rather lot of misinformation about this bug posted everywhere, I figured it would try to clear things up.

First, it should be mentioned that most major services, and Elliquiy, had patches in place before malicious attacks were verified. The major exception to this is Yahoo and its various properties (including Tumblr). Mashable has a list here of potentially compromised/not compromised major services. Of these, though, the biggest problem was Yahoo dragging its feet. Google and Facebook were patched before this went live.

I'll go a bit into what data was most likely exposed, below.

Second, as I mentioned elsewhere, I patched my servers early on Tuesday morning, about 16 hours after the Debian team pushed their patch. Elliquiy falls into the middle ground, as these things go. I fortunately got alerted to it rather quickly comparatively, but probably need to pay more attention to Debsec.

While Simple Machines Forum hashes passwords client-side (if the user has turned on Javascript), it's done with a known hash and a known salt. If you are paranoid, you should still consider it compromised. Also, not all of the forums I host run SMF, and those would also have been exposed.

Third, the first known malicious use of this exploit in the wild involves attacking vulnerable clients.

This, for most people, is a fairly brief window of Chrome/Chromium, and Android versions, and potentially Opera as well (haven't bothered to check). If you use Chrome/Chromium, Opera or Android browsers, you should make sure they are updating properly. If you have an Android or ChromeOS device, you should try to update it if possible.

If you are running *nix with OpenSSL, I imagine you have already taken care of this, but if you were not aware that this can be used to attack clients, this is your notice.

In general, though, making sure your browser is up to date is a Good Idea (tm). As bad as this was, before Microsoft junkies start gloating, I'll point out that, for everything, this was not a code injection vulnerability. Ahem.

Fourth, if you're not terribly paranoid, a good step to take is to simply log out and back in again on every machine you have. The vast majority of forum users prefer to stay logged in, and the most vulnerable information that may have been leaked would be your cookies.



What the vulnerability was, in semi-lay terms

SSL (https - the thing that gives you the little lock icon next to the address above) is computationally expensive. Forward Security is even more expensive (yes, Elliquiy does this, though in the name of backward compatibility it won't always trigger in supporting browsers). There are a couple of ways to mitigate this - session caching (older) and now with TLS, the heartbeat extension, which actively keeps the SSL connection alive to prevent a need to do the same computations over and over.

The vulnerability worked like this: you send a number of bytes along with your heartbeat request, and tell them you sent a different number of bytes than you actually sent. To get the most data, you'd send nothing, but tell a vulnerable server that you sent 64k. The OpenSSL library would only allocate memory for what you sent it, but still send the entire 64-kilobyte package. A classic buffer overflow bug, in read-only form.

That might sound familiar - wasn't there a giant push to make these sorts of problems a thing of the past over a decade ago?

Yes, yes there was. The OpenSSL team, in its infinite wisdom, decided that the protective measures placed around malloc were too expensive on some platforms.

Theo de Raadt has a bit of a rant here. He's being remarkably civil, considering his general nature.

To whit, this should not have happened. There are some people claiming that C is too old to be writing stuff like this in, but none of the protections of higher-level languages are any better than what standard libraries already provide - provided that you do not turn these protections off.



What got leaked

There have been some claims that this exploit might have been in use in November. However, it's also been pointed out that there is legitimate software that triggers the same fingerprint in logs, so it's not certain if there were any exploits at all before the vulnerability was made public.

Everything that a vulnerable webserver - the program, not the physical machine - ever free()ed from memory was visible for an extremely short period. Other services may have also leaked data, but, in Elliquiy's case:
- Mumble/Murmur (Voice chat): Does not use TLS
- OpenSSH/SFTP (What we use to actually do stuff on the server): Does not use TLS
- Dovecot (IMAP e-mail server): Does not use heartbeat
- Postfix (SMTP e-mail server): Even if it did use heartbeat (checking is nontrivial, but there's no reason for e-mail to support heartbeat), postfix is highly segregated, and exploiting it would be very noisy.

That leaves nginx - our webserver. Anything it held in memory that it released would have been visible until it got allocated again. Nine times out of ten, the result would simply be garbage - most of it is going to be image files, fragments of compressed data that cannot be decompressed (nginx does not support chunkable gzip), and other such things. Much of the remainder is going to have little value - log entries, the vast majority of requests are for public information of some variety, etc.

More pertinently, this data was only visible until it got allocated and overwritten. Elliquiy's server handles a hundred requests a second - so, not very long.



To summarize/tl;dr

1) Make sure your browsers and operating system(s) are up to date

2) Log out of affected sites and log back in - do not delete cookies until after you have done this.

3) There is no evidence that this exploit was abused before Elliquiy, and most major sites except for Yahoo, got patched. Yahoo and its properties did get exploited, however.

4) Changing passwords is optional, but can be a good idea, especially for Yahoo and its properties. I recommend a password manager, such as Password Safe, to handle passwords.

Hope this helps.

-Vek