
Xkcd: Heartbleed Explanation - MattBearman
http://xkcd.com/1354
======
billpg
I showed this to my wife to see if the cartoon worked with an educated but
not-technical person. She subconsciously glossed over the (n LETTERS) part of
Meg's requests as just an annotation on the cartoonist's part, not realizing
that it was actually part of the request.

Once I rephrased the final request as "Server, reply with the 500 letters of
HAT", we finally had that light-bulb moment.

~~~
mitosis
Your wife seems to be affected by the recently discovered vulnerability. It
would be advisable to upgrade her firmware to the latest version.

~~~
SimHacker
And don't forget to immediately revoke your old marriage certificate, reissue
a new one, and invalidate all your old keys and cookies, or else your
relationship is vulnerable to a man in the middle attack, like Dr. Frank-N-
Furter did to Brad and Janet! [1]

[1]
[https://www.youtube.com/watch?v=m62xw7EWJDE](https://www.youtube.com/watch?v=m62xw7EWJDE)

------
StavrosK
Nice easter egg in the user who wants to change the password to CoHoBaSt
(correct-horse-battery-staple).

~~~
kdodia
I love geeks who find the same easter eggs. =]

------
nyellin
This is why xkcd is unique - not because of the puns or nerdy references, but
because of Randall's ability to make complicated issues simple.

~~~
diminish
Does anyone remember Randall explaining DDOS?

~~~
hisem
This? [https://xkcd.com/932/](https://xkcd.com/932/)

~~~
dllthomas
That's likely to be an example of DDOS, but isn't at all an explanation _of
DDOS_. It's an explanation of the difference between "the CIA website" and
anything actually sensitive.

------
mixedbit
Security issue explained without Alice, Bob and Malory, this is way too
confusing. Who is this Meg character?

~~~
Namrog84
She is eve's cousin

------
weavie
Wow. Was it really that simple? The heart beat request sends the text as well
as the length it wants back?

~~~
masklinn
> Wow. Was it really that simple?

Close enough.

> The heart beat request sends the text as well as the length it wants back?

The heartbeat sends a payload prefixed by its size. That's perfectly normal
design (for variable-size payloads), that way the handler reads the size,
allocates a buffer[-1] and uses read(2) to read the payload into the buffer.
Otherwise the handler would have to "guess" the payload size, and that never
ends well.

The problem here is twofold:

1\. read(2) may read less than requested, if an attacker gave a bigger size
than the actual one for instance. That's why read(2) returns the number of
bytes actually read

2\. malloc(3) hands out a bunch of memory, without clearing it[0]. Depending
on the exact allocator and application runtime, chances are this bit of memory
is at least in part freed memory, which is filled with the content of previous
allocations such as SSH keys or passwords or whatever

(2.) is compounded by OpenSSL having its own freelists on top of malloc which
it does not clear, making it _certain_ to hit previously allocated data

You're supposed to check the result of read(2) and adjust your payload size
and only copy _that_ to the output buffer. Or just error out if the sizes
differ.

And ideally unless you have very specific reasons not to you'd want to use
calloc(3), so that if you forget to check read(2) you return zeroed memory
anyway. The first part was forgotten and the second one not done (because
"needs fasts!"), the whole input buffer was copied in the output buffer and an
attacker gets 64kb[1] worth of previous allocations data.

[-1] possibly adding its own constraints on top of that, here the payload's
64KiB so it's not relevant, in other contexts the server could refuse overly
large payloads

[0] except on BSD with a malloc.conf using the J or Z options

[1] because the user-provided length is a 16 bit uint

~~~
gokhan
Haha. Your comment is so complex it needs another XKCD comic just to make sure
all those [-1], (2), 1., [1]'s etc. don't get mixed up.

~~~
StavrosK
That's because it was the in-depth, technical explanation of the comic. Based
on the GP's comment, the comic is exactly accurate.

------
AndrewDucker
Can someone explain why Heartbeat needed to return the text it was sent,
rather than always returning an "OK" message?

What advantage does returning the text give you?

~~~
twic
The heartbeat extension was originally designed for DTLS, which is TLS over
UDP. UDP datagrams don't arrive in a guaranteed order, or within any bounded
time. If heartbeat used a fixed message, then if you sent a request and
receive a response using DTLS, you would have no way of knowing if that
response was a response to that request, or to some other request you sent ten
minutes ago, or what.

Allowing the request and response to carry a payload lets you mark each
request with a unique identifier, so that you can recognise the resulting
responses.

It's basically like an HTTP cookie. In reverse.

I have no idea why the payload is variable-sized, rather than being (say) a
fixed 32 bits. I would guess the specifier didn't want to bake in assumptions
about how much space a unique identifier would need.

~~~
fulafel
> I have no idea why the payload is variable-sized

For DTLS path MTU discovery (according to the heartbeat extension RFC).

~~~
EvanAnderson
That could have been accomplished with a fixed-length payload and variable-
length padding, though.

------
parax
"And this is, kids, why you always have to validate your input and do not
trust on the user".

------
damon_c
It's hard to believe that even with all of our slavish mantra repetition about
not trusting user submitted data... the freaking web server trusts user
submitted data.

We're all going to have to start reading more source code...

------
yiedyie
Check this answer:
[http://security.stackexchange.com/a/55539/15901](http://security.stackexchange.com/a/55539/15901)

------
spbhat1989
Xkcd is best at simplifying the most complex things and complicating the most
simple things! :)

------
danyork
Brilliantly done! Great to have this out there to help explain the issue to
non-developers.

------
nashashmi
I just began appreciating all the hoops I jump through just to concentrate on
things hardly anyone else cares about. It takes me nearly ten times as long to
complete a program, and taxes my mind ten times more, and makes me frustrated
twice as much about pursuing programming, but after a very sharp practicing
curve, makes me hundred times better than the rest of the programmers out
there. But, still, I wonder if it's worth it. Especially, considering my
boring as hell job.

~~~
oafitupa
wat

