kcc
commented
7 years ago The narrower the better. guided fuzzing has superlinear complexity, so the smaller is the target the better.
But just like with "unit tests vs integration tests" you sometimes may need to fuzz more complex targets to test the "glue" between the smaller components.
On Sun, Dec 11, 2016 at 5:03 AM, MarkusTeufelberger < notifications@github.com> wrote:
Imagine an application that can receive various inputs: reading a config file with slightly custom syntax, reading some state from JSON, processing some YAML input and for good measure displaying PNG and JPEG image files.
Writing one fuzzer per input type ("config_fuzzer", "json_fuzzer" etc) would create nicer looking, single type corpora and make it easier to immediately see in which code area the issue lies.
A jack-of-all-trades fuzzer would however also not be that hard to debug (since it is relatively easy to see which sub-function caused an error most of the time) and might profit from cross-corpora information (a valid JSON string might lead to a valid YAML string). It would also lead to a better overview which code paths your fuzzing efforts are covering. Also it might help in promoting practices like failing on invalid input as soon as possible, as otherwise the performance would degrade.
Cross corpora checking is hopefully already done at ClusterFuzz though
Actually, no, we don't do it yet (but are planing to).
(checking coverage is so fast that it makes no sense to not check all test cases ever generated by all fuzzers imho to find the current minimal seed corpus), so the overhead of e.g. pushing a JPEG picture through a JSON parser might be too much.
Should fuzzers written for oss-fuzz be as general or as narrow as possible, or is there no real difference?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/oss-fuzz/issues/166, or mute the thread https://github.com/notifications/unsubscribe-auth/ABtNcUtOJC0TvrZpIzQQYFd3uUhhnUBEks5rG_SJgaJpZM4LJ60L .
MarkusTeufelberger
inferno-chromium
Imagine an application that can receive various inputs: reading a config file with slightly custom syntax, reading some state from JSON, processing some YAML input and for good measure displaying PNG and JPEG image files.
Writing one fuzzer per input type ("config_fuzzer", "json_fuzzer" etc) would create nicer looking, single type corpora and make it easier to immediately see in which code area the issue lies.
A jack-of-all-trades fuzzer would however also not be that hard to debug (since it is relatively easy to see which sub-function caused an error most of the time) and might profit from cross-corpora information (a valid JSON string might lead to a valid YAML string). It would also lead to a better overview which code paths your fuzzing efforts are covering. Also it might help in promoting practices like failing on invalid input as soon as possible, as otherwise the performance would degrade.
Cross corpora checking is hopefully already done at ClusterFuzz though (checking coverage is so fast that it makes no sense to not check all test cases ever generated by all fuzzers imho to find the current minimal seed corpus), so the overhead of e.g. pushing a JPEG picture through a JSON parser might be too much.
Should fuzzers written for oss-fuzz be as general or as narrow as possible, or is there no real difference?