Is PR with fuzz target finding unpatched bugs soon after start isn't responsible disclosure?
JulianVolodia opened this issue · 6 comments
Hi!
I was talking on google/oss-fuzz#402 but as description of this repo says, maybe this is better place for some discussion and thoughts.
I still have some n00b questions so forgive me please. I have read https://security.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html and some documentation out there, but still hold my horses with sharing some weapons like fuzz targets without think.
Should I run fuzz target for some grace period to see if it not founds some easy bugs, and if so - report them first privately, to fulfill responsible disclosure?
After that, post the fuzz target to upstream of fuzzed project, inform rest about improvement or so?
Thanks for answers!
And, should fuzz targets lie in project's repo (fuzzed project main repo externally) or could be in oss-fuzz, like for this example https://github.com/google/oss-fuzz/blob/master/projects/kimageformats/kimgio_fuzzer.cc
Thanks!
There is no easy answer for a grace period. You can never be sure of how much computing power you need to find the right set of bugs. And also hard to do this at scale locally. So, we recommend filing any obvious bugs from your new fuzzer, get devs to fix those and then get the fuzz target checked in. See https://google.github.io/oss-fuzz/advanced-topics/ideal-integration/ for answer to your second question.
Thanks @inferno-chromium for answer!
I think you referenced from that doc
If you are a member of the project you want to fuzz, most of the steps above are simple. However in some cases, someone outside the project team may want to fuzz the code, and the project maintainers are not interested in helping.
In such cases, we can host the fuzz targets, dictionaries, etc. in OSS-Fuzz’s repository and mention them in the Dockerfile. It’s not ideal, because the fuzz targets will not be continuously tested, so may quickly bitrot.
but sometimes oss-fuzz do not integrate project when maintainers are not intrested in fuzzing (mostly, bc of problem to meet 90d period to fix them, like tcpdump mentioned in 402 issue on oss-fuzz repo).
I rather want to know, if how much I should try to integrate with their repo, or give up on their first we won't merge it and just go on.
we prefer to get maintainers onboard in most cases as otherwise code bitrots and fuzzers starts breaking in a few months and then you/integrator has to step in to fix broken build. we make exceptions only in cases when project is super critical, in those cases we can sometimes host the fuzzer in our repo first and hope maintainer changes their mind after seeing the first set of awesome bugs.
imho tcpdump could have many and not fuzzing it is just hiding existing problem, so posting some fuzz target inside oss-fuzz will be good or not?
Sorry for hard questions, but as one of tcpdump user want to know their problems and then maybe help with it :)