Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Good read, but there is a huge elephant in the room.

In many cases vulnerabilities come from complex, messy, disorganized, or just poorly written code. Assuming that the "fuzzification" techniques are implemented by the same developer who wrote the original vulnerable code; how can we be sure that he isn't introducing MORE bugs in his fuzzified version?

For example, if you have a product which is NOT currently vulnerable and add BranchTrap to it the likelihood that you're creating a vulnerability where one never existed before is insanely high.

So you essentially created a code path for the fuzzer that never would have existed if you never tried to fool the fuzzer in the first place.

Assuming two binaries, an original and a "fuzzified" version and an unlimited amount of time: Which version would have overall More vulnerable code paths? Probably the fuzzified version simply because it has more code. The point of producing two binaries is that one can be analyzed quickly and one slowly. But if your original code doesn't contain a vulnerability and the fuzzed version does your trusted party doesn't mean anything.

This is not insignificant either. Time to fuzz an application no longer matters for the attacker. If he grinds on it long enough he will have a vuln that the authors aren't aware of (and can't/won't even find now). It doesn't matter if it takes 2 years to find a vuln in your code... Someone will do it.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: