How Heartbleed could've been found • Hacker News Board

Re: How Heartbleed could've been found

#41

Post by davidgerard » Tue, Apr 07, 2015, 9:31 PM UTC

mwsherman wrote: post #28

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

Progress in maintaining huge codebases in general. OpenSSL is ridiculously large for too few maintainers, but you should be so lucky as to have a codebase of maintainable size for the coders you have. My favourite example remains LibreOffice, where the coders are very good but there are too few of them - so they hit the automated tools, static checkers, clang plugins etc really hard.

Re: How Heartbleed could've been found

#42

Post by wyldfire » Wed, Apr 08, 2015, 12:01 AM UTC

awruef wrote: post #29

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.

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!

Re: How Heartbleed could've been found

#43

Post by awruef » Wed, Apr 08, 2015, 12:18 AM UTC

wyldfire wrote: post #42

awruef wrote: post #29

Earlier quoted context omitted.

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.

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!

Yay :)