===================================================================== CERT-Renater Note d'Information No. 2023/VULN390 _____________________________________________________________________ DATE : 11/10/2023 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running libcurl versions prior to 8.4.0. ===================================================================== https://curl.se/docs/CVE-2023-38545.html https://curl.se/docs/CVE-2023-38546.html _____________________________________________________________________ CVE-2023-38545 SOCKS5 heap buffer overflow Project curl Security Advisory, October 11 2023 - Permalink VULNERABILITY This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the hostname to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that hostname can be is 255 bytes. If the hostname is detected to be longer than 255 bytes, curl switches to local name resolving and instead passes on the resolved address only to the proxy. Due to a bug, the local variable that means "let the host resolve the name" could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long hostname to the target buffer instead of copying just the resolved address there. TERMINOLOGY The curl library is known as libcurl and the command line tool that uses the library is known as the curl tool. Either or both may be referred to as just curl. The distinctive names are used in this document when necessary. INFO The hostname comes from the URL that curl has been told to operate with. The target buffer is the heap-based download buffer in libcurl that is reused for SOCKS negotiation before the transfer has started. The size of the buffer is 16kB by default, but can be set to different sizes by the application. The curl tool sets it to 102400 bytes by default - but it sets the buffer size to a smaller size if --limit-rate is set lower than 102400 bytes per second. libcurl provides the CURLOPT_BUFFERSIZE option to change the size of the download buffer. libcurl accepts hostnames up to 65535 bytes in the URL. If the used hostname is longer than the target buffer, there is a memcpy() that overwrites the buffer into the heap. The URL parser and possibly an IDN library (if curl is built with one) have to accept the hostname, which somewhat limits the set of available byte sequences that can be used in the copy. For an overflow to happen it needs a slow enough SOCKS5 handshake to trigger the local variable bug, and the client using a hostname longer than the download buffer. Perhaps with a malicious HTTPS server doing a redirect to an especially crafted URL. Typical server latency is likely "slow" enough to trigger this bug without an attacker needing to influence it by DoS or SOCKS server control. An overflow is only possible in applications that do not set CURLOPT_BUFFERSIZE or set it smaller than 65541. Since the curl tool sets CURLOPT_BUFFERSIZE to 100kB by default it is not vulnerable unless rate limiting was set by the user to a rate smaller than 65541 bytes/second. The options that cause SOCKS5 with remote hostname to be used in libcurl: CURLOPT_PROXYTYPE set to type CURLPROXY_SOCKS5_HOSTNAME, or: CURLOPT_PROXY or CURLOPT_PRE_PROXY set to use the scheme socks5h:// One of the proxy environment variables can be set to use the socks5h:// scheme. For example http_proxy, HTTPS_PROXY or ALL_PROXY. The options that cause SOCKS5 with remote hostname to be used in the curl tool: --socks5-hostname, or: --proxy or --preproxy set to use the scheme socks5h:// Environment variables as described in the libcurl section. This bug was introduced when the SOCKS5 handshake code was converted from a blocking function into a non-blocking state machine. The analysis in this section is specific to curl version 8. Some older versions of curl version 7 have less restriction on hostname length and/or a smaller SOCKS negotiation buffer size that cannot be overridden by CURLOPT_BUFFERSIZE. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-38545 to this issue. CWE-122: Heap-based Buffer Overflow Severity: High HackerOne: https://hackerone.com/reports/2187833 AFFECTED VERSIONS Affected versions: libcurl 7.69.0 to and including 8.3.0 Not affected versions: libcurl < 7.69.0 and >= 8.4.0 Introduced-in: https://github.com/curl/curl/commit/4a4b63daaa libcurl is used by many applications, but not always advertised as such! SOLUTION Starting in curl 8.4.0, curl no longer switches to local resolve mode if the name is too long but is instead rightfully returning an error. Fixed-in: https://github.com/curl/curl/commit/fb4415d8aee6c1 Patch collection for older versions RECOMMENDATIONS A - Upgrade curl to version 8.4.0 B - Apply the patch to your local version C - Do not use CURLPROXY_SOCKS5_HOSTNAME proxies with curl D - Do not set a proxy environment variable to socks5h:// TIMELINE This issue was reported to the curl project on September 30, 2023. We contacted distros@openwall on October 3, 2023. libcurl 8.4.0 was released on October 11 2023, coordinated with the publication of this advisory. CREDITS Reported-by: Jay Satiro Patched-by: Jay Satiro Thanks a lot! _____________________________________________________________________ cookie injection with none file Project curl Security Advisory, October 11 2023 - Permalink VULNERABILITY This flaw allows an attacker to insert cookies at will into a running program using libcurl, if the specific series of conditions are met. libcurl performs transfers. In its API, an application creates "easy handles" that are the individual handles for single transfers. libcurl provides a function call that duplicates an easy handle called curl_easy_duphandle. If a transfer has cookies enabled when the handle is duplicated, the cookie-enable state is also cloned - but without cloning the actual cookies. If the source handle did not read any cookies from a specific file on disk, the cloned version of the handle would instead store the file name as none (using the four ASCII letters, no quotes). Subsequent use of the cloned handle that does not explicitly set a source to load cookies from would then inadvertently load cookies from a file named none - if such a file exists and is readable in the current directory of the program using libcurl. And if using the correct file format of course. INFO The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-38546 to this issue. CWE-73: External Control of File Name or Path Severity: Low We set it to low because the flaw requires a series of conditions to be met and the likeliness that they shall allow an attacker to take advantage of it is low. Even if the bug could be made to trigger, the risk that a cookie injection can be done to cause harm is additionally also low. AFFECTED VERSIONS Affected versions: libcurl 7.9.1 to and including 8.3.0 Not affected versions: libcurl < 7.9.1 and >= 8.4.0 Introduced-in: https://github.com/curl/curl/commit/74d5a6fb3b9a96d9f libcurl is used by many applications, but not always advertised as such! The (flawed) logic that created this bug existed even before the curl_easy_duphandle() function was added, but it did not become this problem until this API was introduced. This flaw is not accessible using the curl command line tool. SOLUTION Starting in curl 8.4.0, curl not longer stores the file name in the cookie struct. Fixed-in: https://github.com/curl/curl/commit/61275672b46d9abb32857404 RECOMMENDATIONS A - Upgrade curl to version 8.4.0 B - Apply the patch to your local version C - Call curl_easy_setopt(cloned_curl, CURLOPT_COOKIELIST, "ALL"); right after every curl_easy_duphandle(); call. TIMELINE This issue was reported to the curl project on September 14, 2023. We contacted distros@openwall on October 3, 2023. libcurl 8.4.0 was released on October 11 2023, coordinated with the publication of this advisory. CREDITS Reported-by: w0x42 on hackerone Patched-by: Daniel Stenberg Thanks a lot! ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================