Heartbleed

[Former Member]

It's the month of April, but sometimes things are apparently less inclined towards humor. This month we witnessed a severe setback to the most (well.. almost) popular open standard for implementing internet traffic obfuscation i.e. OpenSSL.

Introduction

To put it straight, all traffic transmitted over HTTPS is encrypted. HTTPS is not a separate protocol, it rather is HTTP running over SSL/TLS. SSL stands for Secure Socket Layer and TLS stands for Transport Layer Security. Technically, they do NOT mean the same protocols. TLS could be considered as the worthy successor of SSL.  SSL had its own idiosyncrasies and many enhancements were made to it which forged the path to TLS. OpenSSL is the most popular open-source implementation of SSL/TLS protocols.

SSL/TLS and Cryptography

SSL/TLS works using a combination of Public-Key/Asymmetric-Key and Symmetric-key cryptography. This former technique uses a pair of distinct keys, one for encryption and other for decryption while the latter uses the same key for both encryption and decryption purposes. Popular algorithms for generating distinct key-pair are RSA, DSA etc while AES, Blowfish etc. are used for symmetric key cryptography. The process could be listed:

1. User accesses a website over HTTPS
2. The web server provides a digital certificate (usually a X509 certificate) containing information related to the version, provider, hash algorithm (SHA1, SHA256, MD5 etc.), asymmetric Public key etc. to the browser.
3. Now the browser creates a symmetric key (which would be used to encrypt/decrypt data) and then uses the Public key provided to encrypt the symmetric key generated and sends it to the server.
4. Server possesses the corresponding Private Key which it then uses to decrypt to get the symmetric key. Henceforth both the parties use the symmetric key to encrypt/decrypt information.

Keep-Alive Connections

HTTP/1.1 introduced the concept of persistent connections or Keep-Alive connections. This allows the client to reuse a TCP connection multiple times to fetch resources from the server i.e. a connection is not terminated upon obliging the request.

However the benefit is more palpable when requests are rendered over SSL/TLS. Such requests need a SSL/TLS handshake before exchanging information with the server which is a costly affair. Hence if we could reuse such an established connection, we would forgo the handshake rigmarole and continue with the communication.

Heartbeat extension

The Heartbeat extension in TLS allows the usage of Keep-Alive connections. Although TLS is built on reliable data transfer protocols, but the way it works is that a TLS session is setup the moment a connection has been established and if there's no evident continuous communication between the peers for some definite length of time, the session is terminated. Hence, to overcome this situation, the extension provides the peer with the provision of sending HeartbeatRequest messages to which the other peer must respond with  a HeartbeatResponse message.

Failure of the response messages could mean that the destination peer is either shutdown or temporarily unavailable which would then lead to the session termination.

The Attack

A typical HeartbeatRequest message reaches the destination peer via an SSL3 record which contains 2 fields:

1. payload - pointer containing the starting address of the arbitrary payload data sent by the source peer. The sent payload data is a structure of type HeartbeatMessage with certain attributes.

struct
{
   HeartbeatMessageType type;
   uint16 payload_length;
   opaque payload[HeartbeatMessage.payload_length];
   opaque padding[padding_length];
} HeartbeatMessage

          The payload_length attribute of the structure is the length of the payload sent (this value is controlled by the source                    peer).

     2. length - actual length or number of bytes present in the payload data(and some padding data) sent

The way the Heartbeat extension works is that it reads the HeartbeatRequest message, specifically the length property and reads out an exact copy of the payload back to the destination peer. Basically, the server starts at the payload attribute of the SSL3 record which points to the starting address of the payload data and then payload_length number of bytes are read from the server's memory and responded back to the destination peer.

The entire situation is compromised if the value of payload_length attribute doesn't match the value of the length attribute and Heartbleed is the specific use case when the former is much larger than the latter.

A malicious example

Since the payload_length attribute is controlled by the peer, a malicious user could cook a contrived request such as:

HeartbeatRequest message

Payload:

Type	payload_length	Payload data
Request	1000	10 bytes

Length:  13 bytes

Now, when the destination peer/server reads the payload, it finds that it needs to send back 1000 bytes back to the source peer. So it starts with the starting address of the arbitrary payload (of actual size 10 bytes) and reads 1000 bytes of the server's memory and responds back to the destination peer. Ideally it should have responded back only 10 bytes. Thus the source peer is actually receiving 990 bytes of unauthorized data.

HeartbeatResponse message

Payload:

Type	payload_length	Payload data
Request	1000	1000 bytes

Length:  1003 bytes

So, basically the issue arose because the payload_length value was never checked against the length attribute which caused excess memory pop from the server. A very short and informative XKCD webcomic related to this, could be found here.

Implications

Now the maximum limit to which we could cause this memory overflow is 64K. That's a sufficiently large number to include very sensitive data like usernames, passwords, X509 certificate Private keys (used to decrypt encrypted messages) and transferred back to the malicious user. Once the malicious user gets access to the Private key, all sensitive information is compromised.

Heartbleed Fix

The fix for Heartbleed bug has been circulated and is in operation. The fix just included the necessary check of the payload_length attribute against the length attribute. Not all versions of OpenSSL were compromised, only the version 1.0.1 to 1.0.1f were vulnerable. For, further information, visit www.heartbleed.com.