Reportings bugs found by OSS-Fuzz

[oliverchang]

Hi, we recently started fuzzing Chakra using OSS-Fuzz (google/oss-fuzz#925), and have discovered a number of crashes. Some of them are potentially security vulnerabilities (buffer overflows, bad address dereferences etc).

We'd like to report these bugs by asking Chakra developers/maintainers to send a PR to add their emails (needs to be associated with a Google account) to this file (example) so that you are CC'ed on current and future bug reports in our issue tracker (disclosure policy).

Our infrastructure comes with regression range testing, fix verification, de-duplication, testcase minimization, and more.

Thanks!

[EdMaurer]

@oliverchang Killer! Thanks for offering to share the reports. Is there a reason to not report the security concerns via secure@microsoft.com?

[oliverchang]

@EdMaurer Our service is designed as a continuous fuzzing tool for the developers of the code that is being fuzzed, and is fully automated in that regard. We don't have anyone doing manual triage to e.g. report to secure@microsoft.com.

[EdMaurer]

@oliverchang Got it. If this is intended to be an ongoing activity, I would prefer it if you would target a release branch as opposed to master. master is our least stable branch and does not generally contain the fixes for issues found through our fuzzing efforts.

[oliverchang]

Sure, we can do that. Would release/1.7 be the best branch?

That said, our workflow is optimized for fuzzing on master/development branches. Our infra is generally very useful at finding regressions quickly on master before they make it into a release branch at all. I'm not familiar with Chakra development/releases or how this would fit into that though, so this is of course up to you :)

[inferno-chromium]

As Oliver said, OSS-Fuzz workflow is strictly meant for master branch fuzzing. That way, we don't have to keep changing release branch numbers in our code. If your branch is unstable, it creates a few more bugs, but once your developer uploads a fix, bugs get auto-verified and auto-closed. So, workflow wise it is all automatic and more useful. This way, you will get both stability and security bugs as soon as they are introduced.

[EdMaurer]

The concern I have is around managing the triage of your discoveries. I'm hoping that if you run it on something that we've put our hardening/fuzzing effort into, you will find fewer issues that will need to be dealt with outside of our normal workflow.

You've run it on master it sounds like. How many issues did it turn up?

[oliverchang]

We've found 21 unique reproducible crashes so far. Our de-duping is generally pretty good and we have tools to help triage like e.g. regression ranges and automatic fix verification.

Would you be opposed to receiving these reports for now and giving it a trial run? If they end up being too much to triage in the long run, we can change to fuzzing release branches.

[EdMaurer]

@oliverchang Yeah, that'll work. Regression ranges will be very helpful.

[oliverchang]

Hey @EdMaurer, how are reports that you've received so far?

We'd be very happy to hear any feedback you might have for us.

[EdMaurer]

@oliverchang I tuned out on this topic, sorry. I'm not the best person to ask about the quality of the reports. @digitalinfinity and @curtisman have been looking at them. I've heard of a couple of cases where we had the same issue already on our books from our internal fuzzing, but that has not been the general case.