3 ms·

My first impression was that this page was oddly defensive but, on the other hand, their criticisms of the CVE system made a fair amount of sense. Do others te

My first impression was that this page was oddly defensive but, on the other hand, their criticisms of the CVE system made a fair amount of sense. Do others tend to agree with those critiques?

aumerle 5y ago
Yes, CVEs are often exaggerated and sometimes just plain wrong. The bulk of them tend to be created by people that gain somehow, either financially or reputationally by creating them, and have no affiliation with either the person who originally discovered the bug or the upstream project that fixed the bug. Such people have every incentive to maximize impact and no incentive to do due diligence. And the review process for CVEs is entirely inadequate to the volume of the task.
noir_lord 5y ago
Yep - CVE's are sometimes overblown - particularly if they have a codename attached to them which became the trend once it entered the conscious.
vortico 5y ago
Yes, a lot of CVEs follow the form explained in the SQLite article, where you have to already have access to "gain access" in an unnecessarily complicated way. For example, `rm` has a vulnerability where if an attacker runs `rm -rf ~` on your machine, they will delete your home directory.
hannob 5y ago
I think the key problem is that people misunderstand what CVEs are. Ultimately CVEs are numbers given to a certain vulnerability. It helps so two people know they're talking about the same thing. A typical usecase would be that you have a security scanner that tells you your server is vulnerable to CVE-xxxx-xxxx and you can check the changelog of your server software which version fixes that. A CVE does not mean that a vulnerability is particularly important. It doesn't mean it's relevant for your use case. And a lot of CVEs does not mean the person who found them achieved something of significance. From a security perspective it makes sense to treat vulnerabilities that are minor and only relevant for rare use cases (or in combionation with other bugs) as vulnerabilities. But when you start counting vulnerabilities as achievements this distorts things. Plenty of shady security companies and research institutions making "statistics" about CVEs don't help either.
stux 5y ago
I think the tone of this page is frustration that this page needs to exist. I think if I had to constantly deal with stuff like this I'd be pretty frustrated too: > CVS-2019-19317 is an excellent example of a bogus CVE. This CVE describes a bug in an unreleased development version of SQLite. We were working on the new generated columns feature of SQLite, and a third-party hacker found an error in the code under active development, and then wrote a CVE against it. The error was fixed before the problem was ever released, and yet still there is this CVE sitting out there, unresolved, and as far as I can tell unresolveable. Lot's of great related discussion from drh in this[0] sqlite forum thread. [0]: https://sqlite.org/forum/forumpost/0e8b92001245dec1 https://sqlite.org/forum/forumpost/0e8b92001245dec1
- radarsat1 5y ago
  It applies to a lot of software actually, I've found that one of the implications of developing in the open is that people feel free to take whatever version they want and treat it the same as a release. The DVCS appears to have exacerbated this because people so often just attach their scripts to pull from "master" instead of respecting tagged releases. I've more than once discovered an in-development version of a library I'm working on appear as a package in Debian, for example. Suddenly I'm feeling responsible to maintain backward compatibility with an unreleased version because it's now "released" as far as users go. Of course what happened is that I asked the maintainers to remove it and then they never packaged any new versions of my software because of the interpersonal friction it caused.

My first impression was that this page was oddly defensive but, on the other hand, their criticisms of the CVE system made a fair amount of sense. Do others tend to agree with those critiques?

aumerle 5y ago

Yes, CVEs are often exaggerated and sometimes just plain wrong. The bulk of them tend to be created by people that gain somehow, either financially or reputationally by creating them, and have no affiliation with either the person who originally discovered the bug or the upstream project that fixed the bug. Such people have every incentive to maximize impact and no incentive to do due diligence. And the review process for CVEs is entirely inadequate to the volume of the task.

noir_lord 5y ago

Yep - CVE's are sometimes overblown - particularly if they have a codename attached to them which became the trend once it entered the conscious.

vortico 5y ago

Yes, a lot of CVEs follow the form explained in the SQLite article, where you have to already have access to "gain access" in an unnecessarily complicated way. For example, `rm` has a vulnerability where if an attacker runs `rm -rf ~` on your machine, they will delete your home directory.

hannob 5y ago

I think the key problem is that people misunderstand what CVEs are. Ultimately CVEs are numbers given to a certain vulnerability. It helps so two people know they're talking about the same thing. A typical usecase would be that you have a security scanner that tells you your server is vulnerable to CVE-xxxx-xxxx and you can check the changelog of your server software which version fixes that. A CVE does not mean that a vulnerability is particularly important. It doesn't mean it's relevant for your use case. And a lot of CVEs does not mean the person who found them achieved something of significance. From a security perspective it makes sense to treat vulnerabilities that are minor and only relevant for rare use cases (or in combionation with other bugs) as vulnerabilities. But when you start counting vulnerabilities as achievements this distorts things. Plenty of shady security companies and research institutions making "statistics" about CVEs don't help either.

stux 5y ago

I think the tone of this page is frustration that this page needs to exist. I think if I had to constantly deal with stuff like this I'd be pretty frustrated too: > CVS-2019-19317 is an excellent example of a bogus CVE. This CVE describes a bug in an unreleased development version of SQLite. We were working on the new generated columns feature of SQLite, and a third-party hacker found an error in the code under active development, and then wrote a CVE against it. The error was fixed before the problem was ever released, and yet still there is this CVE sitting out there, unresolved, and as far as I can tell unresolveable. Lot's of great related discussion from drh in this[0] sqlite forum thread. [0]: https://sqlite.org/forum/forumpost/0e8b92001245dec1 https://sqlite.org/forum/forumpost/0e8b92001245dec1

radarsat1 5y ago
It applies to a lot of software actually, I've found that one of the implications of developing in the open is that people feel free to take whatever version they want and treat it the same as a release. The DVCS appears to have exacerbated this because people so often just attach their scripts to pull from "master" instead of respecting tagged releases. I've more than once discovered an in-development version of a library I'm working on appear as a package in Debian, for example. Suddenly I'm feeling responsible to maintain backward compatibility with an unreleased version because it's now "released" as far as users go. Of course what happened is that I asked the maintainers to remove it and then they never packaged any new versions of my software because of the interpersonal friction it caused.