How to respond to the curl and libcurl vulnerabilities

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:
  • The CURLOPT_PROXYTYPE option is set to type CURLPROXY_SOCKS5_HOSTNAME
  • 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