search

ossf / osv-schema

Open Source Vulnerability schema.
https://ossf.github.io/osv-schema/
Apache License 2.0
180 stars 77 forks source link

Add a "first_not_affected" field or similar to properly describe all possible ranges for affected packages #75

Open pereyra-m opened 2 years ago

pereyra-m commented 2 years ago

Description

Hi!

I was trying to express some NVD vulnerabilities with OSV. They use these keywords for the ranges

So we can have these type of intervals

But here in OSV, we have:

It isn't posible to express (X,..., Y] / (X,..., Y) ranges, we are missing an equivalen to versionStartExcluding.

Example

The https://nvd.nist.gov/vuln/detail/CVE-2022-34465 vulnerability has this type of ranges

example

chrisbloom7 commented 2 years ago

For context, this seems to be a duplicate of #31 and https://github.com/ossf/osv-schema/issues/35#issuecomment-1068498931, with versionStartExcluding being synonymous with the lower bound exclusive operator >.

pereyra-m commented 2 years ago

Thank you very much for indicating these related issues, I didn't know this had been discussed in the past.

We need to express the NVD vulnerabilities database in OSV format, and after that all the manual verification and curation process will begin. I've read in the related discussions you show that adding > is not ideal, because almost always it's possible to find the first version affected of the range.

But this is the way the NVD is expressing some vulnerabilities.

Let me add more examples:

https://nvd.nist.gov/vuln/detail/CVE-2022-22566

CVE-2022-22566

https://nvd.nist.gov/vuln/detail/CVE-2022-24724 CVE-2022-24724

https://nvd.nist.gov/vuln/detail/CVE-2022-24831 CVE-2022-24831

https://nvd.nist.gov/vuln/detail/CVE-2022-29243 CVE-2022-29243

oliverchang commented 2 years ago

Hi @pereyra-m, thanks for filing this issue.

FWIW, this was discussed as part of the CVE 5.0 schema as well (https://github.com/CVEProject/cve-schema/issues/87#issuecomment-905657161), where it was decided that a '>' operator was uncommon enough that it didn't warrant encoding in the new schema.

I do recognize that these come from NVD's CPE ranges instead of from the CVE itself -- do you have any numbers on how often these are used in the context of open source packages? A lot of the CPEs you pointed out seem to point to vendor specific products that can't be encoded in OSV anyway.

pereyra-m commented 2 years ago

Hi @oliverchang ! Thank you very much for your quick answer!

I can see that in CVE 5.0 this isn't supported and you are trying to be fully compatible. And I can also understand that in some situations the '>' operator could introduce some difficulties in the evaluation or even false positives.

But the examples I have shown are from the NVD where CVE 4.0 is used currently, and I'm trying to translate this database to OSV. If the NVD allows this, then those who fill the information can use it. Do you suggest that for this particular cases I use the affected[].ranges[].database_specific field?

Also, this means that CVE 5.0 has a breaking change and it won't be backward compatible with the expressions in CVE 4.0?

A lot of the CPEs you pointed out seem to point to vendor specific products that can't be encoded in OSV anyway.

Our teams needs to be able to detect vulnerabilities in both open/closed source software. Here I have some examples of open source vulnerabilities too. Some of them are in state UNDERGOING REANALYSIS, that's why the information isn't accurate or complete yet. But we can't skip them until the analysis is finished

source: https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2021.json.gz

https://nvd.nist.gov/vuln/detail/CVE-2021-20194 CVE-2021-20194

https://nvd.nist.gov/vuln/detail/CVE-2021-22187 CVE-2021-22187

https://nvd.nist.gov/vuln/detail/CVE-2021-22917 CVE-2021-22917

https://nvd.nist.gov/vuln/detail/CVE-2021-33037 CVE-2021-33037

https://nvd.nist.gov/vuln/detail/CVE-2021-3743 CVE-2021-3743

I couldn't tell you of often this is right now. Regards.