undefined | Better HN

0 pointslifthrasiir2y ago0 comments

It's indeed stupid in general, but many big F/OSS projects suffer too much from this issue that they really want to do this.

A possible resolution would be to have two kinds of CVE numbers: researchers can request and get assigned provisional CVE numbers that don't look like the current CVE numbers (e.g. pCVE-2021-3PF5), and the current CVE number format would be used for verified CVE numbers where the vendor(s) have confirmed them (e.g. CVE-2021-22204). Note that my example assumes that they still share the same identifier space: a conversion from "3PF5" to "22204" should be mechanical [1]. So researchers can still use pCVE numbers as needed, but proper CVE numbers would require vendor's cooperation. That sounds a reasonable trade-off for the security purpose.

[1] I've specifically used bijective vigesimal numbers with digits from Open Location Code in this example. So 1..20 = 2..X, 21..420 = 22..XX, 421..8420 = 222..XXX and so on. I've specifically picked OLC because it avoids many profanity possibilities, but an ideal scheme would also avoid all-number identifiers to clearly distinguish it from normal CVE numbers.

0 comments

PeterisP2y ago

I strongly disagree, whatever process we have should work also for 'hostile' vendors and allow for "the community" to verify and assert vulnerabilities even if the vendor denies them, attempts to take legal action, etc.

There are all kinds of options, perhaps national CERTs could override vendor decisions, perhaps something else, but we can't simply assume good-faith behavior from every vendor.

The whole reason why we have various community resources for tracking vulnerabilities was that relying on vendor behavior didn't (and doesn't) work, and it's up to the general public to figure out how force appropriate behavior with e.g. responsible disclosure deadlines, public shaming, etc; and CVEs are part of that mechanism of the community pushing reasonable standards on vendors whether they want it or not - since many vendors often have a clear financial motivation to act against user's interests, downplay and ignore vulnerabilities, and CVEs are for the benefit of system users, not vendors, they are how security researchers can communicate risks to the system users, with or without cooperation from the vendor.

lifthrasiirOP2y ago

CVE numbers are nothing more than identifiers for Common Vulnerabilities and Exposures of all sorts and all severities, so they theoretically do not require any kind of vendor confirmations. However in the reality CVE numbers are seen as some sort of absolute indication of unsafety---which is hardly true---to both security researchers and vendors. So we have two opposite problems now:

1. Security researchers are gaming the CVE system to get more CVE numbers in their portfolio, resulting in frustrated vendors. This is why curl and Linux Kernel went for being CVE numbering authority (CNA) but...

2. Vendors are also trying to reduce the number of CVE numbers assigned for their products, and while not every vendor CNA is that hostile, some do become CNA solely for this purpose.

I believe we should deemphasize the impact of CVE numbers to solve both problems. They should be just identifiers for researchers and users and should not necessarily convey any sort of insecurity---otherwise you will end up with hostile vendors. We can't change the reputation of current CVE numbers however, so I proposed a "provisional" CVE number that hopefully do not convey the same reputation. Hostile vendors can prevent any new (confirmed) CVE number to be assigned, but that's not very much different from today. But we can forbid them from preventing new provisional CVE number to be assigned, assuming an appropriate process update. So we still retain a reliable identifier for CVEs; they can possibly be provisional however.

fweimer2y ago

We tried that already, there used to be candidate CAN-* identifiers. Review to promote them to CVE-* identifiers was always a bottleneck.

lifthrasiirOP2y ago

That's a fair argument. But candidate numbers were abandandoned long before the current problem, back when there were only ~5000 CVE numbers assigned per year (vs. 52000+ for 2023). And more crucially, this review was done by the CVE Editorial Board, which is a small group of people who could vote for/against making it the "entry" status. That is clearly not scalable and I'm not proposing that. In fact, I believe there doesn't even need an actual vendor intervention to be "confirmed" in my scheme---the researcher should be able to attach a vendor response as an evidence in principle. (Of course such response can be forged, so there would have to be a proper process to counteract that.)

j / k navigate · click thread line to collapse

0 pointslifthrasiir2y ago0 comments

It's indeed stupid in general, but many big F/OSS projects suffer too much from this issue that they really want to do this.

0 comments

PeterisP2y ago

There are all kinds of options, perhaps national CERTs could override vendor decisions, perhaps something else, but we can't simply assume good-faith behavior from every vendor.

lifthrasiirOP2y ago

2. Vendors are also trying to reduce the number of CVE numbers assigned for their products, and while not every vendor CNA is that hostile, some do become CNA solely for this purpose.

fweimer2y ago

We tried that already, there used to be candidate CAN-* identifiers. Review to promote them to CVE-* identifiers was always a bottleneck.

lifthrasiirOP2y ago

j / k navigate · click thread line to collapse