saelo
commented
4 years ago One way to deal with stderr/stdout output for crashes would be to add a new Operations "Comment" which contains an arbitrary string as payload and is then lifted to a JS comment. Then, the Fuzzer.execute method could, for crashes, append a comment instruction to the crashing program with the content of stderr and/or stdout. This way, the output would automatically be preserved even when sending the crashing program to a master instance.
As with any fuzzer, Fuzzilli can trigger crashes that do not reproduce later on. There can be various reasons for that, e.g. memory pressure of the system during the time of the crash or simply non-deterministic behaviour of the target. As JavaScript engines are quite complex, it is expected that there will be non-reproducible crashes during fuzzing.
It would, however, be nice to have some more information about how a sample originally crashed so root-causing of non-reproducible crashes becomes easier/possible. This could e.g. be done by adding a commandline flag that, when enabled, causes Fuzzilli to record stdout + stderr of the target during fuzzing and include that in the crashing testcases. That way, it should at least be somewhat clear how the sample originally crashed.
There could also be a bug in Fuzzilli that causes it to incorrectly treat some files as crashes under some circumstances. One approach to debug this would be to comment out this line: https://github.com/googleprojectzero/fuzzilli/blob/2e7c967d171a5059aff6f9ab8df6be0e36216018/Sources/libreprl/libreprl.c#L106 and thus log stderr of the target during fuzzing. That should show whether the target actually crashed and roughly how it crashed (e.g. with an assertion failure).