The bogus CVE problem

Posted Sep 14, 2023 0:04 UTC (Thu) by wahern (subscriber, #37304)
In reply to: The bogus CVE problem by geofft
Parent article: The bogus CVE problem

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.