GSD-2022-2414 update

[random-oskar]

POC on https://github.com/superhac/CVE-2022-2414-POC

[kurtseifried]

Ok meta comments:

Obviously, we want this added as a reference, but the OSV schema only supports:

https://ossf.github.io/osv-schema/#references-field

ADVISORY: A published security advisory for the vulnerability. ARTICLE: An article or blog post describing the vulnerability. REPORT: A report, typically on a bug or issue tracker, of the vulnerability. FIX: A source code browser link to the fix (e.g., a GitHub commit) Note that the fix type is meant for viewing by people using web browsers. Programs interested in analyzing the exact commit range would do better to use the GIT-typed affected[].ranges entries (described above). PACKAGE: A home web page for the package. EVIDENCE: A demonstration of the validity of a vulnerability claim, e.g. app.any.run replaying the exploitation of the vulnerability. WEB: A web page of some unspecified kind.

So it could be classed as "EVIDENCE", which ios what I'll use for now, but I'm going to file an upstream issue with OSV to try for a better word, e.g.:

REPRODUCER: Nonweaponized, programmatic method to trigger the vulnerability? EXPLOIT: weaponized, programmatic method to trigger the vulnerability (can be a link to code?) EXPLOITATION: reports of exploitation but no actual technical reproducer/exploit available?

[joshbressers]

I'm comfortable adding our own fields as needed. I expect we will have different needs and use cases form OSV. I think it's a bad idea to try to align the lists

[oliverchang]

Sorry for the delay in responding on the OSV issue (been a busy week). If we could, let's work out a way this can work for all of us. Our "needs and use cases" just come from our designing principles of keeping the schema as minimal as possible and making sure we're very intentional about use cases for everything we add.

I would argue that is part of why OSV is liked by most users (as opposed to other more heavyweight, bloated formats :) ) Let's continue discussion about this one in particular in the OSV issue.

[kurtseifried]

One comment when you say "keeping the schema as minimal as possible" do you mean the schema in general or more primarily the "required" schema?

[oliverchang]

One comment when you say "keeping the schema as minimal as possible" do you mean the schema in general or more primarily the "required" schema?

In general! Having to read through walls of text to understand what's in a format is definitely not ideal in my mind. Technically, {"id": "FOO-123", "modified": "date"} is a valid OSV entry as that's all that's required.

[kurtseifried]

Speaking of which in the OSV data there's a lot of aliases of just some number:

["CVE-2020-3671","2576091"]

which makes it... hard to track, or know where it came from, e.g. unless an alias is unique (so not just a number) and identifiable, e.g. CVE-, GSD-, RHSA-, it's basically just confusing. To quote the docs:

The aliases field gives a list of IDs of the same vulnerability in other databases, in the form of the id field. This allows one database to claim that its own entry describes the same vulnerability as one or more entries in other databases. Or if one database entry has been deduplicated into another in the same database, the duplicate entry could be written using only the id, modified, and aliases field, to point to the canonical one.

but there's no data around which database that alias is for...

I feel like I should open up another ticket to discuss this as a pile of random numbers that end up overlapping between different entries is going to be problematic.

[oliverchang]

That's indeed an interesting problem! But I think that's the job of the aggregator (e.g. https://osv.dev) to link and resolve across all of the different sources.

Let's discuss this in a separate issue?

[joshbuker]

Added via #2454, closing.