Six Lines


Posted by Aaron Massey on 10 Apr 2014.

Quite a few people have contacted me with questions as to what they should do about Heartbleed, so I thought I would write some advice for a general audience to share.

What is it and how does it work?

I’m basically not getting into that since this question has been answered elsewhere. I like Timothy B. Lee’s answer on Vox.

What should I do about this?

The link in the previous question doesn’t address this because it’s basically impossible to give a definitive answer to that question. The nature of the bug means that it will affect different sites differently. Obviously, this isn’t helpful to people who are just interested in doing what they can to mitigate Heartbleed’s effects for them.

Mashable has a great checklist of popular websites, whether they have been affected, and what users need to do in response. If you’re just interested in knowing whether “the Internet is fixed” then is the website for you. If you’re more technical or if you run your own website that uses SSL, then you should check out Ed Felten’s advice. Brian Krebs also has a list of things you can do.

Worst bug ever, right?

No. If you want an existence proof, I think the protocol-level DNS flaw Dan Kaminsky found in 2008 is both more serious and more egregious than Heartbleed. It basically reduced the “trustable” Internet to any website you visit by typing in an IP address rather than a domain name.

Another bug that might legitimately be considered more serious and more egregious than Heartbleed is the Firesheep bug. This was an HTTP session hijacking bug and the name of a Firefox plugin that could exploit it. Most crimes are committed by people the victim knows. Since Firesheep allowed session hijacking surreptitious session hijacking over WiFi, it opened up a lot of people to some serious session hijacking. By comparison, you need to have some pretty serious technical skill to exploit Heartbleed. Obviously, it can be done, but we’re talking about organized crime rather than script kiddies, friends, and family.1

Picking a “worst bug ever” is over-simplifying quite a lot of security and privacy engineering. For example, it’s entirely fair to say that the most serious, most egregious problems we’ve seen haven’t really been technical problems. Data breeches, like the Target data breach I mentioned before,2 are arguably more damaging than Heartbleed. It’s more clear that valuable data is at risk. The data that was exposed is also more obviously exploitable. Yes, Heartbleed could be worse, but how do you even measure that sort of thing? Attempting to differentiate massive security failures or rank them using some objective metric isn’t easy and probably isn’t fruitful either.

This is a serious bug, and it deserves massive amounts of attention. However, it’s not clear how to compare this bug with other serious bugs. If we were collecting security failures to use in a classroom setting, as Arvind Narayanan did for ethical dilemmas, then this is clearly a candidate. Beyond that, ranking these things may not make much sense.

What’s the big deal?

To me, the truly interesting differentiator for Heartbleed is the branding behind it. One of the most challenging things about security and privacy is informing the public about the severity of problems when they occur. Some bugs require immediate responses from people who aren’t tech savvy, don’t care about security or privacy much, or are otherwise unaware or uninterested in the latest security bug or privacy breach. Heartbleed’s approach to solving this problem was to register a domain, create a controversial logo, and build a cleanly designed page with answers to some basic questions about the nature of the bug.

A perfect encapsulation of the Heartbleed approach is the name ‘Heartbleed’ itself. Where does that come from? Well, the custom website about the bug has an answer for you:

What is the CVE-2014-0160?

CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by MITRE. Due to co-incident discovery a duplicate CVE, CVE-2014-0346, which was assigned to us, should not be used, since others independently went public with the CVE-2014-0160 identifier.

Why it is called the Heartbleed Bug?

Bug is in the OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server.

Why use that nasty, hard-to-pronounce CVE number when you can create something reminiscent of the bygone days of the ILOVEYOU virus or the Code Red worm?

Although it may seem silly to old school hackers, the Heartbleed “marketing” is important and valuable. Clear communication about security and privacy isn’t easy, and mistakes can be extremely costly. I have seen way too many tweets and posts from otherwise respectable security researchers who feel that the Heartbleed branding was either unnecessary or over the top. I don’t agree. The marketing and branding may not have been perfect, but it’s way better than nothing. For bugs as serious as this, it’s important that technically oriented researchers control the message, which is exactly the goal of marketing and branding.

The alternatives are all worse. Letting the media and the Internet shape the message entirely is how we end up with frivolous contests and comparisons of what is the worst bug of all time. This is how misconceptions spread. Heartbleed is a great example of this because from a user perspective, it really isn’t clear what a particular user should do in response. Without clear communication either (1) the seriousness of the bug would be lost in the conclusion that end users don’t need to do anything in response, or (2) the widespread and open-ended nature of the bug would drive some strange techno-panic. Bugs this serious need branding and marketing to ensure they are properly understood and addressed.

  1. Obviously, there’s more of a debate about these sorts of tradeoffs than I’m presenting here. It’s not really my goal to get into these comparisons in this post, but I might do so in the future. 

  2. Yes, I know there was malware involved in the Target data breach. However, the initial intrusion was a HVAC system contractor. For me, that’s game over. If an intruder gets physical access to your systems, I don’t think of this as a “technology” problem.