An abundance of caution: Why the curl buffer overflow is not the next Log4Shell

What you need to know

 

• On October 11, 2023, a high-severity buffer overflow vulnerability in the widely-used curl tool and library was disclosed, and a fix was included in the 8.4.0 release.
• CVE-2023-38545 affects all versions of curl since 7.69.0 but requires very specific conditions to exploit. No practical attack has been discovered so far.
• All maintainers of software that ships with the curl tool or includes the libcurl library are urged to patch or update to version 8.4.0 or later. Avoiding the use of SOCKS5 proxies with curl also eliminates exposure to the vulnerability.
• With billions of curl installations worldwide, vulnerable versions will likely remain online for years, posing a long-term risk if the vulnerability is ever weaponized.

When Daniel Stenberg, the maintainer of the ubiquitous curl tool and library, announced that a high-severity vulnerability was found and refused to provide further details until a patch was ready, the security world held its breath. In one form or another, the open-source curl is used in billions of software installations, and a remotely exploitable flaw in it could dwarf the Log4j crisis in terms of impact. Was this another Heartbleed? Would it break the Internet?

Luckily, it wasn’t – and it didn’t. When finally disclosed, the flaw turned out to be a buffer overflow vulnerability that only affected a limited subset of curl functionality and only in very specific circumstances. As of this writing, no practical ways to exploit it have been discovered or seen in the wild. The vulnerability was addressed in curl 8.4.0, and all curl installations should be patched or updated to at least this version.

So what’s all the fuss about, you might ask? It’s just another buffer overflow vulnerability that was reported and fixed, so let’s complain about people still not using memory-safe languages in 2023, patch this, and move on, right? Well… Not quite. While, thankfully, we won’t be dealing with another Log4Shell (along with the inevitable Curl4Shell moniker), this could be something of a slow-burner that may resurface for years to come. The vulnerability also combines several common security headaches and was (somewhat unusually) described in great detail by the developer who introduced and fixed it, so it’s well worth a deeper analysis.

What is curl, and where is it used?

Curl (sometimes written cURL) is the fundamental command-line tool and library for programmatically calling URLs and retrieving responses. In essence, if you have a script or C/C++ program that needs to get data from a web page or API, there’s a good chance that curl is involved in some way.

Most operating systems ship with the tool, and the related libcurl library is called by or included with practically any C/C++ program that communicates over HTTP. Crucially, this includes embedded systems in web-connected devices – which is why Daniel Stenberg estimates that some 20 billion curl installations may exist. Compared to curl, those “Log4j is everywhere” headlines definitely seem overblown.

The heap buffer overflow vulnerability in curl

Daniel Stenberg has described the history and technical details of the vulnerability at length on his blog, but here’s the simplified one-minute version:

• Curl has many operating modes, including one for communicating via SOCKS5 proxies. The SOCKS5 protocol can be used for traffic tunneling from an internal network (similar to a VPN) and for circumventing traffic filters. The vulnerability only affects curl if used in SOCKS5 mode.
• When reworking older code to improve performance for SOCKS5 connections, a mistake was made when processing excessively long hostnames (over 255 bytes). Instead of rejecting such a hostname, which would be the expected behavior (DNS only allows 255 bytes, so anything bigger most likely isn’t legitimate), curl switches from remote to local resolution mode and attempts to resolve the hostname again.
• If the SOCKS5 connection isn’t fast enough, curl waits for more data and resumes work. Due to the bug, when curl resumes, it doesn’t remember that it’s supposed to be working in local mode and tries remote hostname resolution again – but this time, it passes on the entire overlong hostname.
• The code writes the hostname to be resolved to the hostname buffer without checking its size. If the target buffer size is between 16kB and 64kB and an extremely long hostname is supplied, a buffer overflow can occur that overwrites adjacent memory. Note that command-line curl defaults to 100kB and is only vulnerable if this default size is changed, but programs using the libcurl library default to 16kB, which makes them vulnerable.
• An attack can only succeed if the operating system doesn’t protect against memory corruption. The attacker also has an additional limitation due to the limited set of characters (more precisely octets) permitted in a hostname.

If you’re reading this and thinking there are far too many “ifs” along the way, you’re right, and this summary doesn’t even cover all the “ifs” required to trigger the vulnerability. Again, thinking back to Log4Shell where a single line of text sent to a server somewhere on the web could get you code execution, the curl vulnerability seems almost impossibly hard to exploit by comparison. There is also no known payload that would do something more useful than crashing the tool – but sooner or later, somebody might find one, so it was important to quietly fix this before attackers knew what they were looking for.

Vulnerability disclosure, mitigation, and default security panic

Despite the low practical risk and no demonstrated way to usefully exploit the vulnerability, Daniel Stenberg took the report extremely seriously and was careful not to reveal any details of the bug (not even the versions affected) until a patch was available. Before it was published, the fix was provided to operating system maintainers so they could update curl in their respective systems. This additional delay extended the period of wild speculation about the potentially devastating impact of the vulnerability.

The patch and full details of the vulnerability were published on October 11, 2023, to a collective sigh of relief that the issue was far from the Internet-breaking horror everyone had feared. The update fixes the underlying hostname resolution bug, and from version 8.4.0 onwards, curl will reject excessively long hostnames and return an error. This eliminates the resulting overflow vulnerability and makes it safe to use curl in SOCKS5 mode. 

Except that’s only the beginning because, as with all patches to widely-used software, updating everything is easier said than done. Not all curl users can patch immediately, and many might not even know their system or application uses curl. The tool and library are shipped with or built into most operating systems, including embedded systems (e.g. IoT devices and network appliances), as well as software running in virtual machines and containers. So the recommended mitigations are, in order of preference (from the official advisory):

1. Upgrade curl to version 8.4.0
2. Apply the patch to your local version
3. Do not use CURLPROXY_SOCKS5_HOSTNAME proxies with curl
4. Do not set a proxy environment variable to socks5h://

Another link in the fragile software supply chain

As with every high-profile memory-management vulnerability, initial responses immediately included calls for all C/C++ software to be burned at the stake and rewritten in this year’s fashionable memory-safe language so we can finally stop seeing buffer overflows at the top of the CWE top 25. As usual, this would be great in theory but is completely unfeasible in practice, especially for a tool such as curl that has been widely used and embedded for over two decades. 

The whole scare could be written off as an abundance of caution on the part of the maintainer. Many other software maintainers, both for open-source and commercial projects, would likely have approached the same issue as a routine low-priority bug fix and buried it somewhere in the release notes for the next scheduled version. But Daniel Stenberg cares deeply about security and feels the burden of responsibility as one of the people thanklessly maintaining the foundations of all modern digital infrastructure. As he writes in his blog post: “In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend.”

Even with the patch released, millions of vulnerable curl installations will likely persist for years to come. If an effective attack is ever discovered and weaponized, things could get really ugly. Considering the fragility of the global software supply chain, being obsessive about security is no bad thing.