According to the security advisory, the vulnerability is caused by a heap overflow when using SOCKS5 proxy with remote hostnames over 255 bytes. The same which Cyber Kendra identified before the official release of the security advisory.
This is a Heap-based Buffer Overflow vulnerability, tracked as CVE-2023-38545, discovered by Jay Satiro, which impacts Curl versions 7.69.0 up to and including 8.3.0.Initially, the developer of Curl posted a warning note about this vulnerability but didn't disclose much information about the bug, due to its severity and scope.
It was introduced in commit 4a4b63daaa when the SOCKS5 handshake code was converted to a non-blocking state machine. The buffer overflow occurs because a bug in the handshake logic can copy hostnames longer than 255 bytes into a fixed-size heap buffer used for SOCKS negotiation.
To exploit this, an attacker would need to get the victim to connect through a malicious SOCKS5 proxy server that can slow down the proxy handshake. Then they could redirect the victim to a URL with an overly long hostname designed to trigger the overflow. Successful exploitation could lead to arbitrary remote code execution.
All users of the affected Curl library versions should update to 8.4.0 or later immediately. Alternatively, the Curl team has provided patches that can be applied to older versions. As a workaround, avoid using the socks5h proxy scheme which triggers the vulnerable code path.
At the time of writing the post, we have only seen one poc on GitHub.
The Curl command line tool is not impacted by default, but could be vulnerable if used with the --socks5-hostname flag or socks5h proxy URLs. The default buffer size used by the Curl tool is large enough to avoid overflow in most cases.
This serious remote code execution flaw underscores the importance of prompt security updates for critical internet infrastructure like Curl.
The Curl library is used in many applications and environments, often without being clearly advertised as such. Anyone using an impacted version should apply patches or upgrade as soon as possible to avoid potential compromise.
Marked as High instead of Critical
Curl author Daniel Stenberg has written a blog post regarding this issue and to know more technical details about the flaw, you can check the HackerOne report page. Regarding marking the issue as High-severity rather than Critical, Stenberg says -
My arguments for going with high instead of critical:
- it is not exploitable with the curl tool
- SOCKS5-hostname is only used by a fraction of libcurl users
- a successful attack on this almost requires that you can delay the proxy as well as providing a malicious redirct on the remote server. That "double presence" makes this hard to exploit.
- even if there is such a "double presence" to help exploiting this flaw, it is difficult use it for any surgical precision attack. Unless a special situation which makes the memory allocation patterns and sizes used by the application predictable enough for the attacker, selecting exactly what data to overflow and where - with precision - is extremely difficult. Especially since the exact contents of that data needs to be accepted by the libcurl URL parser as a host name.
The Second Bug CVE-2023-38546
From starting the Curl developer has warned about this high severity bug. There was another vulnerability CVE-2023-38546 that was fixed in Curl 8.4.0 which was categorised as Low Severity.
The second vulnerability was in libcurl versions 7.9.1 through 8.3.0 could allow an attacker to inject arbitrary cookies into an application using the affected library.
This is possible under very specific conditions - the application must duplicate an easy handle using curl_easy_duphandle() without explicitly loading a cookie file.
If cookies were enabled in the original handle but no cookie file was loaded, the cloned handle would try to load cookies from a file named 'none'.
An attacker could exploit this by placing a maliciously crafted cookie file on that path. Successful exploitation could result in compromised user sessions or other impacts, depending on the target application's cookie usage.
The Curl team rates this as low severity since it requires a series of unlikely conditions to be met. All users of affected libcurl versions should update to 8.4.0 which fixes the flaw. Alternatively, a patch is available. Mitigation can also be achieved by explicitly loading a cookie file after duphandle calls.