1. 2

From the abstract:

Precise crash triage is important for automated dynamic testing tools, like fuzzers. At scale, fuzzers produce millions of crashing inputs. Fuzzers use heuristics, like stack hashes, to cut down on duplicate bug reports. These heuristics are fast, but often imprecise: even after deduplication, hundreds of uniquely reported crashes can still correspond to the same bug. Remaining crashes must be inspected manually, incurring considerable effort.

In this paper we present Semantic Crash Bucketing, a generic method for precise crash bucketing using program transformation. Semantic Crash Bucketing maps crashing inputs to unique bugs as a function of changing a program (i.e., a semantic delta).

We observe that a real bug fix precisely identifies crashes belonging to the same bug. Our insight is to approximate real bug fixes with lightweight program transformation to obtain the same level of precision.

Our evaluation shows that approximate fixes are competitive with using true fixes for crash bucketing, and significantly outperforms built-in deduplication techniques for three state of the art fuzzers.

  1. 1

    (Havent read paper yet.)

    “Remaining crashes must be inspected manually, incurring considerable effort.”

    Im don’t think that’s true. If using contracts as runtime checks, the fuzzing takes you right to point of failure or supporting part. For those without contracts, I speculated one could use tools like Softbound+CETS modified to log the point of failure and type. You also log the inputs. On failure, save both from memory to a file. From there, you can just simple programming to filter duplicates, prioritize by vulnerability type, and so on.