[deleted]
Just to be clear; everything except the first word you said is true.
It's just not mutually exclusive.
How Heartbleed could've been found
11–20 of 43 posts
Re: How Heartbleed could've been found
#12I 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?
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.
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.
Re: How Heartbleed could've been found
#13[deleted]
You're thinking of Apple's "goto fail" bug, not Heartbleed.
Re: How Heartbleed could've been found
#14I 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.
Re: How Heartbleed could've been found
#15I 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.
Whether they are used as a justification to use C/C++ for new projects (which isn't an argument I've seen), it's still better to have some solid tools available to find security issues in the existing C/C++ code that's already out there.
Re: How Heartbleed could've been found
#16I'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!
Re: How Heartbleed could've been found
#17Google 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.
Not many people did serious analysis of OpenSSL just because the code was very difficult to debug.
Isn't the whole point of fuzzing that you don't really need to understand the code to find flaws in it?
Re: How Heartbleed could've been found
#18Earlier quoted context omitted.
Not many people did serious analysis of OpenSSL just because the code was very difficult to debug.
Isn't the whole point of fuzzing that you don't really need to understand the code to find flaws in it?
No. A fuzzer abstracts away some of the need for intricate, function by function analysis, but you really want to know what the source code is doing to be successful.
Fuzzing "blind" will work...but you will miss a lot without more instrumentation than that.
Re: How Heartbleed could've been found
#19I believe Heartbleed was found via both manual analysis and fuzzing to begin with. Good analysis here: http://www.dwheeler.com/essays/heartbleed.html
Re: How Heartbleed could've been found
#20Hanno (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 He is doing great work to make the Internet safer.
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...