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

31–40 of 43 posts

Re: How Heartbleed could've been found

#31

Post by jjarmoc »

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

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

Re: How Heartbleed could've been found

#32

Post by ScottBurson »

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.

How does your checker work?

Re: How Heartbleed could've been found

#33

Post by awruef »

ScottBurson wrote: post #32
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.

How does your checker work?

the parent comment has a link that includes code and a blog post. clang-analyzer uses "symbolic execution". the work I've been doing in extension also uses symbolic execution.

Re: How Heartbleed could've been found

#34

Post by ScottBurson »

dankohn1 wrote: post #22
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

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

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

Re: How Heartbleed could've been found

#35

Post by Scramblejams »

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.

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.

Re: How Heartbleed could've been found

#37

Post by Puts »

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.

I think we need to start thinking of programming as a true craft. Like watch making. Not something you learn within 2 years just to become a productive app-maker to mass produce more useless apps. But something you grow into by gaining a full understanding about how the computer works. And this requires you to go trough both assembler and C. And by raising the notion of coding as a true craft that takes time and require precision, we will gain more secure applications. Not by hiding the inherent mechanics of the machine treating programmers like kids who need training wheels.

Re: How Heartbleed could've been found

#38

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

Re: How Heartbleed could've been found

#39

Post by tormeh »

Puts wrote: post #37
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.

I think we need to start thinking of programming as a true craft. Like watch making. Not something you learn within 2 years just to become a productive app-maker to mass produce more useless apps. But something you grow into by gaining a full understanding about how the computer works. And this requires you to go trough both assembler and C. And by raising the notion of coding as a true craft that takes time and requ…

Except we're not making the same kind of thing over and over. Programming's not a craft. It's an abnormally non-routine form of engineering. By all means, teach the college students about doping, logic circuits and binary assembly. But skip C. Skip C++. It's not cool, it's not hardcore, it's just sad.

Re: How Heartbleed could've been found

#40

Post by mwsherman »

jjarmoc wrote: post #31
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...

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

Oh no doubt, but tools scale well. The tools allow us to partially but cheaply replicate the brains of the expensive smart people.
Post reply on HN