1353: Heartbleed

Explain xkcd: It's 'cause you're dumb.
(Redirected from 1353)
Jump to: navigation, search
I looked at some of the data dumps from vulnerable sites, and it was... bad. I saw emails, passwords, password hints. SSL keys and session cookies. Important servers brimming with visitor IPs. Attack ships on fire off the shoulder of Orion, c-beams glittering in the dark near the Tannhäuser Gate. I should probably patch OpenSSL.
Title text: I looked at some of the data dumps from vulnerable sites, and it was... bad. I saw emails, passwords, password hints. SSL keys and session cookies. Important servers brimming with visitor IPs. Attack ships on fire off the shoulder of Orion, c-beams glittering in the dark near the Tannhäuser Gate. I should probably patch OpenSSL.


The Heartbleed bug refers to a critical bug in the OpenSSL cryptographic library. This bug was publicly revealed on Monday, 7 April 2014. Due to a programming error in OpenSSL versions 1.0.1 through 1.0.1f — meaning the bug had existed for two years — attackers could read random server memory by sending specially prepared HeartbeatRequest messages to an affected server.

OpenSSL is a very commonly used library to implement SSL/TLS, a cryptographic protocol not only used to secure web traffic but also for mail clients and much more. Only the user and the server can read the communication. On the web the protocol is https:// (HTTP Secure), instead of the open http:// standard. SSL is often used to protect sensitive web traffic, such as login requests, which contains the usernames and passwords in the requests. The server sends a certificate to the browser before the secure connection is established. If the certificate is registered the browser accepts it automatically, otherwise the user gets a popup to accept or reject this insecure certificate.

A vulnerability that lets an attacker read random clumps of memory on the server would possibly let an attacker find recent username/password requests, allowing them to gain unauthorized access to user accounts. Even worse, this vulnerability could read the server's private key, enabling anyone to impersonate the server and/or decrypt any future traffic that relies on that key, and any previously obtained prior traffic also, unless a "perfect forward secrecy" cipher is used. Furthermore, the Heartbleed exploit occurs during the handshake phase of setting up a connection, so no traces of it are logged, i.e. you can be attacked and never be the wiser.

More information is available at heartbleed.com or under the reference CVE-2014-0160 at nvd.nist.gov.

In the last panel, Megan interprets Cueball's question ("is everything compromised?") expansively. She responds that, being a computer bug, Heartbleed can only affect information which is stored on computers. Cueball concludes that information recorded in analog media, such as that written on paper or etched in clay tablets, is safe. Megan adds that imaginations are also unaffected by Heartbleed, and Cueball is reassured. The reader may wonder how our society would fare in the face of the leakage of all electronically stored private information, but having our imaginations intact is certainly reassuring.

The title text cites the Tears in rain soliloquy, the dying words of the replicant and main antagonist Roy Batty (played by Rutger Hauer) in the 1982 film Blade Runner, implying that the 64KiB Heartbleed buffer is so complete it includes memories from replicant brains. This is ironic as in the soliloquy, Roy Batty stated "All those moments will be lost in time".

The title text also suggests patching OpenSSL oneself, which might refer to the patched version of OpenSSL by Debian, which turned out to be vulnerable in 2008, and was the topic of 424: Security Holes.


In addition to the below, see xkcd's explanation in the next comic.

Transport Layer Security (TLS), the successor to SSL, is a protocol that provides end-to-end encryption for data transmitted over the internet and is described in RFC 5246. The Heartbeat extension to TLS introduced in 2012 (described in RFC 6520) provides a protocol for keeping an encrypted TLS session alive (preventing inactivity timeouts), so you do not have to do a costly TLS handshake with the server for subsequent transfer of information.

The Heartbeat protocol involves the client sending a packet with an arbitrary payload (often a random 16-to-32-byte number) that the server periodically sends back to the client to tell the client that the TLS session is still alive. When the client sends the packet to a vulnerable version of OpenSSL, the OpenSSL server reads a payload_size from the header sent by the client. This is a 2-byte number (0 to 0xffff=65535) that is supposed to describe the size of the payload. The OpenSSL library writes the payload to memory, but it does not check that the size of the payload written to memory matches the payload_size taken from the client's header. When the vulnerable server sends back the Heartbeat KeepAlive response to the client, it will readout payload_size number of bytes and send them back to the client. If you send a payload that is actually 16 bytes, but claims it is 0xffff bytes you will read the next 64KiB of memory of the vulnerable process starting from wherever the payload was written. An attacker can repeat this attack many times and can do this attack early in the TLS handshake, so the attack will not in any way be logged unless they are logging every incoming packet which is not typical and would result in many passwords being logged. As private keys often have an identifiable format, it is often possible for an attacker to find the private TLS key, so if they eavesdrop on network traffic they can decrypt and/or alter it. For more detailed information see: 1, 2, 3.

It is worth noting that modern operating systems use a virtual memory abstraction above physical memory. This means every process can only access memory assigned to it, so it would be impossible for a vulnerable web server to read memory assigned to another process (like a text editor that has erotic fan fiction stored to memory) on the same computer. For more info, see: 4.

It also should be noted that this Heartbleed bug only affects certain versions of OpenSSL, and does not affect other TLS/SSL implementations, or OpenSSH which does not even use the TLS protocol but uses the SSH-2 protocol (described in RFC 4251). SSH is typically used for remote logins on Unix and Linux computers.

Vulnerable sysadmins need to update to a patched version of OpenSSL or one with the Heartbeats disabled. Unless their TLS keys were protected by hardware, they probably also need to revoke their old TLS keys and generate new TLS keys. To learn how to do this visit Leo Green. There you will find all the information you need.

Users of vulnerable systems should change their passwords after the sysadmins have revoked their old key and issued new ones (as their passwords may have been compromised). Users can check whether a given website is vulnerable via a Heartbleed test also available as open source. The LastPass Heartbleed diagnostic also indicates whether the signature on the TLS key predates the publication of the Heartbleed vulnerability.

The vulnerable commit was introduced Dec 31st, 2011, by Robin Seggelmann, the first co-author of the heartbeats RFC, and went live when OpenSSL version 1.0.1 was released on 2012-03-14 and the vulnerability was widely announced 2014-04-07.


Megan: Heartbleed must be the worst web security lapse ever.
Cueball: Worst so far. Give us time.
Megan: I mean, this bug isn't just broken encryption.
Megan: It lets website visitors make a server dispense random memory contents.
Megan: It's not just keys. It's traffic data. Emails. Passwords. Erotic fanfiction.
Cueball: Is everything compromised?
Megan: Well, the attack is limited to data stored in computer memory.
Cueball: So paper is safe. And clay tablets.
Megan: Our imaginations, too.
Cueball: See, we'll be fine.

comment.png add a comment! ⋅ comment.png add a topic (use sparingly)! ⋅ Icons-mini-action refresh blue.gif refresh comments!


I added an explanation for the punchline. ImVeryAngryItsNotButter (talk) 16:13, 10 April 2014 (UTC)

I added a transcript, if I messed up on anything, I'm sorry! 06:08, 9 April 2014 (UTC)

Thanks for the transcript! (nothing seems messed up) 06:41, 9 April 2014 (UTC)
But wait! You forgot a comma! (It's okay, I fixed it :) ) 06:47, 9 April 2014 (UTC)

The alt-text contains a reference to the scene "Tears in the rain" of Blade Runner 06:19, 9 April 2014 (UTC)

Is Explainxkcd using Open SSL? Jonv4n (talk) 06:56, 9 April 2014 (UTC)

I'd just like to take this moment to say that even though you probably don't have anything of value stored here, Explain xkcd is good on the Heartbleed front. Not using any of the affected software because the data we handle isn't private at all probably helps with that. And yes, Mediawiki hashes your passwords before they're sent. Davidy²²[talk] 07:18, 9 April 2014 (UTC)

Davidy22 - While your first point was correct (explainxkcd isn't vulnerable to heartbleed as explainxkcd doesn't any encryption -- everything starts being sent in plaintext over the net), your second point is wrong. As anyone with wireshark can verify (or using your web browsers' developer tools), when you login to explainxkcd from `http://www.explainxkcd.com/wiki/index.php?title=Special:UserLogin&returnto=Main+Page`, you make a POST request to `/wiki/index.php` that contains as a POST variable your user name (in the POST variable wpName), and your password (in the POST variable wpPassword), both sent in plaintext. Granted it probably is stored in the database hashed (hopefully with a unique salt and a good hash algorithm), it is readable by any network eavesdropper. Not really a problem though, if you don't reuse passwords or mind if your account here was compromised. Jimbob (talk) 22:38, 9 April 2014 (UTC)

Have the following from OpenSSL Bug Report Should this be incorperated into the main explanation, and how should it be formated Jonv4n (talk) 08:07, 9 April 2014 (UTC)

OpenSSL Security Advisory [07 Apr 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 releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley <[email protected]> and Bodo Moeller <[email protected]> for preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

Actually, attack is limited to data in memory of the webserver PROCESS. Even on affected computers, other applications are safe and most of disk content is safe. Not speaking about the fact that in many cases, the public-facing webserver is just proxy cache before the real ones. The real problem is if someone immediately used the revealed data - either to impersonate the server or for example found the admin password and used it to copy the database ... which DOES leave traces. I agree with Cueball: there can be worse kind of bug. In fact, I'm sure that what Edward Snowden revealed is worse, although not technically bug. -- Hkmaly (talk) 10:18, 9 April 2014 (UTC)
Hkmaly -- Completely agree. Posted a similar discussion at security.stackexchange.com and altered the text here to describe heartbleed in more detail. Jimbob (talk) 21:33, 9 April 2014 (UTC)

" If the certificate is registered the browser accepts it. This is incorrect. Server certificates aren't accepted because they're registered, they're accepted because they can prove a chain of trust up to a CA certificate which is explicitly trusted. Ironically, certificates only need to be registered when they're revoked (on a CRL - certificate revocation list). The whole idea of the digital certificate system we use is that of federated trust, which requires no online lookup to validate a certificate. Jezzaaaa (talk) 22:19, 10 April 2014 (UTC)

Nope, you have to pay for it. The browser trusts that few sites and accepts the certificate silently. Otherwise you do get that popup to accept or deny. --Dgbrt (talk) 22:29, 10 April 2014 (UTC)
You're talking about the CA certificate at the root of the trust chain. But the certificate in the server sends a certificate ... if the certificate is registered is the server's certificate, not the CA certificate. Jezzaaaa (talk) 00:40, 11 April 2014 (UTC)
Another attempt at explanation: server certificate is accepted because it's SIGNED by (private key of) AUTHORITY. The certificate (public key) of AUTHORITY is part of browser. So, the implicitly trusted certificates of authorities are registered/listed in browser, but no list of server certificates is needed. And yes, you need to pay for getting your certificate signed by one of those few (120?) authorities which are part of most browsers. -- Hkmaly (talk) 10:53, 11 April 2014 (UTC)
Yep, and being signed does not require being registered. So, instead of "if the certificate is registered the browser accepts it", perhaps "if the certificate is signed by a trusted authority the browser accepts it".Jezzaaaa (talk) 21:42, 14 April 2014 (UTC)

What is most remarkable in all this is the list of things that have happened to or about Robin Seggelmann. Compare enquiries and published data on him with what has occurred to Julian Assange or Edward Snowden.Weatherlawyer (talk) 19:27, 9 January 2015 (UTC)