Sooner or later we all fuzz something. When we do it is important to us (or at least to me) to spend time wisely to maximize results with a minimal effort. Some people think that only fuzzing dumbly and quickly is the way to go, while others think that only smart fuzzing will bring results against targets that had any prior fuzzing done on. I think both are wrong. For those that support dumb fuzzing I will point out MS SAGE work that found a ton of stuff after they ran dumb fuzzing on their applications. For those supporting only smart fuzzing I'd point the Adobe 1-byte bug found by a dumb fuzzer not too long ago.
So, here is my take on the question of dumb, smart or in-between fuzzing:
- In every project we should start with dumb fuzzing - making sure we don't miss the obvious by making our fuzzer too smart. This should happen in day one, as soon as we have a minimal understanding of the project we should write some dumb fuzzer and start running it - this is CPU cycles well spent. Usually we'll find something this way. We must also keep adjusting our
- As we go on we start gaining a more in-depth understanding of the project we're working on. This is the time to start developing a smarter fuzzer. It is important to start from a slightly "dumb" smart fuzzer. Meaning one that has a minimal knowledge of the protocol or implementation details. We should have some hints on how to focus this fuzzer from our initial dumb fuzzer and what we found (or didn't find) there.
- Finally it's time to bring out the big guns - we must build our "ultra smart" fuzzer. This one should be an evolution of the initial slightly "dumb" smart fuzzer we wrote. It should be based on our findings during the project - from fuzzing an other stuff we did.
-- Gal