he Heartbleed bug – Attacks on TLS Implementations

22.4.2 The Heartbleed bug

Heartbleed is the result of improper input validation – more precisely, a missing bounds check – in the OpenSSL implementation of the TLS Heartbeat extension. Technically, the bug is a buffer over-read, where an attacker can read more data than what was intended by the designer (see Figure 22.2).

Figure 22.2: The Heartbleed Bug (source: xkcd.com/154)

Listing 22.2 shows an OpenSSL version vulnerable to Heartbleed. The code stores the Heartbeat message type in unsigned short hbtype and increments pointer *p by one byte. It then calls the n2s() macro to write the 16-bit length of the Heartbeat payload into the payload variable and to increment *p by two bytes. Finally, pl is set to point to the payload’s contents.

Listing 22.2: The Heartbleed bug

   /* Read type and payload length first */
   hbtype = *p++;
   n2s(p, payload);
   pl = p;

   — snip —

   if (hbtype == TLS1_HB_REQUEST) {
       unsigned char *buffer, *bp;
       int r;
      /* Allocate memory for the response */
       buffer = OPENSSL_malloc(1 + 2 + payload + padding);
       bp = buffer;
       /* Enter response type, length and copy payload */
       *bp++ = TLS1_HB_RESPONSE;
       s2n(payload, bp);
       memcpy(bp, pl, payload);
       bp += payload;
       /* Random padding */
       RAND_pseudo_bytes(bp, padding);

If the received Heartbeat message has the type TLS1˙HB˙REQUEST, the code proceeds by creating a bp buffer of 1 + 2 + payload + padding bytes. It then sets the message type to TLS1˙HB˙RESPONSE and increments the bp buffer pointer by one byte. Finally, the code uses the s2n() macro to write the 16-bit payload length to memory, increment bp by two bytes, and copy payload number of bytes from the received payload (which is pointed to by pl) into the reply payload.

Recall that Eve controls the Heartbeat request message and, thus, can manipulate it at will. So, she can set the payload length – stored in the payload variable in the above code – to 64 KB but the payload itself – pointed to by the pl variable – to just one byte.

Because the vulnerable code in Listing 22.2 does not check the actual size of the payload in the Heartbeat request, the memcpy() function will read beyond the end of the received payload, thereby reading from the server process’s memory. This memory, in turn, holds sensitive information such as passwords, decrypted messages, or Alice’s private keys.

In other words, as illustrated in [200], whereas a benign Heartbeat request would ask Alice to return a four-byte payload, 0x01020304, a malicious Heartbeat request would ask her to return a 216-byte payload, 0x01020304, causing Alice to return 0x01020304 followed by whatever 216 − 4 bytes happen to be in her process’s active memory.

Even worse, sending a second Heartbeat message will read another 64 KB, thereby allowing Eve to repeat the attack and extract a large amount of Alice’s internal memory.