CVE-2023-38545: “The worst curl security flaw in a long time”

On October 5, 2023, curl maintainer Daniel Stenberg issued an early alert about two security flaws in curl, a popular tool for transferring data over a network. One of the flaws is rated HIGH severity, and Stenberg describes it as “probably the worst curl security flaw in a long time.“

curl and libcurl are used for transferring data over a network. curl is a command-line tool, while libcurl is a library that can be used to integrate network transfer capabilities into other applications. curl and libcurl support a wide range of protocols, including HTTP, HTTPS, FTP, FTPS, SFTP, SCP, TFTP, and more.

curl is a very popular tool, and it is used by many different people and organizations. It is included in most Linux distributions, and it can also be installed on macOS and Windows. libcurl is also a very popular library, and it is used by many different software applications, including web browsers, download managers, and file transfer clients.

The new version, curl 8.4.0, and details about the two CVEs will be published around 06:00 UTC on October 11, 2023. Yet, what’s intriguing is the potential widespread effect of the libcurl vulnerability. While every application using libcurl could be in the line of fire, the exact conditions for triggering the vulnerability remain enigmatic. Stenberg candidly admits the challenge in pinpointing specific vulnerable libcurl users at this juncture.

What is CVE-2023-38545?

CVE-2023-38545 is a severity-high vulnerability that affects both libcurl and the curl tool. This is a serious problem, but it is important to note that not all users will be affected.

What is CVE-2023-38546?

CVE-2023-38546 is a severity-low vulnerability that affects libcurl only, not the tool. This vulnerability is less serious than CVE-2023-38545, but it is still important to be aware of it.

What should I do?

1. Evaluate your container and package utilization beforehand to assess potential risks.
2. Locate hosts with curl installed and ascertain its installation method.
3. Determine the curl version you’re utilizing by running: curl –version.

Most operating systems come with curl pre-installed. Its location varies based on the OS and installation technique. To swiftly check if curl is installed and accessible, execute: curl –version.

If the command processes without any issues, it displays the first detected curl version in your path. Remember, curl might exist in multiple locations. For instance, modern Apple devices default to /usr/bin/curl but might also have a version from homebrew. To find out the location of the version you accessed, use: which curl. On macOS/Linux systems, consider checking the following paths:

• /bin/curl
• /usr/bin/curl
• /usr/local/bin/curl
• /opt/homebrew/opt/curl

Ensure you identify all instances that require updates for the forthcoming version.

The best way to protect yourself from these vulnerabilities is to upgrade to curl 8.4.0 as soon as it is released.

Update on October 11:

CVE-2023-38546

Delineated in disclosure by the esteemed curl developer Daniel Stenberg, CVE-2023-38546 introduces a sneaky method for attackers. It allows them to arbitrarily insert cookies into a running program utilizing libcurl. But for the trap to snap shut, a specific sequence of conditions must be met: chiefly, the cookies need to be placed in a uniquely titled file, “none”, within the application’s directory.

CVE-2023-38545

The more technical and intricate of the two, CVE-2023-38545, makes curl falter by overflowing a heap-based buffer during a SOCKS5 proxy handshake. The essence of the flaw centers on the tool’s handling of hostnames. If a hostname, originating from the URL curl interacts with, exceeds 255 bytes, a series of incorrect operations could culminate in the overflow of the buffer into the heap.

To further illustrate the intricacies: for this vulnerability to be exploited, it requires the interplay of a sluggish SOCKS5 handshake, coupled with a hostname that dwarfs the download buffer’s size. While this might sound like a far-fetched scenario, real-world server latencies often meet the “slow” criteria, making this bug an impending threat.

Importantly, the flaw manifests under specific conditions. Applications that either don’t adjust CURLOPT_BUFFERSIZE or adjust it to a size smaller than 65541 are susceptible. As for the curl tool itself, by default, it isn’t vulnerable unless users impose rate limits below 65541 bytes/second.

To shed more light, the anomaly had its roots when the SOCKS5 handshake code transitioned from a blocking function to a non-blocking state mechanism.

Affected Versions

If you’re running libcurl versions between 7.69.0 to 8.3.0, it’s time to pay heed. These are the versions affected. Fortunately, the earlier versions, as well as the latest 8.4.0 and beyond, are immune to this vulnerability.

Mitigation and Forward Path

To tackle the storm head-on, Daniel Stenberg and the curl team have drawn a clear roadmap:

1. Upgrade to Safer Shores: Jump to curl version 8.4.0. This latest version rectifies the error handling by not switching to local resolve mode for elongated names.
2. Patch it Up: If upgrading immediately isn’t feasible, patches for older versions have been released.
3. Tread Cautiously with Proxies: Steer clear from using CURLPROXY_SOCKS5_HOSTNAME proxies.
4. Environment Variables: Refrain from setting a proxy environment variable to socks5h://.