Skip to content

Commit

Permalink
CVE-2023-52071.md: provide "explanation"
Browse files Browse the repository at this point in the history
Extends this document with most details from the email I have sent with
a description to add to the public CVE record since we cannot REJECT
this and have to live with it as DISPUTED.

Closes #329
  • Loading branch information
bagder committed Feb 20, 2024
1 parent 9d1366d commit cccb89c
Showing 1 changed file with 41 additions and 1 deletion.
42 changes: 41 additions & 1 deletion docs/CVE-2023-52071.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,47 @@ SOLUTION

Relax. Use curl as usual.

The curl security team will work on getting this CVE rejected.
The curl security team tried to get this CVE rejected. The MITRE system
unfortunately makes that impossible. We can only make this CVE get marked
**DISPUTED**, which we are not satisfied with but have to accept under
protest.

EXPLANATION
-----------

First we 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.

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.

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 the 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)

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

/ Daniel

RECOMMENDATIONS
--------------
Expand Down

0 comments on commit cccb89c

Please sign in to comment.