
How Heartbleed could've been found - hannob
https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html
======
f-
Hey all,

I'm the author of AFL. I think this is pretty cool, but also would like to ask
you all to hold on to your hats =) Here's the short response I posted to the
oss-security mailing list:

[http://www.openwall.com/lists/oss-
security/2015/04/07/8](http://www.openwall.com/lists/oss-
security/2015/04/07/8)

------
dankohn1
Hanno (the blog author) uses american fuzzer lop (AFL) and other fuzzers and
has discovered (and reported with test cases) an extraordinary number of bugs:
[http://lcamtuf.coredump.cx/afl/#bugs](http://lcamtuf.coredump.cx/afl/#bugs)

He is doing great work to make the Internet safer.

~~~
KnoopKnoop
As soon as I started reading how it worked it reminded me of Microsoft SAGE
[0] It also uses guided execution to find constraints and new bugs.

[0] [http://research.microsoft.com/en-
us/um/people/pg/public_psfi...](http://research.microsoft.com/en-
us/um/people/pg/public_psfiles/cacm2012.pdf)

------
steakejjs
Google has a big fuzz-farm and Project Zero looking for this type of thing and
even they did not find Heartbleed years ago. They are nabbing tons of bugs but
there are many that are simply buried.

This seems to me a bit like when you do a maze starting from the finish and it
is, for whatever reason, trivial to go from one end to the other.

It is neat that it is 2015 and fuzzers are cool again, though.

~~~
dankohn1
Actually Google did find Heartbleed (along with Codenomicon, who discovered it
independently). [1]

[1]
[http://en.wikipedia.org/wiki/Heartbleed#Discovery](http://en.wikipedia.org/wiki/Heartbleed#Discovery)

~~~
ScottBurson
And Codenomicon apparently found it by fuzzing [0], though I haven't seen any
details.

[0]
[http://www.codenomicon.com/products/defensics/](http://www.codenomicon.com/products/defensics/)

------
Tomte
I rhink there's something fishy with it: you overcome several hurdles to fuzz
OpenSSL and then - miraculously - you come up with Heartbleed.

And the best of it: only Heartbleed. nothing else. Nothing more.

Looks like it really went that way, but what are the odds?

~~~
gpvos
The only slightly suspicious thing that he did was that he immediately fuzzed
only the first packet and no others. Although, being the first packet, it's a
logical place to start. So I think the Heartbleed bug would indeed have been
reasonably easy to find with this technology.

~~~
gpvos
Actually, also the fact that he selected this particular packet exchange. This
is a bit more suspicious, since there are thousands of other possible packet
sequences. But again, the initial TLS handshake would be one of the first ones
to check, I think.

------
wyldfire
afl-fuzz is pretty powerful, no doubt.

But beyond dynamic analysis, someone wrote a static analysis feature to find
heartbleed as well: [https://github.com/awruef/find-
heartbleed](https://github.com/awruef/find-heartbleed)

~~~
awruef
happy to see that someone else saw that! I mostly wrote that post / code as a
tutorial on how to write checkers in a symbolic infrastructure, I think it was
a little successful. I've been working on making checkers like that better,
but that work is depressing because people like the author of AFL spend a lot
of time telling me (indirectly) that it will never work, never scale, and
never matter.

~~~
wyldfire
I read it and thought it was super cool.

I was inspired to write my own checker to demonstrate how easy it was to my
software team.

And when I get a chance I'll try to contribute some general-purpose checkers
to clang.

I dunno if it will work, but IMO it matters. If for no other reason than
inspiring other folks!

~~~
awruef
Yay :)

------
tormeh
I fear these kinds of tools will be (are?) used as an argument to keep using
C/C++. "Just adhere to all these standards and use all these code analysis
tools" is a really bad way of handling bugs when I guarantee you it won't be
used by those that need it most.

~~~
TillE
It's really dangerous to think that switching to another language will fix all
your security problems. You can have safe memory, but that's about it. Serious
exploits like "goto fail" can exist in any language.

~~~
Scramblejams
_You can have safe memory, but that 's about it._

That's not nothing. How many remotely exploitable bugs of massive severity
have come from unsafe memory?

Sure, there's much more work to do beyond memory safety, but there isn't much
excuse for that one anymore.

------
hcrisp
Bug detection is a problem that is easy to verify and hard to solve.

------
midael
I believe Heartbleed was found via both manual analysis and fuzzing to begin
with. Good analysis here:
[http://www.dwheeler.com/essays/heartbleed.html](http://www.dwheeler.com/essays/heartbleed.html)

------
tedunangst
Since I had something to do with the exploit mitigation chatter, I feel I
should note that there's something of difference between fuzzing and exploit
mitigation. I'll also happily concede that Address Sanitizer could be a more
effective exploit mitigator than omalloc.

------
Drdrdrq
To make random() deterministic you can also just seed it with a predetermined
number. Not sure if it is any better in this case, but it helps when writing
unittests and similar.

------
mwsherman
The third part of my post here [1] is that progress in security will more
likely come from cheap tools than expensive humans. Pardon the self-reference
of course. :)

[1] [http://clipperhouse.com/2015/04/04/liquidity-open-source-
and...](http://clipperhouse.com/2015/04/04/liquidity-open-source-and-
security/)

~~~
jjarmoc
... and where do the tools come from?

Tools are either made by expensive humans, or forged by the Dark Lord Sauron
in the fires of Mount Doom.

There's also the matter of who will run those tools. It's not like fuzzers
output exploit.sh or something.

Automation and tooling are great, but they aren't replacements for human
ingenuity.

~~~
mwsherman
Oh no doubt, but tools scale well. The tools allow us to partially but cheaply
replicate the brains of the expensive smart people.

------
smoyer
I'm a big fan of fuzzers and believe the HeartBleed bug could have been found
by one. Finding an already known bug would require a very careful researcher
(to avoid providing either clues or bias). In any case, thanks for all the
work you're doing Hanno!

------
upofadown
So wasn't Heartbleed caused by a single overly large value coming directly
from the attacker?

So, yeah, fuzzing could find that but it seems like wild overkill. The normal
sort of manual range checking one does when implementing a protocol would of
worked too...

------
ndesaulniers
I like to use scan-build to find, report, and fix bugs in open source C/C++
code! Another tool in the toolbox for me, nice read!

------
fjarlq
Coverity has been improved so that it now detects Heartbleed and similar
defects via static analysis:

[http://security.coverity.com/blog/2014/Apr/on-detecting-
hear...](http://security.coverity.com/blog/2014/Apr/on-detecting-heartbleed-
with-static-analysis.html)

