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. ®