Maximizing the impact of fuzzing in the context of free software

Dec 28, 2018, by Hugo Lefeuvre.

It is hard to accurately identify the impact of fuzzing on the security of free software projects. That being said, most will agree that a large part of the current CVE flow is the result of fuzz testing.

Unfortunately free software projects don't always fully profit from this fuzzing work, mostly due to mistakes being done while reporting fuzzing results: among others malformed bug reports, missing information and uncontactable reporters. These issues tend to create a counter-productive overhead to security teams and upstream developers.

This blog post is an attempt to point at the potential pitfalls when submitting fuzzing results and how to counter them by observing simple rules.

Guidelines for hassle free fuzzing

  1. if you are fuzzing stable releases, always reproduce on the master branch

    This will help to catch duplicates already fixed since the last stable release.

    If the issue is not reproducible anymore, search for a duplicate in the closed bug reports. Can't find ? Try to determine the commit which made the issue unreproducible, submit a new bug report and indicate this information.

  2. check for open duplicates

    Found an open bug report with identical crash path ? Do not open a new one and use it.

    In doubt ? Open a new bug report and indicate the references of the potential duplicate.

  3. submit a bug report on the project's bug tracker

    The worst thing you could possibly do would be to ask for CVE numbers without opening a bug report.

    The issue should be opened on the project's bug tracker. You can open a bug report on your distro's bug tracker but make sure the issue is also being tracked on upstream's side.

    Also, one issue per bug report! Ideally, one cve number would be assigned per bug report.

  4. explain how to reproduce

    Always publish the POC. Make sure it will stay online as long as possible: do not upload it on Google Drive, DropBox, etc.

    What command triggered the crash ?

    If this required a long processing time, indicate it in your bug report.

  5. give information about your fuzz environment

    Indicate which versions of related libraries you are using.

    Depending on the context you might also want to indicate the affected architecture, ulimit...

  6. wait for confirmation before asking for a CVE number

    Wait a few days before asking for a CVE number, just in case developers find a duplicate meanwhile.

    Requesting for CVE updates takes time to projects developers, security teams members and MITRE people. Remember, each CVE assigned has a triage overhead.

  7. don't disappear

    Developers might not be able to reproduce the issue. In this case there's nothing worse than disappearing as this forces projects developers and security teams members to spend a great deal of time just to assess reproducibility which could be done much faster with your help.