Docs Overview
Project
Bug Bounty Bug Report Code of conduct Dependencies Donate FAQ Features Governance History Install Known Bugs Logo TODO website Info
Protocols
CA Extract HTTP cookies HTTP/3 MQTT SSL certs SSL libs compared URL syntax WebSocket
Releases
Changelog curl CVEs Release Table Version Numbering Vulnerabilities
Tool
Comparison Table curl man page HTTP Scripting mk-ca-bundle Tutorial When options were added
Who and Why
Companies Copyright Sponsors Thanks The name
curl / Docs / curl CVEs / Bogus report filed by anonymous
Related:
Audits
Bug Bounty
Changelog
curl CVEs
JSON metadata
Vulnerability Disclosure
Vulnerabilities Table

CVE-2023-52071

Bogus report filed by anonymous

Project curl Security Dismissal, January 30 2024 - Permalink

VULNERABILITY

None. CVE-2023-52071 was filed and made public by an anonymous person due to incompetence or malice. We cannot say which and the distinction does not matter to us.

The original description said:

tiny-curl-8_4_0, curl-8_4_0 and curl-8_5_0 were discovered to contain an off-by-one out-of-bounds array index via the component tool_cb_wrt.

INFO

CVE-2023-52071 was published on January 30 2024. Its existence was reported to us the same day.

The CVE references a git commit that fixes an assert. The assert itself accesses a stack based buffer one byte out of boundary. This code is only included in debug builds and never in release-builds. Even in debug builds it is not a security problem.

The referenced bug was introduced in a commit done on April 4 2023 (shipped in 8.3.0), later fixed again in a commit merged on September 13 2023 (shipped in 8.4.0).

AFFECTED VERSIONS

It does not affect any version. It is not a security problem. It was a bug that we fixed in September 2023.

SOLUTION

Relax. Use curl as usual.

The curl security team first 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.

In spite of that, MITRE eventually (after the email below), changed status for this CVE to REJECTED anyway.

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 am 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 is 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 does 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 does 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 is not complicated.

/ Daniel

RECOMMENDATIONS

Do not blindly trust the CVE system. It is full of cracks and bogus reports such as CVE-2023-52071.

TIMELINE

This CVE was made public on January 30 2024. We were notified about it on January 30.

CREDITS

Thanks a lot!