Fuzzing, or fuzz testing is a kind of QA testing which involves inputting some invalid data into the program in order to monitor it for crashes and ensure its security.
Security contributors and researchers use a lot of different fuzzing approaches on Firefox, but it seems quite difficult for beginners to find the information about them.
7 brief tips that can make fuzzing on Firefox more effective:
If you want bugs identified earlier, mind that the nightly builds directly correspond to the central Mozilla’s HG repository, as well as always contain the latest features prepared for release. These offer the great opportunity for testing changes much earlier.
Builds of regular release are not good for fuzzing since they lack some significant features debug builds have. Debug builds, for instance, have a range of enabled memory invalidation routines. Another good thing in debug builds is assertions. While all the assertion failures report bugs, some assertion types are especially capable of indicating security holes.
Using Add-on Debug Functions
Certain functions accessible in privileged context are very powerful only for automated testing. Among such examples are the garbage collector’s calling, zealous garbage collection ability, Firefox quitting, or the cycle collector invoking. Luckily, there’s a publically available add-on for this.
Communication between the outside harness and the running in-browser component is especially important when testing browsers. When the fuzzer running inside a browser has just an outside harness which’s monitoring it, communication from fuzzer to harness is mostly helpful for logging all actions taken by the fuzzer so that they are more easily reproduced.
By using multiple profiles you may in parallel run multiple Firefox instances on one host. You may specify your profile name in the command line. Mind that the prefs.js file provided with ADBFuzz also contains some significant options to be added directly into the prefs.js file of the fuzzing profile you’re using.
It is not that efficient to run Firefox under the debugger for fuzzing. You can instead try the mini-dumps Firefox’s crash reporter provides. By means of theminidump_stackwalk tool, it’s possible to obtain the stack trace from a dump for further triage. An advantage of such an approach is its working on all the supported platforms.
Automated test cases reduction
When your fuzzer finds some problem, often the test case appears very large and can span even multiple files. Its manual reduction is tedious and waste time if this same process is easy to automate. For assertions and crashes, automation proves to be rather easy. For these, try delta scripts or Lithium tool.
Browsers’ fuzzing is a complex effort, so we hope at least one of the tips provided above will facilitate your QA testing endeavors on Firefox and make them even more awesome.