sucks that you have to deal with this :( Do you have any idea who is filing these and what their motivation is? Or do they believe these to be genuine bugs?
> The curl security team will work on getting this CVE rejected.
Good luck on that. At best, it will be labelled as "disputed".
I would recommend you to become a CNA yourself for curl. The general CVE policy is that any reporter need to first reach out to the appropriate CNA to get a CVE for an issue. A reporter can go to a root CNA too, but only after the project CNA has been reached. And there are some conflict resolution policy if the CNA and reporter disagrees.
It's a bit of "paperwork" and administrative steps to get approved as a CNA. You need to document security policies and processes and show you understand how CVE's are worded and registered. But I would expect curl to be in a good position to get approved.
We did that a while back in OpenVPN. And the tooling (in particular cvelib) makes it pretty easy to register and publish CVEs.
@0ddj0bb yes it is. Numerous projects get the same kind of crap. This is not an isolated case. I can't say numbers, but I would say there are easily hundreds of equally bad/bogus ones.
@joshbressers @hanno correct, but this was filed before we were accepted. We are now getting it assigned so I believe we will get the mandate to reject it... we'll soon find out!
AFAIR, to reject it has a very high barrier, like not being relevant to the project it's assigned to at all. Or pointing at features/code paths not available and such things. Basically the content of CVE record is completely wrong, not the claim towards the project itself.
I would expect DISPUTED being the right solution, preferably with a URL to the detail why it's wrong.
There is a closed CVE slack where such things can be discussed, though.
Wait, what? I can get up to 5 kilodollars for reporting bugs that curl has already fixed as new security issues and providing the patch, that curl has already made, as a fix? Where do I sign up? I could start buying LEGO if this works.
jomo
in reply to daniel:// stenberg:// • • •Do you have any idea who is filing these and what their motivation is? Or do they believe these to be genuine bugs?
daniel:// stenberg://
in reply to jomo • • •daniel:// stenberg://
Unknown parent • • •Peter Kovář
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to daniel:// stenberg:// • • •We are going to try to reject it proper, but here is my take on it:
curl.se/docs/CVE-2023-52071.ht…
curl - Bogus report filed by anonymous - CVE-2023-52071
curl.sehanno
in reply to daniel:// stenberg:// • • •Peter Kovář
in reply to daniel:// stenberg:// • • •Efraim Flashner
in reply to daniel:// stenberg:// • • •🔗 David Sommerseth
in reply to daniel:// stenberg:// • • •> The curl security team will work on getting this CVE rejected.
Good luck on that. At best, it will be labelled as "disputed".
I would recommend you to become a CNA yourself for curl. The general CVE policy is that any reporter need to first reach out to the appropriate CNA to get a CVE for an issue. A reporter can go to a root CNA too, but only after the project CNA has been reached. And there are some conflict resolution policy if the CNA and reporter disagrees.
It's a bit of "paperwork" and administrative steps to get approved as a CNA. You need to document security policies and processes and show you understand how CVE's are worded and registered. But I would expect curl to be in a good position to get approved.
We did that a while back in OpenVPN. And the tooling (in particular cvelib) makes it pretty easy to register and publish CVEs.
daniel:// stenberg://
in reply to 🔗 David Sommerseth • • •curl is a CNA | daniel.haxx.se
daniel.haxx.se🔗 David Sommerseth
in reply to daniel:// stenberg:// • • •Martin Peck
in reply to daniel:// stenberg:// • • •This is perfect...
"We cannot say which and the distinction does not matter to us."
Max
in reply to daniel:// stenberg:// • • •0ddj0bb Is At Cyphercon
in reply to daniel:// stenberg:// • • •"Do not blindly trust the CVE system. It is full of cracks and bogus reports such as CVE-2023-52071."
Okay that seems a bit extreme. Sure do your research seems verify stuff but is it really full of bogus reports?
daniel:// stenberg://
in reply to 0ddj0bb Is At Cyphercon • • •0ddj0bb Is At Cyphercon
in reply to daniel:// stenberg:// • • •i wouldn't call 5.8% of cves to be "full" of junk.
Maybe I'm just focusing too much on full there. Just seems unnecessary hyperbole that tries to call the entire nvd into question on its credibility.
It does seem nvd does respond well to rejection process.
daniel:// stenberg://
in reply to 0ddj0bb Is At Cyphercon • • •0ddj0bb Is At Cyphercon
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to 0ddj0bb Is At Cyphercon • • •0ddj0bb Is At Cyphercon
in reply to daniel:// stenberg:// • • •they literally have a dashboard
nvd.nist.gov/general/nvd-dashb…
NVD - NVD Dashboard
nvd.nist.govdaniel:// stenberg://
in reply to 0ddj0bb Is At Cyphercon • • •daniel:// stenberg://
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
Unknown parent • • •🔗 David Sommerseth
in reply to daniel:// stenberg:// • • •@joshbressers @hanno
AFAIR, to reject it has a very high barrier, like not being relevant to the project it's assigned to at all. Or pointing at features/code paths not available and such things. Basically the content of CVE record is completely wrong, not the claim towards the project itself.
I would expect DISPUTED being the right solution, preferably with a URL to the detail why it's wrong.
There is a closed CVE slack where such things can be discussed, though.
Yaksh Bariya
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to daniel:// stenberg:// • • •Wilhelm S. Bankenstein
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to daniel:// stenberg:// • • •Arnaud Launay
in reply to daniel:// stenberg:// • • •mhoye
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to mhoye • • •mhoye
in reply to daniel:// stenberg:// • • •christina | twyn!b
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to christina | twyn!b • • •Lars Wirzenius
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Lars Wirzenius • • •freund
in reply to daniel:// stenberg:// • • •I like how the description is just straight up wrong:
"The product uses untrusted input when calculating or using an array index, [...]",
when the patch they even refer to makes it obvious that there is no input involved at all.
daniel:// stenberg://
in reply to freund • • •Fabian ¯\_(ツ)_/¯
in reply to daniel:// stenberg:// • • •