Be Still my Bleeding Heart …

“Secure web servers are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police.” — Dr. Eugene Spafford, (Web Security & Commerce, p9, O’Reilly, 1997, S. Garfinkel & G. Spafford)

The aptly named Heartbleed bug has become the talk of the town in the mainstream media. It had to happen at some point. After all, people were growing bored with bitcoin news which seemed to have settled into a stream of scam reports, evangelicals claiming it is the new gold rush and skeptics claiming it is nothing more than tulip mania redux.

While the Heartbleed bug was originally reported on December 3, 2013, it was a website by the same name, created on April 5, 2014, that finally ushered it into the media spotlight.

So, what exactly, is Heartbleed, and why do (or should) we care? To better understand the situation as well as the potential impact, a short history walk is in order.

In February of 2012, a request for comment (RFC 6520) was proposed for providing a means to allow the use of keep-alive functionality within the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. This proposal was called the “Heartbeat” extension. It was within this extension that the Heartbleed bug was found.

And what is this bug?

In basic terms, the “Heartbeat” extension returns the number of bytes (payload) as requested by the client, without first determining if the payload exceeds the actual number of bytes sent by the client. If the number of bytes exceed the client request, the result extends past the buffer boundary, thereby sending data residing at that boundary, back to the client.

So, for example, the client sends a heartbeat request containing 2 bytes of data, while claiming the message payload is 65536 bytes. The heartbeat extension would then return the 65536 bytes of data, as opposed to the initial two bytes, thereby responding with data that could be anything from pure gibberish, to customer data, such as usernames/passwords, credit card information, private messages, email correspondence, or in some cases, the server’s private SSL key. It really depends upon what resides in the memory at the breached buffer boundary, as well as the server’s primary function (i.e., a subscription news service, email service provider, social networking site, ecommerce site, bank, etcetera).

Sidenote: for the tldr; crowd, here’s an xkcd cartoon that demonstrates how this bug can be exploited.

While this bug has existed for a little over two years, the likelihood that consumer data (or even a server’s private keys, for that matter), was compromised is arguably quite negligible. Negligible, is, of course, relative. Even if only 1% of the servers containing the bug were compromised, that would still mean that we’re looking at approximately 5K potentially compromised servers (based upon reports that more than half a million sites have been affected by this bug). Out of these proposed 5K compromised servers, the probability that the server returned relevant data (i.e., private user data and/or private server keys) is, again, arguably negligible. This is due to the fact that thousands of heartbeat requests would be required to return even a minuscule amount of relevant data. That, and the relevant data would have to be sorted from the gibberish that was returned.

This is not to suggest that it cannot be done. However prior to the notification of this bug the likelihood that this bug was being exploited is miniscule. This has now changed. The probability of risk of data loss increases exponentially now that the information regarding this bug has been widely disseminated. That is, for those sites who have yet to patch their servers with the since released OpenSSL update as well as updating their SSL keys.

And this is what has people up in a dander. Various security pundits are urging users to change their passwords as other parties scour and list vulnerable sites. And yet others are alleging the bug was deliberate. Highly doubtful on that last bit. Memory leaks in code can and do occur. Unfortunately, all too often. And code reviews will not necessarily catch them. As proven in this case.

While it is still too soon to know the damage wreaked by this particular bug, this too, shall pass. Though, it will doubtfully go quietly into the night. Rest assured however, another bug will come along that will make this one look benign. The future bug will likely involve a massive data breach within the cloud space. Why? Because, although the cloud is convenient, it is just begging to be hacked. Data is, after all, the new gold. And solid security protocols require much, much more than sound code impls and hardened firewalls.

They require support personnel who do not divulge user data during customer calls, IT admins who do not hand out passwords just because a user claims they lost theirs, office workers who do not lose laptops or usb drives containing sensitive customer data, while on business trips, employees who do not visit pr0n sites and/or download attachments, while at work, resulting in internally infected networks. And, last but certainly not least, it requires end users who have taken the time to educate themselves with regard to practicing their own security protocols.

Sound security protocols are, of course, moot, in the case of this particular bug. That is, from the user standpoint. As for the companies? They’ve been handing out our data for years. Freemiums after all must be paid for by someone. Nevertheless, and as it stands today, hackers do not require bleeding hearts to get at user data. And just perhaps, after a few more serious data breaches, or arguably, as in this case, data breach scares, people just might get a clue or two or ten with regard to how truly insecure their data actually is. That, or they’ll get lulled back into their false sense of security as the specter of this particular bug becomes a distant memory.