Curl project squashes high-severity bug in omnipresent libcurl library (CVE-2023-38545)
Curl v8.4.0 is out, and fixes – among other things – a high-severity SOCKS5 heap buffer overflow vulnerability (CVE-2023-38545).
Appropriate patches for some older curl versions have been released, too.
Preparation for the security updates
A little over a week ago, lead developer Daniel Stenberg announced the upcoming release of the newest curl version and said that it would carry patches for CVE-2023-38545 and CVE-2023-38546, a low-severity bug that has been described today as a cookie injection flaw.
Since curl (i.e., the libcurl library) is used by a wide variety of operating systems, applications and IoT devices, the pre-announcement makes sense, as it allows organizations to audit their own systems, find all instances of curl and libcurl in use, and make a plan for enterprise-wide patching.
The curl project has also simultaneously shared the info about the flaws with developers of a variety of Linux, Unix and Unix-like distributions, so they can prepare patches/updated packages in advance of the curl v8.4.0 release.
About CVE-2023-38545 and CVE-2023-38546
CVE-2023-38545, reported by Jay Satiro, affects the curl command-line tool and the libcurl (client-side URL transfer) library. It makes curl overflow a heap based buffer in the SOCKS5 proxy handshake.
“When curl is asked to pass along the hostname to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that hostname can be is 255 bytes. If the hostname is detected to be longer than 255 bytes, curl switches to local name resolving and instead passes on the resolved address only to the proxy,” the associated advisory explains.
“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 bug was inadvertently introduced in libcurl 7.69.0 by Stenberg himself, as he noted in a blog post published today. (More technical details about the bug can also be found in the HackerOne report.)
To pull trigger the heap buffer overflow, an attacker:
- Must control an HTTPS server that a client using libcurl accesses over a SOCKS5 proxy (using the proxy-resolver-mode)
- Make the server return a crafted redirect (containing a Location: header where the host name is longer than 16kB and up to 64kB) to the application via a HTTP 30x response
“If the libcurl using client has automatic redirect-following enabled, and the SOCKS5 proxy is ‘slow enough’ to trigger the local variable bug, it will copy the crafted host name into the too small allocated buffer and into the adjacent heap memory,” Stenberg explained.
In a discussion on Mastodon, he also laid out a realistic scenario for exploitation involving Tor users visiting an HTTPS site that has been compromised.
CVE-2023-38545 affects curl and libcurl from version 7.69.0 to (and including) v8.3.0.
CVE-2023-38546, on the other hand, only affects libcurl from version 7.9.1 to (and including) v8.3.0, but the likelihood of its exploitation is low. “Even if the bug could be made to trigger, the risk that a cookie injection can be done to cause harm is additionally also low,” the maintainers said.
What now?
The curl project advises users to update curl/libcurl to version 8.4.0 or to patch older versions, and has shared additional/alternative mitigations in the advisories.
Libcurl/curl is used by default in many Linux distros and is included in many container images, so be on the lookout for releases by various providers (Debian, Ubuntu, Red Hat, etc.).
Go here for additional advice on how to deal with the patching and how to avoid possible pitfalls.