CVEs based on OSS-Fuzz reports

[evverx]

It seems some CVEs are assigned automatically based on OSS-Fuzz reports, which in turn triggers requests to update "vulnerable" packages. I think in general it makes sense but looking at some of those "medium" CVEs with "exploits" referring to crashes and backtraces copy-pasted from monorail with no way to trigger them in practice it would be nice if they could be vetted a bit better. The latest example would be a CVE assigned to libbpf that can be only triggered with broken toolchains (clang, llvm-strip and bpftool) by somehow tricking programs using those bpf skeletons into loading them. I mean, if the toolchain is that broken (or subverted) I think a libbpf bug isn't the worst issue there :-) I wonder if this process can be improved somehow so as not to waste people's time. As far as I can remember OSS-Fuzz has nothing to do with those CVEs but I don't know where else to report this.

[evverx]

On a somewhat related note I don't think CVEs can be assigned fully automatically because quite often it seems ClusterFuzz can't point to commits where bugs are fixed so it's necessary to bisect codebases with their fuzz targets manually. Another issue is that sometimes ClusterFuzz seems to group issues where their security impact is deduced from the most severe issues in those groups but bug reports on Monorail describe some other less severe issues from those groups so it's also necessary to run fuzz targets with provided testcases for a few minutes to get those severe issues. As far as I can tell, that usually happens to newly integrated projects.

[DavidKorczynski]

Perhaps related (at least on the CVE issuing): #6782

[evverx]

Looking at that CVE I'm not sure it was assigned fully automatically because someone appears to have taken the time to translate the unclickable commit ranges to a few links on GitHub. Plus nobody seems to have claimed that there were "exploits". The CVE refers to "patches" and "advisories".

[evverx]

I think I'll switch to CFLite

[oliverchang]

Sorry for the bad CVEs @evverx and thanks for the feedback! As you mention, we didn't generate those CVEs but we'll get in contact with some of our CVE contacts and figure out what's going on there and if we can work out a better process where the community can have input. I'll keep this issue open to track that.

Switching from OSS-Fuzz to only CFLite (and losing the many benefits) because of a 3rd party issuing bad advisories is not ideal :)

[evverx]

a better process where the community can have input

I think it's already kind of possible in the sense that CVEs like that can be disputed and the idea probably was to rely on that and treat all OSS-Fuzz bugs as security issues with that auto-generated impact. But personally I don't care about that enough to go out of my way to do that :-)

I generally agree that it would be nice to automate some things based on OSS-Fuzz bugs reports but having gone through a lot of of those bugs manually (for educational purposes only :-)) I'm not sure how to do that. There are remote DOSes hiding behind infinite loops manifesting themselves as timeouts that don't end up in the OSV database and so on. Apart from that, unclickable commit ranges and other UX stuff like that makes it kind of hard to use OSS-Fuzz bug reports for fully automated analysis. I think those issues should be addressed somehow and probably whoever that is who is trying to turn OSS-Fuzz into a machine bombarding people with CVEs should maybe start going through bugs manually and working with the OSS-Fuzz team and try to resolve issues popping up here and there. Unfortunately it isn't as easy as writing a bash script using the OSV API.

Switching from OSS-Fuzz to only CFLite (and losing the many benefits)

CFlite is compatible with forks though and that's where it outshines OSS-Fuzz and CIFuzz :-)

[evverx]

Forgot to mention that since OSV is based on OSS-Fuzz bug reports "shallow" issues that are fixed when fuzz targets are integrated usually aren't reported on Monorail but since fuzzers are public they are actually run against "stable" releases (the latest example would be https://sourceware.org/bugzilla/show_bug.cgi?id=28666 "We fuzzed with a modified oss-fuzz, so it can be reproduced with oss-fuzz steup.") and I'm not sure how to include those bugs in the OSV database either. Anyway, what I'm trying to say is that there are issues preventing OSS-Fuzz from being used to keep track of all the bugs fuzz targets are capable to discover and ideally they should have been addressed before rolling out those bash scripts.

I'd go as far as to say that for the infrastructure based on OSV to keep up with bugs all OSS-Fuzz bug reports should be public by default but I think I lost that battle a long time ago :-)

[jonathanmetzman]

CFlite is compatible with forks though and that's where it outshines OSS-Fuzz and CIFuzz :-)

Why is this so important? just curious.

[evverx]

Some projects like systemd for example keep their stable branches in forks so when patches are backported it makes sense to run various tests there as well to make sure bugs/regression aren't introduced.

[jonathanmetzman]

Ah. got it!

[evverx]

FWIW I'm not sure CFLite can cover a scenario where several branches are maintained at the same time but considering that usually the latest stable branch is most important one branch should do I think :-)

[jonathanmetzman]

FWIW I'm not sure CFLite can cover a scenario where several branches are maintained at the same time

Why can't it? Because it doesn't upload corpus and whatnot to branch specific locations?

[evverx]

As far as I understand CFLite gets the latest builds using a "plain" list of artifacts returned by GH API so PRs opened against two different branches are compared against the same latest builds. I have to admit I haven't done enough digging to be 100% sure though

[evverx]

Why can't it? Because it doesn't upload corpus and whatnot to branch specific locations?

@jonathanmetzman I took a closer look and I don't think it has anything to do with CFLite itself. It uses "scheduled" GH Actions like "cf_cron", "cf_build" and "cf_batch" to update fuzz targets, corpora and coverage data regularly but actions like that use only default branches (or more precisely the last commit on default branches) so it seems to be a Github limitation CFLite can't do anything about.

[DavidKorczynski]

we didn't generate those CVEs but we'll get in contact with some of our CVE contacts and figure out what's going on there

@oliverchang do you have any updates here?

I have been in contact with the maintainers (Simon Kelley) of Dnsmasq who has also experienced OSS-Fuzz CVEs being "automatically" (and incorrectly) filed, specifically:
https://nvd.nist.gov/vuln/detail/CVE-2021-45951
to
https://nvd.nist.gov/vuln/detail/CVE-2021-45957

[oliverchang]

Thanks for the ping! we're still trying to follow up to see who's requesting these, and if there's a way for us to request amendments to these entries.

[evverx]

I haven't seen this recently so I'll go ahead and close this issue. More generally I don't think OSS-Fuzz can do anything about this. By the way there is apparently a new thing where unfixed issues get reported to upstream projects over and over again wit POCs and stuff like that :-) Those are reported by actual people (sometimes) though so it's less annoying probably.