Heartbleed

CVE-2014-0160

Why Heartbleed?

The bug exists in the heartbeat extension of OpenSSL's TLS/DTLS implementation. When exploited it leaks memory contents.

What Makes Heartbleed Unique?

Bugs can come or go in versions of software and have varying impact. The Heartbleed bug left private keys and other data exposed across the internet. The exposure period was quite long, and attacks leave no trace.

History

Creation

The bug was introduced by Robin Seggelmann and reviewed by Stephen Henson, who missed the bug and committed it to the OpenSSL repository on December 31, 2011. The affected version 1.01 was released 14 March 2012. Since the extension was enabled by default, all equipment running the vulnerable version was affected.

Discovery

Neel Mehta of Google's Security team reported the discovery of Heartbleed to OpenSSL on 1 April 2014. Codenomicon discovered the bug on 3 April 2014. Approximately 17% of servers were estimated to be vulnerable to the bug.

What is Heartbleed?

Heartbleed is a vulnerability in OpenSSL cryptographic library. Heartbleed allows anyone to read the memory contents of a server using a vulnerable version of OpenSSL.
This could potentially be one of the worst vulnerabilites found since commercialization of the internet.

Behavior

Heartbleed may be detected using a simple test. During normal usage, a TLS/DTLS handshake. The computer at one end sends a heartbeat request to the server. The request consists of:

The server then responds with the exact same payload to the sender.

Affected versions of OpenSSL create a memory buffer for the message based on the request, regardless of the payload's actual length. Because of this failure, the server is vulerable to a form of buffer overflow.

An attacker could send a request for a message, such as "bird", of length 500. The server will then respond with "bird" plus the remaining memory location past the end of the desired payload.

Impact

Client side vulnerability

Malicious servers could send a request to clients using vulnerable versions of OpenSSL, reading the contents of their memory buffer. This could lead to the leaking of usernames and passwords.

Affected Systems

Operating systems were also affected.
These include Debian and deriviates Mint and Ubuntu, Red Hat Enterprise Linux (RHEL) and deriviatives, Android, DD-WRT (base for many router firmwares), and others.

Servers

Most notably among the affected software is Apache and nginx. Combined, these two server packages held 66% of the active sites on the internet in 2014.

Certificates

Remediation

Patching

Vulnerability to Hearbleed is fixed by updating to OpenSSL version 1.01g or later. Programs that statically linked ot the OpenSSL library would need to be restarted.

The patch is quite simple:

if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */

Certificates

Certificates had the potential, along with private keys to be leaked from memory. Server administrators should revoke any X.509 certificates on affected machines and issue new ones after patching. Key pairs would need to be regenerated. Credentials shoould also be changed. Even signatures made with potentially compromised certificates are drawn into question.

OCSP Certificate lists should be updated, as browsers shipped with lists might not be updated and would remain compromised until the certificates expired or the vendor updated the lists in browser.

Lessons Learned, Causes, and Reactions

Cost

Eweek estimated the cost of Heartbleed to be $500 million.

Globalsign's Certificate Revocation List (CRL) grew to 4.7MB from 22KB over four days following the discovery. CRL downloads generated 40Gbps of traffic across the internet.
Assuming $10/Mbps average in 2014, just these additonal CRL downloads would have cost Globalsign $400,000USD for the monthly bill. (cloudflare.com). The cost of this using AWS infrastructure would be $952,992.40/month (in 2014).
Revoking certificates also has the cost of risking a denial of service for those who do not have the updated lists.

Testing

Possible solutions include:

Staffing

OpenSSL was maintained by a team of two fulltime individuals. Software used in securing the majority of the internet was relegated to a handful of volunteers to maintain over 500,000 lines of code.

As OpenSSL was integrated into a staggering amount of the internet, the reliance on a package maintained by so few people is concerning. Open source software undoubtably has benefits. But we must keep in mind who is developing the packages, what the dependencies are, and how security conscious the contributors are. One bad actor could easily slip in an unnoticed exploit and compromise multiple targets.

Reactions

The OpenBSD and OpenSSH team forked OpenSSL into LibreSSL. They removed over 90,000 lines of C code in the first week. The library was critized for having a lack of security conciousness. We must address the issue of software economics. Often open source software is a passion project or ran by non-profit organization. After the discovery of Heartbleed, the organization asked for donations. The donations totaled $841 after 2-3 days. The bug bounty claimed by Neel Mehta was $15,000. This disparity must be addressed and critical software properly funded and audited. If steps are not taken, it is not a matter of if a another heartbleed level exploit will occur, but when.