Skip to main content

Hello #MITRE, (regarding CVE-2023-52071)

Well, first I of course think that the "burden of proof" would be on the person that insists that there is a problem. The one saying that this is a #CVE should provide the necessary details to explain "beyond reasonable doubt" that the identified problem is a vulnerability. There are no such details or explanations provided in the existing CVE. There is nothing there that identifies a vulnerability.

#cve #mitre
in reply to daniel:// stenberg://

daniel:// stenberg://
daniel:// stenberg://
• •

I'm convinced someone just grepped commit messages for this and submitted a #CVE and there was nothing and no one that even tried to confirm or check that this was actually legitimate. There was no filter in place and it was incorrectly let through. That's why it should be rejected. Saying it is "disputed" hints that there can be different views on this subject.

So, you are asking me to explain how this not identified vulnerability is actually not identifying a vulnerability.

#cve
in reply to daniel:// stenberg://

daniel:// stenberg://
daniel:// stenberg://
• •

Let me try:

The claimed issue identifies a bug in curl that

1. only existed in debug-builds (thus disqualified)

2. even in debug-builds, a bad access will at worst cause a crash, which is also what assert itself does when triggered. Thus having the same end result. Not a vulnerability.

3. in most situations, the bad access will not cause any problems at all, even in debug-builds (because the accessed stack memory is readable)

in reply to daniel:// stenberg://

daniel:// stenberg://
daniel:// stenberg://
• •

My claims can easily be verified and double-checked by simply reading the code. It's not complicated.

/ Daniel

in reply to daniel:// stenberg://

maswan
maswan
• •
It seems to me that this process is designed for closed software with commercial vendors who's first reaction is blanket denial of any vulnerability, and not good-faith actors with source code to back up claims.
in reply to maswan

daniel:// stenberg://
daniel:// stenberg://
• •
@maswan indeed. And a process that makes it impossible for a good faith vendor to REJECT bad faith claims, which is really upsetting. It seems the only remedy available is to make it "DISPUTED" and provide text for that. (I'm "protesting" against this too, separately)
@maswan
in reply to daniel:// stenberg://

timthelion
timthelion
• •

I'd like to file a CVE against Daniel Stenberg. He can easily DOSed simply by telling him that there is a security vulnerability in curl. Daniel is a key piece of internet infrastructure responsible for maintaining mission critical software.

Unfortunately, he can be put out of service for hours simply by putting a number next to the letters C.V. and E This needs to be patched immediately. Where can I report this?

in reply to daniel:// stenberg://

the vessel of morganna
the vessel of morganna
• •
After the first few bogus CVEs I wouldn't be surprised if some anonymous asshole is going out of their way to do this just to waste your time :/
in reply to the vessel of morganna

daniel:// stenberg://
daniel:// stenberg://
• •
I waste this time in the hope that I "take one for the team". With a little luck I can push the system ever so slightly in the right direction. Then, over time, at some future point, we might be in a better situation...
This entry was edited (2 months ago)
in reply to daniel:// stenberg://

mort
mort
• •
The existence of this CVE is obviously annoying in itself, but how did it end up with a severity of "medium"? What about "debug builds may harmlessly read unintended stack memory in a way which doesn't cause a crash or memory corruption or info disclosure" suggests "medium severity"
in reply to daniel:// stenberg://

sigi714
sigi714
• •
Lets add CVSS with Debug Mode = 0 for Access Vector, Access Complexity and Authentication as a quick workaround
¯\_(ツ)_/¯
⇧