HeartBleed: what it really is (or was)

You will read that HeartBleed is a bug in OpenSSL, which is correct. You will then be told that it’s a security flaw – which is technically incorrect.

Unlike the deliberate weakness inserted by the NRA into encryption’s choice of random numbers, making them less random, the HeartBleed bug was a simple dumb coding error.

Some peer-to-peer connections need to be assured that the other party (computer, actually) is still ‘there’ in the internet-available sense. To do this, there is a ‘Heartbeat’ protocol which works approximately like this:

A sends to B a message which says: here’s some data, and its size. Here’s some padding, and its size. Send me back the same data, at this size.

B is then supposed to respond with essentially a copy of A’s data. A then knows that B is there and is listening.

The Bug: in some versions of OpenSSL, this protocol was implemented such that, if A requested more data from B than A actually sent, B would respond with A’s data, plus adjacent memory contents, up to the size requested.

This is a simple coding flub, mildly analogous to stack overflow. Whenever asked, B would show A up to some 64KB of data that happened to be next to A’s input storage memory.

Once this was known, sites with sensitive data were forced to close. (At least, sensible sites with sensitive data. Others kept open, knowing that a hacker could be looking at their computer’s memory contents.)

In Canada, the CRA (tax department, eh?) shut down until the bug could be fixed.

You will read that information can be stolen without trace, which is almost incorrect. First, websites can and do keep a log of all traffic, coming and going. Thus it is possible to find all the heartbeat requests and responses, and detect those that were for extra data, and inspect those packets for sensitive information. CRA did this and found that some 900 SINs had been accessed.

In addition, since the attacker needs to get the data back, his/her IP address must be in the heartbeat request. Thus CRA (possibly with some help) was able to track the attacker’s IP address. In the case of a provider like Rogers Cable, that IP address maps to a single cable going into a single location. The hacker has been arrested.

(There is a way around this difficulty, using a service such as TOR. But I’ll bet they notice obvious multiple repeated hacking attempts, as their stated intent is merely to prevent correlation of requests as a tracking service for governments and agencies such as NRA.)

Now for some observations.

It has been claimed that the NRA was aware of this and used it for the two years that the bug was in effect (for specific versions of OpenSSL). I believe this is a credible statement.

It has been noted that two sets of people detected the bug at about the same time. I find this fascinating.

If you google Heartbleed shutdown, you’ll not find much. CRA shutdown, of course, and a claim that

Communications Security Establishment Canada says it learned of the Heartbleed bug a full day before a federal government public warning went out and parts of the Canada Revenue Agency website were temporarily shut down.

You can find this here.

A quick search on BBC News for Heartbleed shutdown found little. Very few sites, it appears, were as thoughtful as the CRA. Many warned of slowdowns while servers had code updated. (Apparently, it’s one line of code and some sites can’t easily update that and compile and test it. I remember being iteration manager at a major bank’s development project, when we sometimes did over three thousand Cobol compiles overnight. Maybe the CRA should hire me to audit their code management practices, eh?)

So. The bug should be fixed everywhere now. Not all sites had the bug version to start with. Not all sites were attacked. Not all sites are checking their logs to find out if they were attacked. CRA shut down when informed. CSEC didn’t bother informing them for a full day.

Net net: if you were unlucky, and your information was in memory on a site with the HeartBleed weakness, your information could be in the hands of anyone hacking that site while your information was in memory. It is not clear why it would be, unless you were active on the site at the time, or your information was ‘in the same cluster’ as someone else’s information, and that someone was active on the site at the moment of the heartbleed request.

Comments? Did this help, at least a bit?

Leave a Reply

Your email address will not be published. Required fields are marked *