The heartbleed bug has been in the news lately. Rightfully so; it’s a pretty big deal, at least in theory. How much damage is practically possible and how much damage may have occurred is unknown so far. But the potential security hole is enormous!

Two things really stand out about this bug: Firstly, attackers get (potentially) vast amounts of internal computer data while leaving no record. Secondly, the bug is a simple error caused by, metaphorically speaking, not looking both ways when crossing a one-way street.

The description in the initial announcement sounds unassuming:

A missing bounds check was found in the way OpenSSL handled TLS heartbeart extension packets. This flaw could be used to reveal up to 64k of memory from a connected client or server.

But the consequences are pretty major!

Here’s an excellent description for non-experts, and here’s one for coders, and here’s another. I’ll assume you’re no more likely than I am to follow reference links immediately, so following is a very brief description of the bug. See one of the links for details (the latter two include source code).

Briefly and generally, when online in an https session (note the “s” for secure), a browser (or other client software) can send a “heartbeat” to the server over their secure link. The heartbeat says, “Here's 10 bytes of data.” All the server has to do is copy back those 10 bytes. It’s a way for the client to insure the server is alive, paying attention and that the secure channel is working.

The bug is that if the client says, “Here's 64,000 bytes of data” — but only sends one byte — the server still returns 64,000 bytes of data! It returns the one byte it was sent plus the next 63,999 bytes that happen to be in memory at the time!

And because the heartbeat function takes place at a low level, it’s not logged or monitored by the protocol stack. The heartbleed attack is invisible to the server!

So you put those two together and you get an invisible attack that exposes large chunks of internal memory. If the platform and software are known, attackers can sift through the dumped memory looking for data structures or other tags they can identify. Those act as “Rosetta stones” allowing interpretation of data — such as site private encryption keys and passwords.

What makes this bug so egregious is that it results from trusting user input.

The incoming heartbeat packet said it had 64,000 bytes, so therefore it did, and crucial code treats what the user said as truth. That’s a huge no-no in software; you always validate any user input.

What’s astonishing is that user input would be assumed to be valid in a network context. Worse, a network context directly involving a security implementation! If there was anywhere you’d want to dot every eye and cross every tea, implementing secure network code would be at the top of the list.

In the comment section of the first linked blog article you’ll find a quote attributed to Doug Linder (I assume the Unix sysadmin in the Northeast, not the lawyer in the Midwest):

A good programmer is someone who always looks both ways before crossing a one-way street.

That’s a great quote, and it packs a lot of important viewpoint in a very pithy and memorable phrase.

Generally one is safe if one looks towards potential oncoming traffic when crossing the street. If traffic only comes from one direction, then presumably one is generally safe looking only that one way.

And — who knows — maybe 99.99% of the time, that works out great. No harm done.

But a good programmer approaches it differently. A good programmer reasons that, although it’s reasonable to expect cars from the expected direction, it’s not impossible that one could be coming the other way. While it may be a waste of time and effort 99.99% of the time, it’ll save you from a broken leg (or worse) that one time.

More importantly, perhaps, a good programmer places a high value on preventing that broken leg and considers it worth the (potentially usually wasted) double-check.

And the really good programmers? They look up, too! ‘Cause you just never know.

The point has been made that the affected library is open-source and lovingly maintained for free. That’s a valid point, and while it doesn’t make the bug less egregious or unforgivable, it does spread the blame around a bit and provide some food for thought.

There is the topic of commercial libraries and open-source libraries. If a financially successful website uses free open-source code, it would be nice to see them contribute to the development and maintenance of that code. It would certainly be in their best interests. A company with a large vested interest in a software suite might even consider taking it under its wing.  (I’m thinking about Oracle and Java, although I haven’t decided how I feel about that, yet.)

In the end I suppose it’s just one more place the interweb is truly changing how society operates. The combination of communications and computers is a game-changer on par with fire. The printing press was small potatoes in comparison!