Heart Bleed Bug in openSSL

[Rajesh Martin]

How to rectify the heart bleed bug in the openSSL

[Jaikiran Pai]

Rajesh, welcome to CodeRanch!

There's already a discussion going on about it here https://coderanch.com/t/631935/Security/Heartbleed-Bug-vulnerability-popular-OpenSSL. Apparently, you have to upgrade the library version to fix it.

[Ulf Dittmer]

Upgrading the library is the first step. For a public web server, changing the private keys and SSL certificates would be next, but not necessarily last. Other software that incorporates OpenSSL (SSH clients, VPN clients etc.) may also need updating.

[Warren Dew]

I thought I understood the bug, but the I realized I still had a question about it. So the client sends a length for the heartbeat, then sends data. The bug is what happens when the data is shorter than the length. But why doesn't the server wait until the full length worth of bytes comes through? Why does it echo the heartbeat when, from its point of view, it doesn't have the full heartbeat yet?

[Bear Bibeault]

Today's xkcd explains it well:

[Warren Dew]

It's a good basic explanation, but it doesn't answer my question.

[Bear Bibeault]

It's not a matter of the server waiting for anything, but of sending as much data as is asked for regardless of whether it should or not, thus sending the data that it has in memory.

In the last panel, the server should be saying "500! Are you insane? No way!"

[Warren Dew]

But how does the server know that the client has finished sending the data? If it has been sent a length of 500, why isn't it waiting until 500 bytes come in?

Is the length sent by the client redundantly? If so, it sounds like the real bug is in the TLS spec.

[Bear Bibeault]

The 500 bytes aren't going in, but going out.

[Warren Dew]

The bytes going out are supposed to be a copy of the bytes going in. That obviously means that the server must receive the bytes before it can send them back.

In the XKCD example, how does the server decide to send something back after it has received the 3 bytes of "HAT"? Why did it wait until it received 3 bytes - why didn't it stop at 2, or 1, and allocate and send back the buffer starting with just "H" or "HA"? The server must know somehow that the actual data length is only 3, as opposed to 500, to know to reply after 3 bytes, even if it mistakenly uses the 500 for the amount of memory to put in the reply.

But hey, I decided to look it up myself in RFC 6520. It turns out that the client does provide the length redundantly, just as I suspected. There is a length defined for the overall message, and then within the message, there is a length defined for the payload of the message, with the remainder presumed to be padding. It's this defining of two dependent lengths that allows the client to send inconsistent lengths to cause the bug.

RFC 6520 even explicitly warns against this bug:

"If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently."

[Bear Bibeault]

Good research!

Have a cow.