Improving OSS-Fuzz integration (additional fuzz targets and coverage)

[mch-byte]

Hi everyone,

Thanks for merging my recent dictionary and seed corpus improvements for fuzz_parse! Before I dive any deeper, I wanted to touch base with you all.

I’m a security researcher usually focused on web and hardware, but I'm currently using GPAC to learn the ropes of fuzzing. It's been an awesome project to work with so far. Recently, I've started drafting some new fuzz targets for areas that OSS-Fuzz doesn't really cover yet. Specifically the SDP parser and the BIFS decoder.

To be completely transparent: I'm using the OSS-Fuzz guidelines as my learning framework, and I am hoping to eventually qualify for their reward program.

Because of this, adding these new targets will almost certainly cause an initial spike in OSS-Fuzz bug reports as fresh code paths get hit. I really don't want to overwhelm your issue tracker. To help keep the noise down, my plan is to actively help triage the crashes these new targets find.

Do you have the bandwidth for this right now, or would you prefer I pace the introduction of these new fuzzers slowly?

Also, if you're open to it down the line, I’d love to help integrate CIFuzz so we can catch these bugs directly on pull requests before they even merge.

Let me know what pace works best for you.

Thanks for all your hard work on GPAC!

[aureliendavid]

Hi @mch-byte and thank you for your interest in this subject.

We would welcome your contributions to expand the coverage of the oss-fuzz targets.

Regarding the "issues flood" question: if the harnesses are integrated into oss-fuzz, the issues will be opened on the oss-fuzz issue tracker at https://issues.oss-fuzz.com/issues?q=is:open%20gpac&pli=1&s=issue_id:desc (you might only see closed and publicly opened ones, not the new ones in their disclosure period)

we monitor this and fix them when we can (you can see the references in the commits like https://github.com/search?q=repo%3Agpac%2Fgpac+%22ossfuzz+issue%22&type=commits )

We wouldn't want duplicates on the github issue tracker. So the idea is that oss-fuzz harnesses are run by oss-fuzz and issues stay on their board. For other issues, harnesses, and local fuzzing we welcome github issues.

A general rule is that we want to find bugs that correspond to actual gpac/MP4Box uses cases, in particular we ask reporters for a POC file and an actual command line that triggers the bug.

For oss-fuzz harnesses too it would be good to have a corresponding command line for each (as a comment in the code for example). For example the bugs reported by the fuzz_probe_analyze target can (usually) be reproduced directly with

gpac -i clusterfuzz-testcase-minimized-fuzz_probe_analyze-xxx inspect:deep:analyze=full

(I should add these as comments in the existing harnesses)