Inaccurate commit ranges (OSS-Fuzz)

[evverx]

As far as I understand OSV issues coming from OSS-Fuzz can't be bisected past the point where fuzz targets were introduced. For example https://osv.dev/vulnerability/OSV-2018-152 points to systemd/systemd@45a7bec and that's just the first commit where OSS-Fuzz was able to build and run that particular fuzz target. Given that a lot of "shallow" issues are discovered as soon as fuzz targets are added and their commit ranges point straight to fuzz targets (especially when they are kept upstream) I think it would be great if OSV could show that in some cases those ranges can't be copy-pasted verbatim and should be analyzed further. There are other scenarios where the bisection analysis fails but I think they are much harder to detect automatically.

[evverx]

Just to clarify I think ideally it would be great if it was possible to track down bugs as far as possible but in practice I don't think it can be automated in general so the idea is to at least somehow make it clear that even though OSV issues say that bugs are introduced and fixed immediately they can actually be much older and span much more versions.

[oliverchang]

Thanks @evverx! As you mention, this is a pretty challenging problem for us to solve automatically.

Do you have any suggestions on this part?

at least somehow make it clear that even though OSV issues say that bugs are introduced and fixed immediately they can actually be much older and span much more versions.

[evverx]

I think if instead of "introduced" some other field named, say, "present in" was used that could convey that those commits are just known to trigger bugs it would probably be more clear. Another option would be to add something like "confidence" to show how confident OSV is that bugs are introduced in certain commits. When fuzz targets vanish the "confidence" field could be 0 or something like that.

[oliverchang]

I think if instead of "introduced" some other field named, say, "present in" was used that could convey that those commits are just known to trigger bugs it would probably be more clear. Another option would be to add something like "confidence" to show how confident OSV is that bugs are introduced in certain commits. When fuzz targets vanish the "confidence" field could be 0 or something like that.

These are machine readable fields, and adding this distinction will complicate the spec. Potentially, these are things that could go into https://ossf.github.io/osv-schema/#database_specific-field, but it's unclear to me how this indication will help when the use case we are trying to enable is automated matching of vulns in dependencies.

[evverx]

it's unclear to me how this indication will help when the use case we are trying to enable is automated matching of vulns in dependencies

For example systemd heavily relies on libblkid for dissecting images these days (so it's fair to say that it's a systemd dependency) and recently OSS-Fuzz discovered https://osv.dev/vulnerability/OSV-2022-1157 (which can be triggered by supplying malformed images to systemd/systemd-dissect/systemd-portabled/bootctl one way or another as long as util-linux <= 2.38). OSV points to util-linux/util-linux@d9edc38 (where the fuzz target was introduced) so if I looked at OSV only I would miss all bugs in dependencies like that. If OSV somehow indicated that it wasn't exactly confident that issue could at least be flagged for further analysis. It wouldn't be 100% automatic of course but it's better than missing potentially interesting issues altogether.

[evverx]

I think realistically people aren't going to look at those OSV entries so all in all I don't think extending the spec can help much here.