Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Heartbleed could've been found

blog.hboeck.de

Post reply on HN
Print view View original

21–30 of 43 posts

Re: How Heartbleed could've been found

#21

Post by 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...

Re: How Heartbleed could've been found

#22

Post by dankohn1 »

steakejjs wrote: post #4

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.

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

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

Re: How Heartbleed could've been found

#25

Post by TillE »

tormeh wrote: post #14

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.

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.

Re: How Heartbleed could've been found

#26

Post by tormeh »

TillE wrote: post #25
tormeh wrote: post #14

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.

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.

No. The state of the art has advanced well past Java. And besides the kinds of bugs that a good type system can fix, there's also bugs borne from usability problems like switch fall-throughs that are trivial to fix with a better syntax.

Re: How Heartbleed could've been found

#27

Post by haldujai »

Tomte wrote: post #2

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?

He mentions in the article that he also found two other bugs but that they were previously discovered and reported by Brian Carpenter.

By fuzzing various file inputs I recently found two issues in OpenSSL, but both had been found by Brian Carpenter before, who at the same time was also fuzzing OpenSSL.

Re: How Heartbleed could've been found

#29

Post by awruef »

wyldfire wrote: post #3

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

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.
Post reply on HN