[<prev] [next>] [day] [month] [year] [list]
Message-ID: <s335p31-738-9881-832n-r6945p656r3@unkk.fr>
Date: Wed, 17 May 2023 08:41:12 +0200 (CEST)
From: Daniel Stenberg <daniel@...x.se>
To: curl security announcements -- curl users <curl-users@...ts.haxx.se>,
curl-announce@...ts.haxx.se, libcurl hacking <curl-library@...ts.haxx.se>,
oss-security@...ts.openwall.com
Subject: curl: CVE-2023-28322: more POST-after-PUT confusion
more POST-after-PUT confusion
=============================
Project curl Security Advisory, May 17 2023 -
[Permalink](https://curl.se/docs/CVE-2023-28322.html)
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](https://curl.se/docs/CVE-2022-32221.html). 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
-----------------
- Affected versions: libcurl 7.7 to and including 8.0.1
- Not affected versions: libcurl < 7.7 and >= 8.1.0
- Introduced-in: https://github.com/curl/curl/commit/546572da0457f3
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.
- Fixed-in: https://github.com/curl/curl/commit/7815647d6582c0a4900be2e1de
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@...nwall on May 9, 2023.
libcurl 8.1.0 was released on May 17 2023, coordinated with the publication of
this advisory.
CREDITS
-------
- Reported-by: Hiroki Kurosawa
- Patched-by: Daniel Stenberg
Thanks a lot!
--
/ daniel.haxx.se
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
