update the OSS-Fuzz blocklist

[evverx]

It's a follow-up to #2201. The comments point to #2178 because the reason is the same.

[oliverchang]

Thanks for the change. Is there a list of false positive OSV entries you can point to as justification for this case?

[evverx]

google/oss-fuzz#7434, google/oss-fuzz-vulns#25, google/oss-fuzz-vulns#35. At some point I stopped keeping track of them.

I'd also point out things like https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html

What needs to happen is that the Google 'bot need to be stopped, while
the fuzzing framework is fixed, the existing CVEs need to have humans
look at them, and be cancelled if necessary. Google needs to be hit with
a clue-stick and told that auto-generating low-quality CVEs is a bad idea.

[oliverchang]

Thanks for the examples!

google/oss-fuzz#7434

Given the brittleness of MSan, I'm inclined for us to just start stop importing MSan issues by default period.

google/oss-fuzz-vulns#25

This looks like some infrastructure issue that should've hopefully been fixed since.

google/oss-fuzz-vulns#35

This looks like a legitimate OSS-Fuzz environment issue.

I'd also point out things like https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html

This wasn't us :) And we still have no idea who was submitting these CVEs.. particularly during an early time when this pipeline wasn't very mature.

More generally, if we a) stop doing this automatically for all MSan issues, and b) improve infrastructure reliably to a point where you no longer see missing fixes, and implement the UX fixes in #2176 (comment), would you be open to turning this back on again?

It's important for us to not turn this off by default for all OSS-Fuzz projects, because we've more often than not observed projects fixing vulnerabilities without ever notifying downstream consumers or requesting a CVE (because it's a lot of work).

[evverx]

More generally, if we a) stop doing this automatically for all MSan issues, and b) improve infrastructure reliably to a point where you no longer see missing fixes, and implement the UX fixes in #2176 (comment), would you be open to turning this back on again?

I think it depends. It would still be necessary to filter out reliability bugs that have nothing to do with security to prevent them from ending up in the OSV database and I'm not sure who is going to do that. Though if

When OSV imports an issue, if the issue was not triaged, include a big warning that this may not be a real security issue due to frequent OSS-Fuzz false positives

was implemented I think they would be less likely to trigger overzealous vulnerability scanners.

we've more often than not observed projects fixing vulnerabilities without ever notifying downstream consumers or requesting a CVE (because it's a lot of work)

I understand that but I'm not sure how it can be fixed. Downstream consumers should be able to deal with that in general.

[oliverchang]

When OSV imports an issue, if the issue was not triaged, include a big warning that this may not be a real security issue due to frequent OSS-Fuzz false positives

was implemented I think they would less likely to trigger overzealous vulnerability scanners.

I'm thinking this can be a bit somewhere inside the database_specific section of the relevant imported OSV entry. If a maintainer has acknowledged the bug somewhere (e.g. via the issue tracker), then this would be true.

[evverx]

this can be a bit somewhere inside the database_specific section of the relevant imported OSV entry

As far as I understand it would work like "confidence" from #2176 (comment) so I think it should help. Though I suspect this bit is likely to be false in a lot of entries because (most?) projects aren't particularly interested in vetting OSV entries.