Yesterday, researchers from Google and Codenomicon made quite a splash when they revealed details of a vulnerability in OpenSSL's implementation of the heartbeat extension, which they have affectionately dubbed heartbleed
. In short, heartbleed represents a classic example of a simple programming oversight - not properly validating the length of a message, which leads to a serious memory leak.
Why is this such a big deal?
Breadth and depth
- Heartbleed impacts the most common implementation of SSL/TLS (OpenSSL), which is used on the majority of web servers. In fact, according to Netcraft
, in April 2014, Apache and nginx, two of the most popular web servers that both include vulnerable Open SSL implementations, account for 66% of active web servers. As for depth, the impact of the vulnerability is significant and trivial to exploit. A simple request will return up to 64 KB of random data from server memory. This data could include extremely sensitive information such as private encryption keys and authentication credentials. To make matters worse, there are no logs of such requests, so a victim won't even know that they were attacked and the exploit can be sent over and over, retrieving new data every time.
How does it work?
The heartbeat extension is defined in RFC 6520
and was added to the TLS protocol to provide a simple means of keeping a TLS session alive. Think of it as a small packet that the client sends to the server to let it know that it's still around. The problem occurs, because that simple packet includes the length of the payload that it's sending, which isn't properly validated. If the actual payload is smaller that the payload length value, the server will return random data from memory to fill the void. There is already plenty of PoC exploit code for this vulnerability readily available on the web if you want to test your own servers. Let's break down a sample heartbeat request to illustrate the vulnerability (some hexadecimal values have been converted to decimal in the description).
|18 03 02 00
0A 01 40 00 4D 49 43 48 41 45
|#1| #2 | #3 |#4| #5 | #6 |
#1 - Type = 24
#2 - Version = 0x302
#3 - Data length = 10 (#4 + # 5 + #6)
#4 - TLS1_HB_REQUEST
#5 - Total payload length (16,384 bytes)
#6 - Data ('MICHAEL')
In this example, the data length is 10 bytes, while the total length of the payload is set to 16,384 bytes. Due to improper bounds checking, the server ultimately returns both the data sent in the heartbeat request, along with whatever else happens to come after it in memory. In the screenshot below, you can clearly see the heartbeat payload ('MICHAEL') sent to a vulnerable server, is followed by random browser headers - likely from a recently requested webpage on that server.
|Data leakage from a web server vulnerable to the OpenSSL 'heartbleed' attack
This is a serious threat. Use freely available tools such as this handy web app
to quickly check your servers to determine if you're vulnerable. If you are, either upgrade OpenSSL to 1.0.1g or recompile your existing OpenSSL version with -DOPENSSL_NO_HEARTBEATS compile time option.