Listen to post:
TL;DR This vulnerability appears to be less severe than initially anticipated. Cato customers and infrastructure are secure.
Last week the original author and long-time lead developer of cURL Daniel Stenberg published a “teaser” for a HIGH severity vulnerability in the ubiquitous libcurl development library and the curl command-line utility.
A week of anticipation, multiple heinous crimes against humanity and a declaration of war later, the vulnerability was disclosed publicly.
The initial announcement caused what in hindsight can be categorized as somewhat undue panic in the security and sysadmin worlds. But given how widespread the usage of libcurl and curl is around the world (at Cato we use widely as well, more on that below), and to quote from the libcurl website – “We estimate that every internet connected human on the globe uses (lib)curl, knowingly or not, every day”, the initial concern was more than understandable.
The libcurl library and the curl utility are used for interacting with URLs and for various multiprotocol file transfers, they are bundled into all the major Linux/UNIX distributions. Likely for that reason the project maintainers opted to keep the vulnerability disclosure private, and shared very little details to deter attackers, only letting the OS distributions maintainers know in advance while patched version are made ready in the respective package management systems for when it is disclosed.Rapid CVE Mitigation by Cato Security Research
The vulnerability in detail
The code containing the buffer overflow vulnerability is part of curl’s support for the SOCKS5 proxy protocol.
SOCKS5 is a simple and well-known (while not very well-used nowadays) protocol for setting up an organizational proxy or quite often for anonymizing traffic, like it is used in the Tor network.
The vulnerability is in libcurl hostname resolution which is either delegated to the target proxy server or done by libcurl itself. If a hostname larger than 255 bytes is given, then it turns to local resolution and only passed the resolved address. Due to the bug, and in a slow enough handshake (“slow enough” being typical server latency according to the post), the Buffer Overflow can be triggered, and the entire “too-long-hostname” being copied to the buffer instead of the resolved result.
There are multiple conditions that need to be met for the vulnerability to be exploited, specifically:
- In applications that do not set “CURLOPT_BUFFERSIZE” or set it below 65541. Important to note that the curl utility itself sets it to 100kB and so is not vulnerable unless changed specifically in the command line.
- CURLOPT_PROXYTYPE set to type CURLPROXY_SOCKS5_HOSTNAME
- CURLOPT_PROXY or CURLOPT_PRE_PROXY set to use the scheme socks5h://
A possible way to exploit the buffer overflow would likely require the attacker to control a webserver which is contacted by the libcurl client over SOCKS5, could make it return a crafted redirect (HTTP 30x response) which will contain a Location header with a long enough hostname to trigger the buffer overflow.
Cato’s usage of (lib)curl
At Cato we of course utilize both libcurl and curl itself for multiple purposes:
- curl and libcurl based applications are used extensively in our global infrastructure in scripts and in-house applications.
- Cato’s SDP Client also implements libcurl and uses it for multiple functions.
We do not use SOCKS5, and Cato’s code and infrastructure are not vulnerable to any form of this CVE.
Cato’s analysis response to the CVE
Based on the CVE details and the public POC shared along with the disclosure, Cato’s Research Labs researchers believe that chances for this to be exploited successfully are medium – low.
Nevertheless we have of course added IPS signatures for this CVE, providing Cato connected sites worldwide the peace and quiet through virtual patching, blocking attempts for an exploit with a detect-to-protect time of 1 day and 3 hours for all users and sites connected to Cato worldwide, and Opt-In Protection already available after 14 hours.
Cato’s recommendation is as always to patch impacted servers and applications, affected versions being from libcurl 7.69.0 to and including 8.3.0. In addition, it is possible to mitigate by identifying usage as already stated of the parameters that can lead to the vulnerability being triggered – CURLOPT_PROXYTYPE, CURLOPT_PROXY, CURLOPT_PRE_PROXY.
For more insights on CVE-2023-38545 specifically and many other interesting and nerdy Cybersecurity stories, listen (and subscribe!) to Cato’s podcast – The Ring of Defense: A CyberSecurity Podcast (also available in audio form).