Why the Curl Buffer Overflow Is Not the Next Log4Shell

What you have to know

 

• On October 11, 2023, a high-severity buffer overflow vulnerability within the widely-used curl instrument and library was disclosed, and a repair was included within the 8.4.0 launch.
• CVE-2023-38545 impacts all variations of curl since 7.69.0 however requires very particular circumstances to take advantage of. No sensible assault has been found thus far.
• All maintainers of software program that ships with the curl instrument or consists of the libcurl library are urged to patch or replace to model 8.4.0 or later. Avoiding the usage of SOCKS5 proxies with curl additionally eliminates publicity to the vulnerability.
• With billions of curl installations worldwide, susceptible variations will seemingly stay on-line for years, posing a long-term danger if the vulnerability is ever weaponized.

When Daniel Stenberg, the maintainer of the ever-present curl instrument and library, introduced {that a} high-severity vulnerability was discovered and refused to offer additional particulars till a patch was prepared, the safety world held its breath. In a single kind or one other, the open-source curl is utilized in billions of software program installations, and a remotely exploitable flaw in it might dwarf the Log4j disaster when it comes to affect. Was this one other Heartbleed? Would it not break the Web?

Fortunately, it wasn’t – and it didn’t. When lastly disclosed, the flaw turned out to be a buffer overflow vulnerability that solely affected a restricted subset of curl performance and solely in very particular circumstances. As of this writing, no sensible methods to take advantage of it have been found or seen within the wild. The vulnerability was addressed in curl 8.4.0, and all curl installations must be patched or up to date to not less than this model.

So what’s all of the fuss about, you may ask? It’s simply one other buffer overflow vulnerability that was reported and stuck, so let’s complain about individuals nonetheless not utilizing memory-safe languages in 2023, patch this, and transfer on, proper? Effectively… Not fairly. Whereas, fortunately, we gained’t be coping with one other Log4Shell (together with the inevitable Curl4Shell moniker), this could possibly be one thing of a slow-burner that will resurface for years to return. The vulnerability additionally combines a number of widespread safety complications and was (considerably unusually) described in nice element by the developer who launched and stuck it, so it’s nicely value a deeper evaluation.

What’s curl, and the place is it used?

Curl (typically written cURL) is the basic command-line instrument and library for programmatically calling URLs and retrieving responses. In essence, if in case you have a script or C/C++ program that should get information from an internet web page or API, there’s a very good probability that curl is concerned ultimately.

Most working techniques ship with the instrument, and the associated libcurl library is named by or included with virtually any C/C++ program that communicates over HTTP. Crucially, this consists of embedded techniques in web-connected units – which is why Daniel Stenberg estimates that some 20 billion curl installations might exist. In comparison with curl, these “Log4j is in all places” headlines positively appear overblown.

The heap buffer overflow vulnerability in curl

Daniel Stenberg has described the historical past and technical particulars of the vulnerability at size on his weblog, however right here’s the simplified one-minute model:

• Curl has many working modes, together with one for speaking through SOCKS5 proxies. The SOCKS5 protocol can be utilized for visitors tunneling from an inner community (much like a VPN) and for circumventing visitors filters. The vulnerability solely impacts curl if utilized in SOCKS5 mode.
• When remodeling older code to enhance efficiency for SOCKS5 connections, a mistake was made when processing excessively lengthy hostnames (over 255 bytes). As an alternative of rejecting such a hostname, which might be the anticipated conduct (DNS solely permits 255 bytes, so something greater almost definitely isn’t reliable), curl switches from distant to native decision mode and makes an attempt to resolve the hostname once more.
• If the SOCKS5 connection isn’t quick sufficient, curl waits for extra information and resumes work. As a result of bug, when curl resumes, it doesn’t keep in mind that it’s speculated to be working in native mode and tries distant hostname decision once more – however this time, it passes on the whole overlong hostname.
• The code writes the hostname to be resolved to the hostname buffer with out checking its dimension. If the goal buffer dimension is between 16kB and 64kB and a particularly lengthy hostname is provided, a buffer overflow can happen that overwrites adjoining reminiscence. Observe that command-line curl defaults to 100kB and is simply susceptible if this default dimension is modified, however applications utilizing the libcurl library default to 16kB, which makes them susceptible.
• An assault can solely succeed if the working system doesn’t defend in opposition to reminiscence corruption. The attacker additionally has an extra limitation as a result of restricted set of characters (extra exactly octets) permitted in a hostname.

Should you’re studying this and pondering there are far too many “ifs” alongside the way in which, you’re proper, and this abstract doesn’t even cowl all of the “ifs” required to set off the vulnerability. Once more, pondering again to Log4Shell the place a single line of textual content despatched to a server someplace on the internet might get you code execution, the curl vulnerability appears nearly impossibly arduous to take advantage of by comparability. There may be additionally no identified payload that will do one thing extra helpful than crashing the instrument – however in the end, someone may discover one, so it was necessary to quietly repair this earlier than attackers knew what they have been on the lookout for.

Vulnerability disclosure, mitigation, and default safety panic

Regardless of the low sensible danger and no demonstrated strategy to usefully exploit the vulnerability, Daniel Stenberg took the report extraordinarily significantly and was cautious to not reveal any particulars of the bug (not even the variations affected) till a patch was obtainable. Earlier than it was printed, the repair was offered to working system maintainers so they might replace curl of their respective techniques. This extra delay prolonged the interval of untamed hypothesis concerning the doubtlessly devastating affect of the vulnerability.

The patch and full particulars of the vulnerability have been printed on October 11, 2023, to a collective sigh of aid that the difficulty was removed from the Web-breaking horror everybody had feared. The replace fixes the underlying hostname decision bug, and from model 8.4.0 onwards, curl will reject excessively lengthy hostnames and return an error. This eliminates the ensuing overflow vulnerability and makes it secure to make use of curl in SOCKS5 mode. 

Besides that’s solely the start as a result of, as with all patches to widely-used software program, updating the whole lot is simpler mentioned than finished. Not all curl customers can patch instantly, and lots of won’t even know their system or utility makes use of curl. The instrument and library are shipped with or constructed into most working techniques, together with embedded techniques (e.g. IoT units and community home equipment), in addition to software program operating in digital machines and containers. So the advisable mitigations are, so as of desire (from the official advisory):

1. Improve curl to model 8.4.0
2. Apply the patch to your native model
3. Don’t use CURLPROXY_SOCKS5_HOSTNAME proxies with curl
4. Don’t set a proxy atmosphere variable to socks5h://

One other hyperlink within the fragile software program provide chain

As with each high-profile memory-management vulnerability, preliminary responses instantly included requires all C/C++ software program to be burned on the stake and rewritten on this yr’s trendy memory-safe language so we are able to lastly cease seeing buffer overflows on the prime of the CWE prime 25. As traditional, this is able to be nice in idea however is totally unfeasible in observe, particularly for a instrument similar to curl that has been extensively used and embedded for over twenty years. 

The entire scare could possibly be written off as an abundance of warning on the a part of the maintainer. Many different software program maintainers, each for open-source and business tasks, would seemingly have approached the identical subject as a routine low-priority bug repair and buried it someplace within the launch notes for the subsequent scheduled model. However Daniel Stenberg cares deeply about safety and feels the burden of duty as one of many individuals thanklessly sustaining the foundations of all fashionable digital infrastructure. As he writes in his weblog put up: “In hindsight, transport a heap overflow in code put in in over twenty billion cases will not be an expertise I might suggest.”

Even with the patch launched, thousands and thousands of susceptible curl installations will seemingly persist for years to return. If an efficient assault is ever found and weaponized, issues might get actually ugly. Contemplating the fragility of the worldwide software program provide chain, being obsessive about safety isn’t any dangerous factor.