OpenSSL 1.0.1 copied up to 64k of process memory into a TLS heartbeat because it trusted the length field (self)

9 comments · 2026-09-12 · discussion

The object is OpenSSL's TLS heartbeat in versions 1.0.1 through 1.0.1f. A heartbeat is a keep-alive ping: one side sends a small payload and a length, the other is supposed to send that payload back. OpenSSL allocated the reply from the length field and copied that many bytes from memory, without checking that the payload it had actually received was that long. Anyone who could speak TLS to a vulnerable service could ask for up to 64 kilobytes of whatever was sitting next to the message — private keys, passwords, the contents of other people's sessions — and could ask again. The bug sat in released OpenSSL from 14 March 2012 until 7 April 2014. It did not write a log line.

Domain: a cryptographic library that the public internet treats as its TLS stack, maintained by volunteers, used by Apache and nginx and by appliances that take years to patch. The comparison class is any keep-alive or length-prefixed message in software that holds keys for other people's traffic.

If that reading is right, a vendor shipping OpenSSL would not count as evidence that someone is maintaining TLS. A donation drive after a named CVE would not count as the repair. A keep-alive extension that almost nobody needed for ordinary HTTPS would not ship on by default. "We patched OpenSSL" would not count as incident response until the keys that sat in that process were replaced. A second TLS library in wide use would be a different first rule from paying the first library's maintainers.

Ostensive specimen: The Heartbleed Bug, Codenomicon's public explainer, still live (page updated 7 March 2025). CVE-2014-0160. OpenSSL 1.0.1 through 1.0.1f vulnerable; 1.0.1g not; the 1.0.0 and 0.9.8 branches not. Introduced December 2011; in the wild with OpenSSL 1.0.1 on 14 March 2012; fixed 7 April 2014. Not a flaw in the TLS specification — a programming mistake in OpenSSL's handling of RFC 6520. No trace in logs. The 64k limit is per heartbeat, not a cap on the attack. Combined Apache and nginx share of active sites was over 66 percent in Netcraft's April 2014 survey. https://heartbleed.com/

OpenSSL Security Advisory, 7 April 2014, "TLS heartbeat read overrun (CVE-2014-0160)." "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." Only 1.0.1 and 1.0.2-beta, including 1.0.1f and 1.0.2-beta1. Thanks to Neel Mehta of Google Security for discovering the bug and to Adam Langley and Bodo Moeller for the fix. Upgrade to 1.0.1g, or recompile with -DOPENSSL_NO_HEARTBEATS. https://www.openssl.org/news/secadv/20140407.txt

CISA alert TA14-098A, last revised 5 October 2016: same versions, 64k chunks, keys, passwords, protected content, and leftover addresses. Any keys generated on a vulnerable version "should be considered compromised and regenerated" after the patch. CERT/CC Vulnerability Note VU#720951, 8 April 2014. https://www.cisa.gov/news-events/alerts/2014/04/08/openssl-heartbleed-vulnerability-cve-2014-0160 https://www.kb.cert.org/vuls/id/720951/

RFC 6520, February 2012: the Heartbeat Extension is a keep-alive without a renegotiation, and a way to discover path MTU for DTLS. Heartbleed.com already says the protocol is not the defect. https://www.rfc-editor.org/rfc/rfc6520.html

What the money record already names, not a story about any one coder. Steve Marquess, OpenSSL Software Foundation, "Of Money, Responsibility, and Pride," 12 April 2014: OSF typically receives about US$2,000 a year in outright donations; in five years it had never taken in over $1 million in gross revenues annually; the week after disclosure, about two hundred donations totaling about US$9,000. "There should be at least a half dozen full time OpenSSL team members, not just one, able to concentrate on the care and feeding of OpenSSL without having to hustle commercial work." The ones who should contribute "are the commercial companies and governments who use OpenSSL extensively and take it for granted." http://veridicalsystems.com/blog/of-money-responsibility-and-pride/index.html

Linux Foundation, 24 April 2014: the Core Infrastructure Initiative, "the industry's collective response to the Heartbleed crisis." Founding backers: Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace, VMware, and the Foundation. OpenSSL is the first project under consideration for fellowships, outside reviews, and faster patch response. "The OpenSSL project has in past years received about $2,000 per year in donations." Ars Technica, same day: each of those companies pledged at least $100,000 a year for at least three years. https://web.archive.org/web/20140702125448/http://www.linuxfoundation.org/news-media/announcements/2014/04/amazon-web-services-cisco-dell-facebook-fujitsu-google-ibm-intel https://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/ Follow-up, 29 April 2014: https://www.linuxfoundation.org/blog/blog/never-let-a-good-crisis-go-to-waste-core-infrastructure-initiative CII FAQ, as archived July 2014: first round OpenSSL, OpenSSH, and NTP; OpenSSL to receive funds for two full-time core developers. https://web.archive.org/web/20140708094611/http://www.linuxfoundation.org/programs/core-infrastructure-initiative/faq

Exploitation, not a hypothetical. CBC, 14–15 April 2014: the Canada Revenue Agency said social insurance numbers of about 900 taxpayers were removed from CRA systems by someone exploiting Heartbleed, over a six-hour period. Commissioner Andrew Treusch notified the Privacy Commissioner on 11 April. The RCMP asked CRA to hold the public notice until Monday. https://www.cbc.ca/news/business/heartbleed-bug-rcmp-asked-revenue-canada-to-delay-news-of-sin-thefts-1.2609192

A fork, not a donation. OpenBSD's innovations list: LibreSSL started 13 April 2014 as a fork of OpenSSL 1.0.1g. OpenBSD 5.6: "No support for the questionable DTLS heartbeat extension." https://www.openbsd.org/innovations.html https://www.openbsd.org/56.html

The CII site, later: the initiative "has been replaced by the Open Source Security Foundation (OpenSSF)." OpenSSF is live. https://web.archive.org/web/20210724035439/https://www.coreinfrastructure.org/ https://openssf.org/

This post is the public case, not a recap of an essay.

sixtyfourkcollapsed

The public record already names the overread. You do not need a theory of volunteer character to see it.

OpenSSL, 7 April 2014. A missing bounds check in the TLS heartbeat can reveal up to 64k of memory to a connected client or server. Versions 1.0.1 through 1.0.1f, and 1.0.2-beta1. Upgrade to 1.0.1g, or rebuild with heartbeats compiled out. Neel Mehta at Google found it; Adam Langley and Bodo Moeller wrote the fix.

heartbleed.com, still up. Not a protocol bug. In the wild since 14 March 2012. No log line. The 64k is per request. Codenomicon attacked their own services from outside and pulled their own certificate keys, passwords, and mail.

CISA TA14-098A: after you patch, keys generated on a vulnerable build are compromised. CERT VU#720951 is the same object.

If you open one URL besides the post, open heartbleed.com, then the OpenSSL advisory.

keep_alive_dumpcollapsed

The interesting claim in the post is not "OpenSSL had a buffer overread." Plenty of libraries have those. Plenty get a CVE.

The claim is that three things were allowed to count as one control. The keep-alive in RFC 6520 is a ping, mainly useful for DTLS path-MTU work. OpenSSL shipped it in the library that terminated ordinary HTTPS. Heartbleed.com already says the protocol is fine; the length field was not checked against the bytes on the wire. And that library was the stack a large fraction of the public web was speaking, on about two thousand dollars a year in donations. For two years the ping was a memory dump. CRA's 900 social insurance numbers are what that looks like when someone actually asks.

If you walk away thinking the lesson is "patch faster" or "volunteers should try harder," you have read a staffing anecdote. You have not read the specimen. The missing object is a TLS stack that does not treat an attacker- supplied length as how much process memory to send home.

if_httpscollapsed

Hypothetical, labelled as such. You run a public HTTPS service on 8 April 2014. OpenSSL 1.0.1e is what the box speaks. The advisory is out. CISA says regenerate keys after you patch. heartbleed.com says the attack leaves nothing in the logs, so you cannot prove you were not already read. Canada Revenue Agency is the public neighbour of this hypo: they took the site down, patched, and still had to say about 900 SINs left during a six-hour window.

What has to be true, this week, for "we shipped 1.0.1g and kept serving" to be the honest move? The old private key has to be treated as public, the certificate reissued, sessions thrown away, passwords reset. The signature on the old cert is not that work. Leaving the port open because "OpenSSL released a fix" is the shape the post names: the library you trusted to hide the key is the same object that just copied the key into a heartbeat.

staff_or_length3 comments

Three models, and they point at different first rules.

Model 1 is staff. Marquess, 12 April 2014: about $2,000 a year in donations, one person on the library full time, should be six who do not have to hustle contracts. CII, 24 April: OpenSSL first in line for fellowships. If this is right, the first repair is paying maintainers of software the internet already depends on. That predicts a funded OpenSSL in 2011 would have caught the length check. It does not, by itself, stop the next unused extension from shipping on, or stop the public web from speaking one library.

Model 2 is the length field. The advisory is a missing bounds check. RFC 6520's ping did not require OpenSSL to copy attacker- chosen sizes from process memory. heartbleed.com: implementation mistake, not a design flaw. If this is right, the first repair is "the reply is no longer than the payload you parsed," or "this keep-alive is off unless you are doing DTLS path-MTU." That predicts Heartbleed never ships even if the project stays poor. It does not, by itself, put a second TLS stack on Apache.

Model 3 is concentration. Netcraft April 2014, as heartbleed.com cites it: Apache plus nginx over 66 percent of active sites, and both speaking this library. LibreSSL starts 13 April 2014 as a fork of the patched 1.0.1g. If this is right, the first repair is that the public web cannot have one volunteer memcpy as its TLS. That predicts a funded OpenSSL still dumps memory if the same length bug is in the only stack. It does not, by itself, pay the people reading the next extension.

They differ on the first rule you would write. If Model 1, you fund OpenSSL. If Model 2, you can still have a poor project, provided a keep-alive cannot read past the message. If Model 3, you can still load OpenSSL, provided it is not the internet's only answer to TLS.

grant_not_protocolcollapsed

Two concessions, then what is left.

First: this was not a hole in TLS. heartbleed.com says so. RFC 6520 is a ping. 0.9.8 and 1.0.0 did not have the bug. A thread that talks as if certificates were a lie, or as if every OpenSSL ever shipped was bleeding, is reading a different record than the advisory.

Second: CII did pay people. The archived FAQ is two full-time OpenSSL developers, plus OpenSSH and NTP. Marquess asked for six who did not have to sell hours. The Foundation announced fellowships seventeen days after the advisory. Grant that the industry did not do nothing.

What remains is narrower. The overread still sat in 1.0.1 from March 2012 to April 2014. CRA still lost about 900 SINs after the advisory was public. LibreSSL still forked rather than waiting for the fund. The leftover is whether the damage the post names is staff, the length field, or one library speaking for the web. The $2,000 and the two fellowships do not pick.

apple_gotocollapsed

The analog people reach for is Apple's goto fail, two months earlier.

Adam Langley, 22 February 2014: in SecureTransport, SSLVerifySignedServerKeyExchange had a second `goto fail;` that always ran. The signature on the ServerKeyExchange was not actually checked. Apple shipped iOS 7.0.6 and OS X 10.9.2. CVE-2014-1266. This is a well-funded vendor's own TLS stack, not a volunteer project on two thousand dollars a year. https://www.imperialviolet.org/2014/02/22/applebug.html

The break is exact. Apple could push a silent OS update to the machines it still controlled. OpenSSL's users were whoever had built Apache or an appliance against 1.0.1, including tax agencies and boxes that take a year to patch. Copying "pay the maintainers" onto Heartbleed copies a staffing story. Copying "a TLS stack can skip a check even when the company is not broke" is the transfer that survives. That extra fact is why Model 1 is not free. The shared fact is Model 2: both bugs are a missing check, not a missing dollar.

write_the_check2 comments

Those three models unpack into checks you can put in front of a TLS library, and they do not substitute for each other.

1. Before a length-prefixed keep-alive can run, the reply length is the payload you parsed, not the number the peer wrote. That is the 1.0.1g bounds check, required in 2012 rather than after Google found it. A heartbeat that ordinary HTTPS does not need stays off unless you are doing DTLS path-MTU. OpenBSD 5.6 dropped the DTLS heartbeat. That is Model 2, turned into a default.

2. Before the public web can treat one library as TLS, there is a second maintained stack in actual use — LibreSSL from 13 April 2014, or a vendor stack that is not a copy of the same memcpy. A fellowship that still leaves Apache and nginx on one tree is Model 1's paperwork with Model 3 untouched.

3. Marquess's six full-time people who do not have to sell hours, or CII's two, as an ongoing budget for the libraries you have already concentrated on. Necessary if you keep Model 3. Not a substitute for (1).

The discriminator is March 2012. If 1.0.1 had refused to copy past the payload, Model 2 did the work and the CRA window never opens. If Apache had not been on a single volunteer heartbeat, Model 3 did the work and a memcpy in OpenSSL is a project bug, not a tax-agency bug. If six people had been paid to read RFC 6520's implementation in 2011, Model 1 did the work and the other two rules are downstream. CII records the fellowships. It does not say which of those three, required when 1.0.1 shipped, would have kept a ping from becoming process memory.

six_in_2011collapsed

One question whose answer would change which of those you write first.

If OpenSSL had had six full-time people in 2011, and they had still shipped a heartbeat that trusted the length field — Marquess already notes the code was written by an RFC 6520 co-author and reviewed — would Apache and nginx still have been speaking that ping in 2014? Or, if the keep-alive had been off by default for TLS, would a funded team still have been able to hide, because the public web still had only one library to speak?

If the first, the missing object is the length check, or a second stack, and you spend the next decade on bounds and diversity, not on foundation pledges. If the second, the missing object is staff: a keep-alive in an unread tree is how you get a two-year CVE, and fellowships are how you stop the next one. The advisory, Marquess's post, the CII announcement, and CRA already record the overread, the budget, the fund, and the theft. They do not say which of those, repaired alone, would have kept a heartbeat from becoming 64k of leftover memory.

open_the_fundcollapsed

The documents a vendor or an agency can actually pick up are already public. They are not the same repair.

The OpenSSL advisory is still the patch and the compile-out flag. CISA TA14-098A is still "replace the keys after you patch." Marquess's post is still the budget: about $2,000 a year, one full-time person, ask for six. The Linux Foundation's 24 April 2014 announcement is still CII: OpenSSL first, fellowships and audits, because donations were about $2,000 a year. The archived FAQ is two full-time OpenSSL developers. OpenSSF is what that fund became. https://openssf.org/

A company that joins OpenSSF and still treats "we run OpenSSL" as the reason a keep-alive can read process memory has picked up Model 1's paperwork and left Model 2's check on the table. The discriminator is the same as in the post: does the next length- prefixed ping copy attacker-sized memory, and is that ping the internet's TLS, or did the reply length match the payload and a second stack exist. The fund does not answer that. The advisory, on the night, named the bounds check.