Difference between revisions of "1353: Heartbleed"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
(Transcript)
(Explanation)
Line 8: Line 8:
  
 
==Explanation==
 
==Explanation==
"Heartbleed" refers to a critical bug in the OpenSSL security library. This bug was publicly revealed on Monday, April 7th, 2014.
+
The {{w|Heartbleed bug}} refers to a critical bug in the {{w|OpenSSL}} cryptographic library. This bug was publicly revealed on Monday, April 7th, 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.
Due to a programming error in OpenSSL versions 1.0.1 through 1.0.1f (inclusive, i.e., the bug has 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 {{w|SSL/TLS}}, a web protocol that encrypts web traffic such that only the user and the server can read the communication. This is the protocol behind http'''s''':// (HTTP Secure) connections. SSL is often used to protect sensitive web traffic, such as login requests, which contains the usernames and passwords in the requests.
+
OpenSSL is a very commonly used library to implement {{w|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 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 user names 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 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" ciphers is used, which is currently rare. Furthermore, the hearbleed 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.
 
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" ciphers is used, which is currently rare. Furthermore, the hearbleed 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.
Line 17: Line 16:
 
More information is available at [http://heartbleed.com heartbleed.com] or under CVE-2014-0160, [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160 CVE-2014-0160 at nvd.nist.gov]
 
More information is available at [http://heartbleed.com heartbleed.com] or under CVE-2014-0160, [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160 CVE-2014-0160 at nvd.nist.gov]
  
The mouseover text cites the {{w|Tears in rain soliloquy}}, the dying words of the replicant and main antagonist Roy Batty (played by {{w|Rutger Hauer}}) in the 1982 film ''{{w|Blade Runner}}'', implying that the 64Kb HeartBleed buffer is so complete it includes memories from replicant brains.
+
The title text cites the {{w|Tears in rain soliloquy}}, the dying words of the replicant and main antagonist Roy Batty (played by {{w|Rutger Hauer}}) in the 1982 film ''{{w|Blade Runner}}'', implying that the 64Kb HeartBleed buffer is so complete it includes memories from replicant brains.
  
 
==Transcript==
 
==Transcript==

Revision as of 20:59, 9 April 2014

Heartbleed
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.

Explanation

The Heartbleed bug refers to a critical bug in the OpenSSL cryptographic library. This bug was publicly revealed on Monday, April 7th, 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 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 user names 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 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" ciphers is used, which is currently rare. Furthermore, the hearbleed 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 CVE-2014-0160, CVE-2014-0160 at nvd.nist.gov

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 64Kb HeartBleed buffer is so complete it includes memories from replicant brains.

Transcript

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!

Discussion

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! 173.245.55.73 06:08, 9 April 2014 (UTC)

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

The alt-text contains a reference to the scene "Tears in the rain" of Blade Runner 173.245.49.90 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)