The bogus CVE problem

Posted Sep 13, 2023 21:10 UTC (Wed) by geofft (subscriber, #59789)
Parent article: The bogus CVE problem

William Woodruff's post from last year ReDoS "vulnerabilities" and misaligned incentives is another good look at this problem focusing particularly on people's excitement with superlinear regular expressions, and points out a very practical issue: a lot of automated security tools will report issues if any of the dependencies you're using have unresolved CVEs. This is well-intentioned, but for things that aren't actually vulnerabilities, it leads to needless churn and panic, and for things that are so much not a vulnerability that they aren't fixed, or aren't fixed except in the current development release, or similar, it may even cause deploy tools to refuse to deploy. Or, worse, it may cause well-funded corporate users to make demands of open-source projects to backport a patch that has no need to be backported. When there's an actual bug to fix, we can just lament the open-source sustainability problem, but when there isn't, it's nothing other than rude.

I actually think that this is, essentially, a DoS vulnerability in the CVE process itself. Anyone can submit an entry into a database that gets insufficiently validated and causes other people to have to scramble and respond and maybe makes their automated systems break. That's unauthenticated input causing denial-of-service attacks!

Also it occurs to me that CVE + CVSS actually does kind of provide a solution here. The point of CVE is that it's common, i.e., if someone else discovers the same vulnerability, there's a way to ideally give them the same CVE identifier or at least mark their new one as a duplicate. It feels like we should be able to proactively mark things as CVSS score 0, and say, yes, this is an integer overflow or stack corruption or whatever, but exploiting it rather involves being on the other side of this airtight hatchway, and so we're going to mark the fact that it exists so people who find it know it was already analyzed. And in some cases it makes sense to "fix" it, as with CVE-2020-19909. It's always better to print a real error message instead of "double free or corruption (fasttop)". (But I do wonder about the incentive system, as Woodruff mentions, of having CVEs on your résumé, and whether the existence of CVEs with CVSS scores of 0 will make things better or worse.)

The bogus CVE problem

Posted Sep 14, 2023 0:04 UTC (Thu) by wahern (subscriber, #37304) [Link] (5 responses)

All this is true enough, but proving that a vulnerability is protected by an "airtight hatchway" (i.e. is unexploitable in practice) is difficult, often more difficult than identifying the vulnerability. Not only is it difficult, but implementations and vendors are highly incentivized to wave away vulnerabilities with claims that they're unexploitable. But in most cases claims are never proven systematically, rather averred. And such assertions often are merely failures of imagination--defenders don't think like attackers, even when they're being earnest and diligent.

The CVE system has flaws--serious flaws. But I'd argue that these flaws are less severe than the alternative where vendors can more easily waive off reports. Let's not forget from whence we came--a time when vendors didn't take these things seriously unless and until bugs were already being conspicuously exploited in the wild. And we still have problems with too many vendors not taking CVEs seriously. The current system is unfair to conscientious developers and maintainers whose time is wasted by self-aggrandizing bug reporters, but we would never have needed the current CVE system if such conscientious people were the majority of those shipping software.

* There's a reason we can't have nice things. * No good deed goes unpunished. * Etc, etc.

The bogus CVE problem

Posted Sep 14, 2023 7:14 UTC (Thu) by madhatter (subscriber, #4665) [Link]

You do make a depressingly good point about software makers, particularly commercial ones, being incentivised to handwave vulnerabilities away. Bruce Schenier wrote this pithy response in last month's Crypto-Gram newsletter, in response to a vendor quote in a vice.com article about a vulnerability found in Tetra police radios:

> Specifically on the researchers’ claims of a backdoor in TEA1, Boyer added “At this time, we would like to
> point out that the research findings do not relate to any backdoors. The TETRA security standards have
> been specified together with national security agencies and are designed for and subject to export
> control regulations which determine the strength of the encryption.”

And I would like to point out that that’s the very definition of a backdoor.

The bogus CVE problem

Posted Sep 15, 2023 3:01 UTC (Fri) by florianfainelli (subscriber, #61952) [Link] (3 responses)

Unfortunately the CVE circus will continue to go on:

- EU CRA: https://www.european-cyber-resilience-act.com/
- US EO 14028: https://www.nist.gov/itl/executive-order-14028-improving-...

this will no doubt create an immense amount of work for projects, distributors, and so on, almost as if it was a jobs program.

The bogus CVE problem

Posted Sep 15, 2023 11:42 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (1 responses)

> this will no doubt create an immense amount of work for projects, distributors, and so on, almost as if it was a jobs program.

... or this garbage will convince many of us that too much is too much and it's time to switch jobs, maybe become a european deputee of some other such dummy jobs where you can vote for random rules that morons will blindly apply. I mean, there's no reason we should be their slaves, we're still free to stop maintaining projects that take too much time under such stupid rules, and let the internet fall apart as well.

The bogus CVE problem

Posted Sep 15, 2023 13:17 UTC (Fri) by pizza (subscriber, #46) [Link]

> ... or this garbage will convince many of us that too much is too much and it's time to switch jobs,

This is the most likely outcome.

> we're still free to stop maintaining projects that take too much time under such stupid rules, and let the internet fall apart as well.

Ah yes, but if you stop maintaining it, you're engaging in willful gross negligence and will be on the hook for $very_massive liabilities. And that's where things are heading.

Damned if you do, damned if you don't.

The bogus CVE problem

Posted Sep 22, 2023 6:46 UTC (Fri) by kunitz (subscriber, #3965) [Link]

I work in the financial industry and we live already in the regulated future. Basically if anything in your build has an unresolved high or critical rated CVE, you can't use it anymore. Right now we are in the process to move all our container images to Alpine, because it doesn't use all the user space tools. A normal Debian image has 70 to 100 high or critical rated CVEs.

Since there are so many software packages, nobody has the time to look at the detail of a CVE. If there is a CVE which is high or critical you have to make it disappear, regardless whether you actually use the functionality or expose the service in any way. The financial industry has the audit and governance structures to enforce such rules.

For me it looks like that dependency reduction will become very important in the industry. How open-source will deal with the requirements of the CRA will be interesting to see.