The developers of the curl open-source software application and library have released patches for two vulnerabilities in the widely used command-line tool. One of the flaws is rated with high severity and could potentially be exploited by rogue servers to execute malicious code on systems that access them with curl under certain conditions.
Curl, which is short for “client for URL,” is a cross-platform and portable command-line tool designed to transfer data or files to and from URLs. Dating back 27 years, it supports many internet communication protocols and technologies including DICT, FTP, FTPS, Gopher, HTTP 1/2/3, HTTP proxy tunneling, HTTPS, IMAP, Kerberos, LDAP, MQTT, POP3, RTSP, RTMP, SCP, SMTP, and SMB. In addition to the command-line tool, curl also provides a library called libcurl that many other applications can integrate to benefit from the functionality.
Daniel Stenberg, the maintainer of curl, made an announcement last week that an important security patch will be released on October 11 to fix “probably the worst curl security flaw in a long time.” The flaw, tracked as CVE-2023-38545, is a heap buffer overflow and affects curl versions 7.69.0 to 8.3.0 and was patched in version 8.4.0 released Wednesday.
The second flaw, CVE-2023-38546, affects only libcurl and allows for arbitrary cookies injection into a program that uses libcurl. However, the issue is considered low severity.
Curl vulnerability resides in SOCKS5 proxy
A buffer overflow is a type of security vulnerability that happens when a program writes data in an allocated memory buffer in a way that exceeds the size of the buffer and the data spills into other memory regions overwriting data there. Buffer overflows can at the very least result in application crashes (denial of service), but in many cases, controlled exploitation can lead to arbitrary code execution.
This is also the case with CVE-2023-38545. While proof-of-concept exploits have only demonstrated denial of service for now, researchers believe it’s only a matter of time until code execution is achieved. The good news is that only certain configurations of the tool are vulnerable, and they are not the default ones.
“Seeing that curl is an ubiquitous project it can be assumed with good confidence that this vulnerability will get exploited in the wild for remote code execution, with more sophisticated exploits being developed,” researchers from DevOps security firm JFrog said in their analysis. “However – the set of pre-conditions needed in order for a machine to be vulnerable is more restrictive than initially believed. Therefore, we believe the vast majority of curl users won’t be affected by this vulnerability.”
The vulnerability is located in curl’s implementation of the SOCKS5 proxy handshake. SOCKS5 is a network protocol for tunneling data from a client to a server through a proxy server and is widely used on the internet.
When curl is asked to access an URL through a SOCKS5 proxy it can behave in two ways: if the hostname of the URL is 255 bytes long or less, it will ask the SOCKS proxy to resolve it. However, if the host is longer than 255 bytes, the application will switch to local hostname resolution because the SOCKS5 protocol doesn’t allow for hostnames longer than 255 bytes. After resolving the hostname locally, curl will only forward the resulting IP address to the proxy.
“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 curl developers said in their advisory.
This can lead to a buffer overflow if the allocated download buffer is too small to fit the long hostname. An attacker could trigger this from a malicious server by performing a redirect to an address with a long hostname.
“For an overflow to happen it needs a slow enough SOCKS5 handshake to trigger the local variable bug, and the client using a hostname longer than the download buffer,” the maintainers said. “Perhaps with a malicious HTTPS server doing a redirect to an especially crafted URL. Typical server latency is likely ‘slow’ enough to trigger this bug without an attacker needing to influence it by DoS or SOCKS server control.”
Only specific curl configurations impacted
Multiple pre-conditions need to be met for an exploit to work and they are different for libcurl and the curl CLI tool. According to JFrog, the libcurl library is only vulnerable if used in any of the following ways:
The CURLOPT_PROXYTYPE option is set to type CURLPROXY_SOCKS5_HOSTNAME.
The CURLOPT_PROXY or CURLOPT_PRE_PROXY is set to use the scheme socks5h://
One of the proxy environment variables is set to use the socks5h:// scheme. For example, the environment variables http_proxy, HTTPS_PROXY or ALL_PROXY.
The Curl CLI tool is only vulnerable if any of the following conditions are true:
The tool is executed with the –socks5-hostname flag.
The tool is executed with –proxy (-x) or –preproxy set to use the scheme socks5h://.
The tool is executed with relevant environment variables as described above.
In addition, versions 8.x of the curl CLI tool are only vulnerable if the flag –limit-rate is set with a number smaller than 65541.
Moreover, even if these conditions are met, exploiting this flaw using a hostname is not easy because the curl parser only allows ASCII characters in URLs and will invalidate any arbitrary bytes. This makes it hard to build a payload.
Internet Security, Vulnerabilities
