You've heard about the Heartbleed vulnerability in OpenSSL, you probably have had to deal with its consequences - but perhaps you don't know just how old fashioned a bug it is. 

OpenSSL is just one implementation of the protocol but it is very widely used because it is open source, therefore low cost and trustworthy. This is the reason why there is so much fuss about it.

Microsoft must be truly happy that it hasn't as yet swallowed the whole open source pill because its implementation of SSL doesn't have the same flaw - it probably has other flaws but that's another story.

So what is the bug that allows the Heartbleed attack. 

Simple - buffer overrun.

At its simplest a buffer overrun involves provisioning a buffer of size x Bytes and then using x+1 or more Bytes - i.e. reading or writing off the end of the buffer. 

If you work in a language that looks after memory management for you then you probably are even more incredulous that such a thing can happen. After all if you allocate a buffer of size x and try to access element x+1 the system will complain - either a runtime error or an exception will be thrown. Whatever happens next it is sure that you will not access memory beyond the last element of the buffer. This is what managed code is all about. Languages such as C and C++ are not managed in this sense and they do allow, if allow is the right word, to read and write beyond the end of a buffer. 

Why you may ask?

The simple answer is because the code with no buffer overrun checks is faster and because sometimes clever, if clever is the right word, programmers can make good use of it. 

However in this case managed code wouldn't necessarily save the day because the flaw in the code was at the logic rather than implementation level. That is the Heartbleed bug isn't a simple buffer overrun.

In the case of the SSL bug it all relates to the heartbeat protocol. To keep an SSL connection open clients can send a heartbeat packet which in principle carries no data and just acts as a "I'm still here don't disconnect" signal. The heartbeat routine however takes the data sent by the client, stores it in a  buffer and then sends the data back to the client - why this is done isn't obvious.

Perhaps sending the data back in response to a heatbeat was the first mistake. 

Now you can see what might go wrong here.

The heartbeat routine uses the client's declared size of the packet to provision the buffer and to send the buffer back - without checking that the value supplies really is the packet size. 

So the attacker sends a 1 byte packet but claims it is 64K in size. The program allocates a 64K buffer, copies one byte into it and then copies the entire buffer back as the return packet. The attacker gets their one byte back and whatever was in the rest of the allocated buffer before it was allocated,  i.e. nearly 64Ks worth of snooped data. 

As the memory is allocated on the heap using the c malloc routine there is even the possibility of scanning larger areas of memory by making multiple requests that acquire buffers in different areas of the growing heap.

Would a managed language have protected us from the error?

Yes, but only if it initialized arrays to their default values.

In this case the problem isn't a simple buffer overrun because the buffer's bounds are not actually breached - the program asks for a 64K buffer and uses a 64K buffer. The problem is that only the first byte is set to a new value and the buffer isn't initialized so as to wipe any data that might have been stored in the area of memory it occupies.

Not initializing a buffer is something that saves time, just like not checking bounds, and it can even be used for some clever programming techniques where a buffer is allocated over existing data. 

Managed languages, C#, Java, etc,  generally do initialize arrays to the default value for the type, but the rules for this can sometimes be complicated when you move away from simple arrays of static type - so even here you have to be cautious.

If you need to know more about the Heartbleed bug - what exact SSL implementations it is in and how to put it right - then visit Heartbleed.com, or one of the many other sites offering advice. 

What seems very likely is that there are other similar bugs that are in other "well crafted" implementations of security protocols. I wouldn't be too smug if I were Microsoft or in charge of any other SSL implementation.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info