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 / more POST-after-PUT confusion
Related:
Audits
Bug Bounty
Changelog
curl CVEs
JSON metadata
Original report
Vulnerability Disclosure
Vulnerabilities Table
Awarded 480 USD

CVE-2023-28322

more POST-after-PUT confusion

Project curl Security Advisory, May 17 2023 - Permalink

VULNERABILITY

When doing HTTP(S) transfers, libcurl might erroneously use the read callback (CURLOPT_READFUNCTION) to ask for data to send, even when the CURLOPT_POSTFIELDS option has been set, if the same handle previously was used to issue a PUT request which used that callback.

This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the second transfer.

The problem exists in the logic for a reused handle when it is (expected to be) changed from a PUT to a POST.

INFO

The code actually sending wrong data or doing a use-after-free is not present in libcurl code but are only presumed scenarios that might become the outcome of libcurl surprisingly calling the read callback in a situation where it is not expected to.

This flaw cannot be triggered with the command line tool.

This problem is almost identical to CVE-2022-32221. A difference this time is that setting CURLOPT_POST for the second transfer avoids the problem, where as only setting CURLOPT_POSTFIELDS after the PUT still makes the second transfer to a PUT and use the callback.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28322 to this issue.

CWE-440: Expected Behavior Violation

Severity: Low

AFFECTED VERSIONS

libcurl is used by many applications, but not always advertised as such!

SOLUTION

This time the logic is improved to avoid having two separate variable fields holding info about HTTP method and behavior. Now there is only one, which should make it harder to end up in such a confused middle state.

RECOMMENDATIONS

A - Upgrade curl to version 8.1.0

B - Apply the patch to your local version

C - Do not do mix using the read callback and CURLOPT_POSTFIELDS string on a reused easy handle

TIMELINE

This issue was reported to the curl project on April 19, 2023. We contacted distros@openwall on May 9, 2023.

libcurl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory.

CREDITS

Thanks a lot!