explain xkcd - User contributions [en]

1353: Heartbleed

2014-04-11T18:00:19Z

108.162.210.111: /* Heartbleed */

{{comic
| number = 1353
| date = April 9, 2014
| title = Heartbleed
| image = heartbleed.png
| titletext = 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 {{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.

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 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 [http://heartbleed.com heartbleed.com] or under the reference [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160 CVE-2014-0160 at nvd.nist.gov]

In the last panel, Megan interprets Cueball's question ("is '''everything''' compromised?") in its most literal meaning. She responds that, being a computer bug, Heartbleed can only affect information which is actually stored on computers. Cueball concludes that all information recorded in physical media, such as that written on paper or etched in clay tablets, is safe. Megan adds that the information stored in human minds is also unaffected by Heartbleed, for obvious reasons. Cueball thus asserts that human civilization will endure the Heartbleed bug, implicitly claiming (though possibly jokingly) that our society will endure even in the face of the destruction of all electronically stored information.

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 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 to patch 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]].

===Heartbleed===
In addition to the below, see [[1354|xkcd's explanation]] in the next comic.

[http://en.wikipedia.org/wiki/Transport_Layer_Security Transport Layer Security] (TLS), the successor to [http://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL], is a protocol that provides end-to-end encryption for data transmitted over the internet, and is described in [http://tools.ietf.org/html/rfc5246 RFC 5246]. The Heartbeat extension to TLS introduced in 2012 (described in [https://tools.ietf.org/html/rfc6520 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 server. 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: [http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html 1], [http://security.stackexchange.com/a/55117/2568 2], [https://news.ycombinator.com/item?id=7549943 3].

It is worth noting that modern operating systems use a [http://en.wikipedia.org/wiki/Virtual_Memory#Usage 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: [http://security.stackexchange.com/a/55271/2568 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 [http://tools.ietf.org/html/rfc4251 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.

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 [http://filippo.io/Heartbleed/ Heartbleed test also available as open source]. The [https://lastpass.com/heartbleed/ Lastpass heartbleed diagnostic] also indicates whether the signature on the TLS key predates the publication of the heartbleed vulnerability.

The [https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3 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.

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

{{comic discussion}}

Talk:1354: Heartbleed Explanation

2014-04-11T12:07:17Z

108.162.210.111:

I assume everybody got the (truncated) reference to the password "CorrectHorseBatteryStaple"... [[Special:Contributions/141.101.89.210|141.101.89.210]] 06:51, 11 April 2014 (UTC)
:Until I read this wiki, I did not get that. [[Special:Contributions/108.162.216.50|108.162.216.50]] 10:09, 11 April 2014 (UTC)BK201
:There are also references to (if I recall correctly): [[Missed Connections]], "snakes but not too long" from [[Umwelt]], there's boats (of which many comics exist), "bees in car why" may be slightly related to [[Parody Week: TFD and Natalie Dee]]... that's all I see. Also the ip (375.381.283.17) doesn't seem to represent anything, but you never know. {{User:Grep/signature|11:04, 11 April 2014}}

While the bug is explained very good, there is one point missing: The word "user" seems to imply that Meg is known to server. But the bug doesn't require that - ANYONE can ask the server. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 11:03, 11 April 2014 (UTC)
: Nope, the word "user" does not indicate a logged in user. It's just a reference to anybody who happens to "use" (actually: connect to) the server at the moment. In fact, it is a particular network connection (TCP or else), on which other end there is a "user" Meg. -- [[Special:Contributions/108.162.210.111|108.162.210.111]] 12:07, 11 April 2014 (UTC)

Talk:1354: Heartbleed Explanation

2014-04-11T12:06:51Z

108.162.210.111:

Talk:1354: Heartbleed Explanation

2014-04-11T12:06:16Z

108.162.210.111:

1353: Heartbleed

2014-04-11T11:56:42Z

108.162.210.111: Corrected confusion between SSL and SSH

{{comic
| number = 1353
| date = April 9, 2014
| title = Heartbleed
| image = heartbleed.png
| titletext = 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==
{{Incomplete|The last picture is not explained i.e. the punch line. All of the explanation so far is concerned with Heartbleed and the title text.}}

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.

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 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 [http://heartbleed.com heartbleed.com] or under the reference [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160 CVE-2014-0160 at nvd.nist.gov]

In the last panel, Megan interprets Cueball's question ("is '''everything''' compromised?") in its most literal meaning. She responds that, being a computer bug, Heartbleed can only affect information which is actually stored on computers. Cueball concludes that all information recorded in physical media, such as that written on paper or etched in clay tablets, is safe. Megan adds that the information stored in human minds is also unaffected by Heartbleed, for obvious reasons. Cueball thus asserts that human civilization will endure the Heartbleed bug, implicitly claiming (though possibly jokingly) that our society will endure even in the face of the destruction of all electronically stored information.

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 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 to patch 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]].

===Heartbleed===
In addition to the below, see [[1354|xkcd's explanation]] in the next comic.

[http://en.wikipedia.org/wiki/Transport_Layer_Security Transport Layer Security] (TLS), the successor to [http://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL], is a protocol that provides end-to-end encryption for data transmitted over the internet, and is described in [http://tools.ietf.org/html/rfc5246 RFC 5246]. The Heartbeat extension to TLS introduced in 2012 (described in [https://tools.ietf.org/html/rfc6520 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 server. 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: [http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html 1], [http://security.stackexchange.com/a/55117/2568 2], [https://news.ycombinator.com/item?id=7549943 3].

It is worth noting that modern operating systems use a [http://en.wikipedia.org/wiki/Virtual_Memory#Usage 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: [http://security.stackexchange.com/a/55271/2568 4].

It also should be noted that this heartbleed bug only affects certain versions 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 [http://tools.ietf.org/html/rfc4251 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.

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 [http://filippo.io/Heartbleed/ Heartbleed test also available as open source]. The [https://lastpass.com/heartbleed/ Lastpass heartbleed diagnostic] also indicates whether the signature on the TLS key predates the publication of the heartbleed vulnerability.

The [https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3 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.

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

{{comic discussion}}

Talk:432: Journal 4

2014-04-04T22:47:27Z

108.162.210.111:

Black hat is going *really* out of character here. Lovesickness in this callous troll? Blasphemy! [[User:Davidy22|Davidy22]] ([[User talk:Davidy22|talk]]) 03:34, 30 October 2012 (UTC)
:We all have our moments. [[User:Thokling|Thokling]] ([[User talk:Thokling|talk]]) 15:06, 22 September 2013 (UTC)
::He does have a heart, he simply does not use it much. -- [[Special:Contributions/108.162.210.111|108.162.210.111]] 22:47, 4 April 2014 (UTC)

Talk:853: Consecutive Vowels

2014-04-04T17:52:56Z

108.162.210.111:

Present tense, or {{w|gerund}}? -- [[User:IronyChef|IronyChef]] ([[User talk:IronyChef|talk]]) 14:52, 16 November 2012 (UTC)

I always thought the voyeur reference was to the statistical voyeurism is http://xkcd.com/563/

I don't think '''y''' is a vowel in that word. [[Special:Contributions/184.66.160.91|184.66.160.91]] 05:17, 8 July 2013 (UTC)

:Y is ''always'' a vowel.[[Special:Contributions/76.29.225.28|76.29.225.28]] 15:21, 17 July 2013 (UTC)
::No --[[User:JSekula71|JSekula71]] ([[User talk:JSekula71|talk]]) 05:33, 18 July 2013 (UTC)
:From the grammatical point of view, “y” is a vowel. If you would look at the pronunciation point of view then even “queue” is read /kjuː/ and therefore has only one vowel. [[User:Sten|'''STEN''']] ([[User talk:Sten|talk]]) 19:53, 5 November 2013 (UTC)
:Depends on barely audiable differences in pronunciation (vowel in voy-eur and consonant in vo-yeur). Would have to be voy-e-yor for every writen vow to be pronounced distinct from the others, though. Equally kyu-e-oo-ee. -- [[Special:Contributions/108.162.210.111|108.162.210.111]] 17:52, 4 April 2014 (UTC)

Y has to be a vowel here or it's not funny ~JFreund

I don't know if it's related, but 'queue' is the french word for 'tail', and it's slang for dick. Queueing sounds like 'queuter', which is slang for 'to fuck'. [[User:Bonob|Bonob]] ([[User talk:Bonob|talk]]) 14:30, 31 October 2013 (UTC)
:So ''THAT'''s why the French are lovers, not fighters! Anonymous 04:30, 5 December 2013 (UTC)

Seems to me the explanation does a pretty good job explaining. as the incomplete did not include a specific reason, I deleted it. Anonymous 06:51, 10 January 2014 (UTC)

Talk:1347: t Distribution

2014-03-26T08:57:41Z

108.162.210.111:

http://en.m.wikipedia.org/wiki/Student%27s_t-test

[[Special:Contributions/173.245.50.73|173.245.50.73]] 05:20, 26 March 2014 (UTC)Adam

I think this is a comment of the quality of education today - it is difficult to grade students on a distribution curve and even more so when you take into account the distribution curve of the teachers ability. {{unsigned ip|108.162.249.205}}

I noticed the teacher's curve is symmetrical, and after further inspection it could be interpreted as an edge detection: high values show where an edge occurs. The two highest peaks would nicely align with the edges of the paper, the next highest peaks fit the edges of the table, and the rest could be approximation artefacts, as they're equidistant and rather insignificant compared to those four. I'm not statistics pro, but maybe that rings someone's bells? [[Special:Contributions/108.162.210.239|108.162.210.239]] 07:56, 26 March 2014 (UTC)

:Interesting observation. It may play into an age-long legend told and re-told among the students that some teachers grade papers by tossing the whole pile in the air; those sheets that land on the teacher's desk get a pass, those falling to the floor get a fail. Sometimes the story gets modified in such a way that papers falling on the teacher's book (or other object) laying on the desk will get a higher marking than those simply hitting the desk. The latter version would explain the higher sheet-size-apart peaks. [[Special:Contributions/108.162.210.111|108.162.210.111]] 08:57, 26 March 2014 (UTC)