#18058 closed enhancement (fixed)
curl-8.1.0
Reported by: | Douglas R. Reno | Owned by: | Tim Tassonis |
---|---|---|---|
Priority: | elevated | Milestone: | 12.0 |
Component: | BOOK | Version: | git |
Severity: | normal | Keywords: | |
Cc: |
Description ¶
New minor version
Contains four security fixes
Change History (5)
comment:2 by , 23 months ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed in commit 9c032d6f99
comment:3 by , 22 months ago
Security Vulnerability Information:
CVE-2023-28322
CVE-2023-28322 more POST-after-PUT confusion 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 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@openwall on May 9, 2023. libcurl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory.
CVE-2023-28321
CVE-2023-28321 IDN wildcard match VULNERABILITY curl supports matching of wildcard patterns when listed as "Subject Alternative Name" in TLS server certificates. curl can be built to use its own name matching function for TLS rather than one provided by a TLS library. This private wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before used for certificate checks. Puny coded names always start with xn-- and should not be allowed to pattern match, but the wildcard check in curl could still check for x*, which would match even though the IDN name most likely contained nothing even resembling an x. INFO curl's wildcard matching function is used only when curl was built to use OpenSSL, Schannel or Gskit. All other backends use the matching functions of the corresponding TLS library and are thus not vulnerable to this flaw. This flaw is lessened somewhat by two factors: Certificates issued by Certificate Authorities for the public Internet are not allowed to use "partial" wildcards, thus completely avoiding this issue. In many circumstances, the control of host names used and the wildcards used in issued certificates are controlled by the same entity, making this unlikely to actually become a problem. curl does not need to be built with IDN support to be vulnerable, as a user can pass in a puny coded version of the host name directly in the URL and can then trigger this flaw. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28321 to this issue. CWE-295: Improper Certificate Validation Severity: Low AFFECTED VERSIONS This bug was introduced in curl when IDN support was first introduced, in curl 7.12.0 - June 2004. The wildcard function was subsequently updated for this case in 2012 (the IDN problem is mentioned in RFC 6125 in a far from obvious way) but was done wrongly, so the flaw remained. Affected versions: curl 7.12.0 to and including 8.0.1 Not affected versions: curl < 7.12.0 and curl >= 8.1.0 Introduced-in: https://github.com/curl/curl/commit/9631fa740708b1890197fad libcurl is used by many applications, but not always advertised as such! SOLUTION curl 8.1.0 completely removes the support for "partial" patches and now only supports *.. No a*, a*b or *b matches. For all host names, IDN or not. Fixed-in: https://github.com/curl/curl/commit/199f2d440d8659b42 RECOMMENDATIONS A - Upgrade curl to version 8.1.0 B - Apply the patch to your local version TIMELINE This issue was reported to the curl project on April 17 2023. We contacted distros@openwall on May 9, 2023. curl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory.
CVE-2023-28320
CVE-2023-28320 siglongjmp race condition VULNERABILITY libcurl provides several different backends for resolving host names, selected at build time. If it is built to use the synchronous resolver, it allows name resolves to time- out slow operations using alarm() and siglongjmp(). When doing this, libcurl used a global buffer that was not mutex protected and a multi- threaded application might therefore crash or otherwise misbehave. INFO Most platforms and systems build libcurl to use the threaded resolver or with c-ares, neither of those suffer from this flaw. Most platforms that build with the synchronous resolver don't feature alarm() and siglongjmp() and therefor are not vulnerable either. Since alarm() uses signals, it is not advisable to use in a multi-threaded environment (signals and threads rarely mix very well) which reduces the risk that this flaw hurts many users. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28320 to this issue. CWE-662: Improper Synchronization Severity: Low AFFECTED VERSIONS Affected versions: curl 7.9.8 to and including 8.0.1 Not affected versions: curl < 7.9.8 and curl >= 8.1.0 Introduced-in: https://github.com/curl/curl/commit/3c49b405de4fbf1f libcurl is used by many applications, but not always advertised as such! SOLUTION The fix is to only support this timeout ability if curl has and can properly mutex protect the buffer. Fixed-in: https://github.com/curl/curl/commit/13718030ad4b3209a7583b RECOMMENDATIONS A - Upgrade curl to version 8.1.0 B - Apply the patch to your local version C - Do not use the synchronous name resolver option TIMELINE This issue was reported to the curl project on April 2 2023. We contacted distros@openwall on May 9, 2023. curl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory.
CVE-2023-28319
CVE-2023-28319 UAF in SSH sha256 fingerprint check VULNERABILITY libcurl offers a feature to verify an SSH server's public key using a SHA 256 hash. When this check fails, libcurl would free the memory for the fingerprint before it returns an error message containing the (now freed) hash. This flaw risks inserting sensitive heap-based data into the error message that might be shown to users or otherwise get leaked and revealed. INFO This only applies to users of the CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 option, which is only supported for libcurl built with libssh2 (curl optionally supports other SSH backends). Either of the options CURLOPT_VERBOSE or CURLOPT_ERRORBUFFER also need to be set to trigger the problem. The damage is somewhat limited by the extremely short time window between the free and the use of the freed memory. The largest possible info leak that can happen due to this flaw per trigger occasion, is limited to CURL_ERROR_SIZE - the error message prefix length (69) = 186 bytes. It will also stop at the first null byte within those 186 bytes. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28319 to this issue. CWE-416: Use After Free Severity: Medium AFFECTED VERSIONS Affected versions: curl 7.81.0 to and including 8.0.1 Not affected versions: curl < 7.81.0 and curl >= 8.1.0 Introduced-in: https://github.com/curl/curl/commit/3467e89bb97e6c87c7 libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/8e21b1a05f3c0ee098dbcb6c RECOMMENDATIONS A - Upgrade curl to version 8.1.0 B - Apply the patch to your local version C - Do not use CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 TIMELINE This issue was reported to the curl project on March 21 2023. We contacted distros@openwall on May 9, 2023. curl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory.
Note:
See TracTickets
for help on using tickets.