4 ms·

You know what's probably a better way of making it harder to find bugs in your code using fuzzing? Fuzz it yourself and actually fix the damn bugs.

by makomk 7y ago

283b 7y ago
In practice I think this is akin to asking someone to write bug free code the first time. Regardless of this specific paper, assuming all bugs can be found and fixed is not a sound assumption. I'm happy to see techniques that correctly assume undetected bugs exist, and propose solutions to that problem. (Other than asking developers to just find and fix all the bugs, which again, is not possible)
- makomk 7y ago
  You don't need to find and fix all the bugs to make fuzzing less useful for an attacker - just finding and fixing the low-hanging fruit that's easily detected by fuzzing is enough to make it a lot less productive for everyone else.
nickpsecurity 7y ago
The state-of-the-art analyzers and fuzzers are also really good. Especially the ones setup for no false positives. Bar is lower than ever.
segmondy 7y ago
One, these guys needed to write a paper. They also can't write a tool that can fix all bugs, but they can write a tool that makes it harder to find for others which is what they did. Last, you never know who else could build on this idea and where they might take it. So relax. :)
jplayer01 7y ago
I love how their justification is: > Unfortunately, advanced fuzzing techniques can also be used by malicious attackers So the solution is to make it harder to find bugs instead of finding and fixing them, which affects everybody, not just "attackers". This is like the companies who'll sue or ban researchers for finding bugs in their stuff. Or programmers on HN who criticize researchers for publicizing vulnerabilities when companies refuse to fix them and give them the runaround. I can already see companies like Apple implementing something like this instead of putting in the required time, effort and money to fix issues, while simultaneously villifying legitimate security researchers who look for vulnerabilities in their products.

You know what's probably a better way of making it harder to find bugs in your code using fuzzing? Fuzz it yourself and actually fix the damn bugs.

by makomk 7y ago

You know what's probably a better way of making it harder to find bugs in your code using fuzzing? Fuzz it yourself and actually fix the damn bugs.

283b 7y ago

In practice I think this is akin to asking someone to write bug free code the first time. Regardless of this specific paper, assuming all bugs can be found and fixed is not a sound assumption. I'm happy to see techniques that correctly assume undetected bugs exist, and propose solutions to that problem. (Other than asking developers to just find and fix all the bugs, which again, is not possible)

makomk 7y ago
You don't need to find and fix all the bugs to make fuzzing less useful for an attacker - just finding and fixing the low-hanging fruit that's easily detected by fuzzing is enough to make it a lot less productive for everyone else.

nickpsecurity 7y ago

The state-of-the-art analyzers and fuzzers are also really good. Especially the ones setup for no false positives. Bar is lower than ever.

segmondy 7y ago

One, these guys needed to write a paper. They also can't write a tool that can fix all bugs, but they can write a tool that makes it harder to find for others which is what they did. Last, you never know who else could build on this idea and where they might take it. So relax. :)

jplayer01 7y ago

I love how their justification is: > Unfortunately, advanced fuzzing techniques can also be used by malicious attackers So the solution is to make it harder to find bugs instead of finding and fixing them, which affects everybody, not just "attackers". This is like the companies who'll sue or ban researchers for finding bugs in their stuff. Or programmers on HN who criticize researchers for publicizing vulnerabilities when companies refuse to fix them and give them the runaround. I can already see companies like Apple implementing something like this instead of putting in the required time, effort and money to fix issues, while simultaneously villifying legitimate security researchers who look for vulnerabilities in their products.