Fuzzing is a dynamic testing method used for identifying bugs and vulnerabilities in software. As opposed to static analysis, fuzzing produces almost no false-positives. With fuzzing, you can conduct black-box, grey-box, and white-box tests. This flexibility makes fuzzing an extremely useful tool in software testing, regardless of source code availability. Black-box fuzzing, for example, can be applied by anyone who wants to examine the reliability of the software they are using or are planning to use.
So, what happens during the fuzzing process? During fuzzing, random inputs are fed to the software under test until a crash happens. The input that resulted in a crash is then analyzed and discovered bugs can be fixed. If the given inputs did not produce a crash, they are mutated to produce further inputs. Software solutions that work with fuzzing are called fuzzers.In 2016, american fuzzy lop (AFL) improved fuzzing by considering the coverage, i.e. the share of traversed code paths in the generation of new inputs. AFL and other coverage-based fuzzers could discover far more paths of a program than “dumb” fuzzers. The next major improvement in the world of fuzzing came in the form of Sanitizers that detect more types of errors than just crashes. The AddressSanitizer, for example, monitors memory access, while the ThreadSanitizer watches for race conditions between multiple threads. Using Sanitizers for fuzzing was made even more practical with the advent of libFuzzer, a fuzzing engine baked into LLVM, due to smart handing of the large virtual memory requirements of the AddressSanitizer. In short, the combination of coverage information with Sanitizers is what we call modern fuzzing. This technology allows continuous and precise targeting of real vulnerabilities in software.