Published April 12th, 2014

Weekend Reading – Bleeding Hearts

This was big enough to warrant a second Weekend Reading.

FAQ

Is this a big deal? Should I be concerned?

Yes. If you like to sleep better at night, I suggest not reading the rest of this FAQ.

What was stolen?

We have no idea what was stolen, but we have a good idea what could have been stolen. First, all data between your browser and affected web servers, including secure data like passwords, credit card numbers, bank accounts, etc. Second, server keys (see below).

Is it fixed now?

Yes, no and no. Some web sites were on the ball and fixed the issue in record time, especially the big guns with their dedicated security teams. Not all sites got to it in time, and smaller ones may still be vulnerable.

Also, this issue has been around for a couple of years before it was discovered, so it's possible someone else discovered it and exploited it a while back.

My bank said nothing. Should I worry?

Banks don't respond to consumer concerns, don't expect to hear anything anytime soon. Most banks don't use OpenSSL for their consumer-facing apps, so your passwords and other sensitive data was not affected. But, they may have used OpenSSL for other systems that could gain access to sensitive data. Like any credit card breach, we won't know until it's too late.

Do I need to change my password?

That's always a good idea.

Is the Web secure now?

Unfortunately, no. It's not just passwords that could be stolen, but also server keys. These are use to encrypt any data sent bettern web browser and web servers.

There are three ways those could be used. In the past, before we all learned about the issue and did something to fix it.

Retroactively. If someone recorded encrypted data in the past, and got access the secure keys now, they could decrypt all that data. This is something the NSA is fond of doing, but they're not alone.

Last, it's possible to use these keys in the future to masquarade a web server and pretend the communication is secure, while listening to all the traffic. It's hard to do, but not entirely possible.

Anything else I can do?

Not really, except watch the news.

So this is still a problem?

I told you not to read this FAQ.

What's Vulnerable?

The Heartbleed Hit List: The Passwords You Need to Change Right Now Green checkbox means go change your password right now.

Heartbleed test tests if your server is vulnerable. You can also download the code and run it from the command line.

Testing for "reverse" Heartbleed The team at Meldium checks if you can use Heartbleed to steal data from clients using OpenSSL (e.g curl). Turns out you can. brew upgrade openssl on your Mac.

The Heartbleed Challenge CloudFlare sets up a challenge to determine if you can use Heartbleed to steal SSL keys from the server. Turns out you can.

What Broke?

Diagnosis of the OpenSSL Heartbleed Bug explains the bug and concludes:

Pay money for security audits of critical security infrastructure like OpenSSL

Write lots of unit and integration tests for these libraries

Start writing alternatives in safer languages

Re: FYA: heartbleed.com points out its not the language but the practice:

So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. …

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc. …

OpenSSL is not developed by a responsible team.

Anything else?

The bug is fixed in all major distributions of OpenSSL. You may heard that the bug is fixed in the most recent version of OpenSSL (1.0.1g and upcoming 1.2.0). Some distribution still offer older versions of OpenSSL, but updated with the security patch.

Disable Segglemann's RFC520 hearbeat:

I am completely blown away that the same IETF that cannot efficiently allocate needed protocol, service numbers, or other such things when they are needed, can so quickly and easily rubber stamp the addition of a 64K Covert Channel in a critical protocol.

Secure storage of private (RSA) keys Akamai offers a patch offers a "secure arena" for storing RSA keys, so they're not vulnerable to Heartbleed, also locked into memory, kept out of core files.