Disputed, Not Rejected
daniel.haxx.se
Disputed, Not Rejected
1–10 of 21 posts
Re: Disputed, Not Rejected
#2We 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.
Re: Disputed, Not Rejected
#3On 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.
Re: Disputed, Not Rejected
#4On 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……
what if certain institutionally affiliated people are paid to use the CVE to report potential issues, and management gets paid to approve that?
Re: Disputed, Not Rejected
#5Very 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.
Re: Disputed, Not Rejected
#6On 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……
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.
Re: Disputed, Not Rejected
#7Very 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 approp…
Agreed!
Just one quibble: the reporter was anonymous, so they aren't doing it for prestige. Perhaps it's griefing?
Re: Disputed, Not Rejected
#8Very 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 approp…
Agreed! 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.
Re: Disputed, Not Rejected
#9Interesting 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.
Re: Disputed, Not Rejected
#10On 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……
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 secu…
[deleted]