Disputed, Not Rejected(daniel.haxx.se)
daniel.haxx.se
Disputed, Not Rejected
https://daniel.haxx.se/blog/2024/02/21/disputed-not-rejected/
20 comments
To be fair, it is possible for a command to obfuscate it's own command line (I've seen this in `ps auwx` but can't offhand recall which command was doing it).
But in no way is that high - CVE ratings have turned to useless junk quite rapidly, probably sometime around when it became monetizable.
But in no way is that high - CVE ratings have turned to useless junk quite rapidly, probably sometime around when it became monetizable.
Obfuscating your commandline is racy. The only fix for issues like this is to not pass passwords on the commandline, except when debugging.
[deleted]
Yeah, having to deal with the level 10 CVE for Postgres from Tuesday.
https://nvd.nist.gov/vuln/detail/CVE-2024-1597
Postgres drivers are now all highly vulnerable and blocked in our pipelines because of overeager security, level 10 means that we can't get waivers for it either.
But you can't exploit because no one uses PreferQueryMode=SIMPLE.
https://nvd.nist.gov/vuln/detail/CVE-2024-1597
Postgres drivers are now all highly vulnerable and blocked in our pipelines because of overeager security, level 10 means that we can't get waivers for it either.
But you can't exploit because no one uses PreferQueryMode=SIMPLE.
Very interesting read, written with understandable fury.
I find it concerning that software projects have to become CNAs to at least alleviate the harm of bogus CVEs.
There surely is some sort of CVE peer review? This should be possible for indefinitely long time after registering a CVE, because humans make mistakes.
So it shouldn't be needed to shy away from marking CVEs as invalid / rejected retroactively if appropriate.
It is understandable to err on the side of caution with vulnerability reports, but since reporting vulnerabilites has become an object of prestige, it seems needed to ramp up the scrutiny.
I find it concerning that software projects have to become CNAs to at least alleviate the harm of bogus CVEs.
There surely is some sort of CVE peer review? This should be possible for indefinitely long time after registering a CVE, because humans make mistakes.
So it shouldn't be needed to shy away from marking CVEs as invalid / rejected retroactively if appropriate.
It is understandable to err on the side of caution with vulnerability reports, but since reporting vulnerabilites has become an object of prestige, it seems needed to ramp up the scrutiny.
I wonder if the curl people are giving this more attention than it deserves.
I’ve reported (and fixed) a number of security issues over the years. Sometimes I get them CVE numbers. I’ve never believed that MITRE or NVD added the slightest bit of value in their analyses.
The whole industry should recognize that CVEs are just a number. They are not, in and of themselves, worthy of entries on resumes, use in academic analyses, or much else. They simply identify an issue that may or may not be a security issue. There is an entire industry (of distros, etc) that triage issues and maybe deploy fixes, and for better or for worse that industry often requires a CVE number for its internal tracking.
So assigning a CVE number in general seems about as meaningful as assigning any other string. If I say “FOOBAR-12345: I don’t like how ‘curl’ is spelled”, then that means about what it sounds like, that is, not much.
I’ve reported (and fixed) a number of security issues over the years. Sometimes I get them CVE numbers. I’ve never believed that MITRE or NVD added the slightest bit of value in their analyses.
The whole industry should recognize that CVEs are just a number. They are not, in and of themselves, worthy of entries on resumes, use in academic analyses, or much else. They simply identify an issue that may or may not be a security issue. There is an entire industry (of distros, etc) that triage issues and maybe deploy fixes, and for better or for worse that industry often requires a CVE number for its internal tracking.
So assigning a CVE number in general seems about as meaningful as assigning any other string. If I say “FOOBAR-12345: I don’t like how ‘curl’ is spelled”, then that means about what it sounds like, that is, not much.
It can be an incredible hassle to have a bullshit CVE "high" assigned to a project when you're dealing with various requirements and reporting.
Assuming the curl dude actually makes some money selling services to people who have to do that reporting, he now has to not only show that the "high" CVE is fixed in the latest release, but go and back port a fix to all the versions that are being "maintained" for these customers who have to fill out reports about CVEs.
Even if all you have to do is respond to each with a "here's why this is bullshit", it still takes some time, time that could be better spent posting on HN.
Assuming the curl dude actually makes some money selling services to people who have to do that reporting, he now has to not only show that the "high" CVE is fixed in the latest release, but go and back port a fix to all the versions that are being "maintained" for these customers who have to fill out reports about CVEs.
Even if all you have to do is respond to each with a "here's why this is bullshit", it still takes some time, time that could be better spent posting on HN.
> It can be an incredible hassle to have a bullshit CVE "high" assigned to a project when you're dealing with various requirements and reporting.
Exactly. Last year, multiple CVEs were opened against node.js. They only impacted an experimental feature introduced in node 20, but NVD listed all versions of node as vulnerable (in contradiction with NVD's own summaries!). Many security tools treat NVD's word as gospel and refused to issue a correction in their findings, even though the erroneous reports were obvious and verifiable. It took multiple weeks for NVD to fix the entries despite receiving no doubt many emails about it.
Flaws in the CVE process waste tons of time, especially (it seems) at large orgs.
Exactly. Last year, multiple CVEs were opened against node.js. They only impacted an experimental feature introduced in node 20, but NVD listed all versions of node as vulnerable (in contradiction with NVD's own summaries!). Many security tools treat NVD's word as gospel and refused to issue a correction in their findings, even though the erroneous reports were obvious and verifiable. It took multiple weeks for NVD to fix the entries despite receiving no doubt many emails about it.
Flaws in the CVE process waste tons of time, especially (it seems) at large orgs.
Agreed!
Just one quibble: the reporter was anonymous, so they aren't doing it for prestige. Perhaps it's griefing?
Just one quibble: the reporter was anonymous, so they aren't doing it for prestige. Perhaps it's griefing?
Good point.
Reading the text, it also seems hard for MITRE to set general rules for when undefined memory access is a vulnerability.
Here it is not exploitable because it is only in a debug build and because the accessed memory is out-of-bounds in the intended context, but provably always within the memory bounds that are readable by curl, if I understand correctly.
For a case like this, it is easy to imagine this being one or two steps away from an actual vulnerability without having any actual security impact as-is.
So, not a vulnerability.
But requires explanation on why it isn't one.
Reading the text, it also seems hard for MITRE to set general rules for when undefined memory access is a vulnerability.
Here it is not exploitable because it is only in a debug build and because the accessed memory is out-of-bounds in the intended context, but provably always within the memory bounds that are readable by curl, if I understand correctly.
For a case like this, it is easy to imagine this being one or two steps away from an actual vulnerability without having any actual security impact as-is.
So, not a vulnerability.
But requires explanation on why it isn't one.
>but provably always within the memory bounds
That doesn't tell the whole story in C code, though. Out-of-bounds access is UB, thus the whole branch could be assumed to be never taken and optimized out by an enterprising compiler. In this case it will only cause missing characters in console output, but "will at worst cause a crash" is not entirely true.
That doesn't tell the whole story in C code, though. Out-of-bounds access is UB, thus the whole branch could be assumed to be never taken and optimized out by an enterprising compiler. In this case it will only cause missing characters in console output, but "will at worst cause a crash" is not entirely true.
On the one hand it seems like, if you are reporting a security issue, you should presumably have some kind of PoC. On the other hand we’ve seen plenty of exploits that required chaining a half dozen not-obviously-exploitable issues to achieve a successful exploit. If someone at MITRE has to adjudicate these issues for every CVE in all possible programming languages for all possible exploits for all possible software… well that seems like a tough job anyway.
I think the people using the CVE database as some kind of official source of actual security issues, as opposed to reported potential issues, is the problem.
I think the people using the CVE database as some kind of official source of actual security issues, as opposed to reported potential issues, is the problem.
I'm technically aware, but do I really have the expertise and bandwidth to tell the difference between an actual CVE and one that isn't, for the whole database?
The database isn't really much use unless it's pretty accurate, as few of us have the ability to evaluate correctness.
In this case, where there's an anonymous report, and a clear, near-elementary level explanation of how the code in question cannot be a security violation and has since been removed, the CVE should just be deleted, to save bandwidth for everyone.
The database isn't really much use unless it's pretty accurate, as few of us have the ability to evaluate correctness.
In this case, where there's an anonymous report, and a clear, near-elementary level explanation of how the code in question cannot be a security violation and has since been removed, the CVE should just be deleted, to save bandwidth for everyone.
[deleted]
> I'm technically aware, but do I really have the expertise and bandwidth to tell the difference between an actual CVE and one that isn't, for the whole database?
I sure don’t. But who does? Who gets paid by whom to make this all work? Apparently whatever is happening now ain’t it.
I sure don’t. But who does? Who gets paid by whom to make this all work? Apparently whatever is happening now ain’t it.
what if certain institutionally affiliated people are paid to use the CVE to report potential issues, and management gets paid to approve that?
We should be defending the creators of our most important tools, like `curl`, from gratuitous time-wasters like these!
I'm glad the `curl` organization is a CMA now, though, maybe that will mitigate the issue.
I'm glad the `curl` organization is a CMA now, though, maybe that will mitigate the issue.
Interesting that there seems to be two approaches to this - curl actually wants to carefully assign CVE only to security issues, Linux wants to defeat them with their own weapon by assigning CVE to every backported patch.
Sounds like the whole freegnix/nginx thing is farther reaching than just that project.
Many were questioning why he chose that particular hill to die on and I think article answers that question. It's a general problem and SOME CVE related hill needs to be chosen.
Many were questioning why he chose that particular hill to die on and I think article answers that question. It's a general problem and SOME CVE related hill needs to be chosen.
https://nvd.nist.gov/vuln/detail/CVE-2022-45868
Total waste of everybody's time. You have to start h2 as server, instead of as dependency. You then have to start it with a command line parameter with a password, instead of specifying it in a config file. Both actions scream debug-configuration. If you do this, then... the password is readable on the command line.
That's the whole vulnerability. Analogy: if you leave a key on the table, people inside the same house can take it, and that's a vulnerability for the door.
So now h2 is 'vulnerable', every application needs to upgrade the dependency, and everybody needs to upgrade the application. What a total waste of time.