Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Fuzzing is a proven way to find vulnerabilities in software. It's found 16K bugs in Chrome alone. How much fuzzing is enough though? This blog post looks through the necessary time for fuzzing to likely say whether there are still more bugs to find based on the amount of computing hours. Machines are abstraction of inputs per minute that really matters for fuzzing. Vulnerabilities are the bugs that were found. Coverage is the map of code executed by the program. The theory is the most coverage, the more bugs you will find. But, there is a little to this.

To do this, they had a wide range of data. They used OSS-Fuzzes 263 programs with 58.3M LoC, FTS with 25 programs with 2M LoC, and an additional six program with 6M LoC. Depending on the target, they ran the fuzzers for lots of hours, and lots of repetitions to see the likelihood of finding the issues. From running all of these campaigns, they have some takeaways...

First, an exponential increase of inputs via more compute only linearly increases the bugs found. In practice, this means that each bug cost more, and more money at a large scale. It's cheap and effective to fuzz code that's never been fuzzed; you'll likely get lots of bugs out of it. Once you've gone through that the long-hanging fruit, it's difficult to find those bugs. The hard to find inputs to get new coverage are exponential to find as well.

Better fuzzers are better than adding more compute. Different mutation strategies, better harnesses... these are practically the best ways forward, once you've fuzzed for a few days.

Seeing data on the ability to find new paths, and the ability to find bugs is interesting to see! I've never found a bug on a fuzzer running more than an hour. I imagine this is probably why. So, fuzz things early, and often!