Curl Vulns Ironed Out With Patches After Week-Long Tease

Updated After a week of rampant speculation about the nature of the security issues in curl, the latest version of the command line transfer tool was finally released today.

Described by curl project founder and lead developer Daniel Stenberg as “probably the worst curl security flaw in a long time,” the patches address two separate vulnerabilities: CVE-2023-38545 and CVE-2023-38546.

We now know the first vulnerability, CVE-2023-38545, is a heap-based buffer overflow flaw that affects both libcurl and the curl tool, carrying a severity rating of “high.” Possible outcomes of such issues include the corruption of data and, in the worst cases, the execution of arbitrary code.

Specifically, the buffer overflow can occur during a slow SOCKS5 proxy handshake. The vulnerability was triggered due to mishandling of hostnames longer than 255 bytes. 

When a hostname exceeds 255 bytes, curl switches to local resolution rather than letting the proxy resolve the hostname remotely.

“Due to a bug, the local variable that means ‘let the host resolve the name’ could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too-long hostname to the target buffer instead of copying just the resolved address there,” the advisory reads.

curl said the vulnerability could most likely be exploited without the need for a denial of service attack or for the baddies to get SOCKS server control since a server’s typical latency is slow enough.

An attacker could feasibly exploit this vulnerability using a malicious HTTPS server redirecting to a URL that was created specifically to trigger the heap buffer overflow, it said.

Applications that depend on libcurl 7.69.0 up to and including 8.3.0 – the previous most recent version – are advised to upgrade to 8.4.0 as soon as possible. Those with applications that haven’t set the preferred receive buffer size (CURLOPT_BUFFERSIZE), or those that have set it to smaller than 65541 bytes, are especially vulnerable.

The curl tool’s default configuration protects against the vulnerability by default, but applications that depend on libcurl may need to make changes.

Now fixed in version 8.4.0, the patch ensures an error is returned when hostnames longer than 255 bytes are encountered.

curl also advised against using CURLPROXY_SOCKS5_HOSTNAME proxies and setting a proxy environment variable to the socks5h:// scheme.

“Reading the code now it is impossible not to see the bug,” said Stenberg in a blog. “Yes, it truly aches having to accept the fact that I did this mistake without noticing and that the flaw then remained undiscovered in code for 1,315 days. I apologize. I am but a human.

“It could have been detected with a better set of tests. We repeatedly run several static code analyzers on the code and none of them have spotted any problems in this function.

“In hindsight, shipping a heap overflow in code installed in over 20 billion instances is not an experience I would recommend.”

Vulnerability number two

The second vulnerability, CVE-2023-38546, is a less-severe cookie injection flaw and affects only libcurl.

The curl project’s advisory says the likelihood that an attacker could meet the series of conditions required to trigger the vulnerability is low, and adds that even if they did, the risk of a cookie injection attack to the safety of a user is also low.

To facilitate transfers, libcurl has a function called curl_easy_duphandle that is responsible for duplicating “easy handles” – individual handles for single transfers.

“If a transfer has cookies enabled when the handle is duplicated, the cookie-enable state is also cloned – but without cloning the actual cookies,” the advisory reads. 

“If the source handle did not read any cookies from a specific file on disk, the cloned version of the handle would instead store the file name as ‘none’ (using the four ASCII letters, no quotes).”

If that cloned handle was used again, then it would load cookies from a file named “none,” providing it was in the correct file format and if it existed in the directory of the program using libcurl.

The affected versions are libcurl 7.9.1 up to and including 8.3.0. Users are advised to upgrade to curl 8.4.0 and call curl_easy_setopt(cloned_curl, CURLOPT_COOKIELIST, "ALL"); after every call to curl_easy_duphandle();.

Uncoordinated disclosure

The patches were originally slated for a release today at 0600 UTC, but one project maintainer released the patch details for CVE-2023-38545 hours earlier than the scheduled go-live time.

The early leak came from Red Hat’s CentOS Stream project on GitLab and its commit time confirmed it was made at 1725 UTC on October 10 rather than the actual scheduled release date and time.

Security researchers quickly attempted to understand how the vulnerabilities could be exploited using the information highlighted in the diff.

John Hammond documented his attempts in an X (formerly Twitter) thread but his tries, which found some small errors, ultimately didn’t uncover a damaging exploit.

Katie Moussouris, CEO at Luta Security, said coordinated vulnerability disclosures can be “tricky business, especially when timezones are involved”.

Memory safety

The idea that applications written in programming languages with fewer memory safety guardrails should be re-written in newer languages like Rust and Go has been long-running in the industry.

Stronger calls to make the change have come out of the US recently, with the National Security Agency (NSA) publishing its recommendation last year.

It raised concern over the number of memory safety-related vulnerabilities that were being exploited, citing Microsoft and Google’s admission that around 70 percent of vulnerabilities are rooted in memory safety issues.

Stenberg admitted that the flaws found in curl would not have existed had it been written in a more memory-safe language instead of C, but confirmed there were no plans to make such a switch.

curl’s approach will remain one that “allows, uses, and supports memory-safe languages,” Stenberg said, and the ambition to replace curl’s HTTP backend with the Rust-coded Hyper is still being considered.

“Such development is however currently happening in a near-glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.

“Everyone not happy about this are of course welcome to roll up their sleeves and get working,” he added. ®

Updated to add: Severity overblown?

When Stenberg announced the existence of the vulnerability in curl last week on October 4, saying it was curl’s “worst security flaw in a long time,” and offering few details more than that, the cybersecurity industry jumped to various conclusions like drawing comparisons between it and log4j.

In the hours since the patches were released today, many in the security community have voiced their opinion that the severity of the vulnerability was initially ‘overblown’.

“Well this is underwhelming if it’s in SOCKS,” said Justin Elze of TrustedSec on X. “The primary reason I’m salty about curl is all the conversations and hype around it,” he added in a follow-up post. “Companies already have a hard time prioritizing patches and determining exposure for various vulnerabilities. Fire drills like this eat up cycles when they could be focusing on things like KEV, their shiny new cloud, or AD.”

It’s actually impressive this nothing burger is the worst they’ve had in foreverWhat I wouldn’t give for this to qualify as “a big issue” for most other software out there…

— Nathan McNulty (@NathanMcNulty) October 11, 2023

Responding to a comment questioning the likelihood of a possible exploit, Stenberg said a more realistic attack scenario would involve a user of the TOR browser, one that often uses the SOCKS5 protocol, connecting to a compromised HTTPS site.

Muhammad Yahya Patel, lead security engineer at Check Point, told The Register that all vulnerabilities in widely used open source tools like curl “carry a huge amount of risk.”

“Now that details have been published, it’s all hands on deck to assess the impact and potential implications. It also highlights the importance of organizations understanding their SBOMs and having a full inventory of what components exist and where.”

Others in the field have highlighted that SOCKS5 isn’t often used, especially in a business environment, which would limit the effectiveness of any exploit that was to be developed. “Perhaps the one shield of defense we have is that the communication must go through a SOCKS5 proxy, which, in my opinion, is not a very common deployment,” said Pieter Danhieux, co-founder and CEO at Secure Code Warrior.

“However, security researchers – good and bad – tend to be highly creative, and with today’s disclosure of vulnerability information, will be pulling out all stops to find every avenue to mass-exploit these weaknesses through other means.”

READ MORE HERE