Security teams don’t have to swing into crisis mode to address the recently fixed vulnerabilities in the command-line tool curl and the libcurl library, but that doesn’t mean they don’t have to worry about identifying and remediating impacted systems. If the systems are not immediately exploitable, security teams have some time to make those updates.
This Tech Tip aggregates guidance on what security teams need to do to ensure they aren’t at risk.
A foundational networking tool for Unix and Linux systems, cURL is used in command lines and scripts to transfer data. Its prevalence is due to the fact that it is used as both a standalone utility (curl) as well as a library that is included in many different types of applications (libcurl). The libcurl library, which allows developers to access curl APIs from their own code, can be introduced directly into the code, used as a dependency, used as part of an operating system bundle, included as part of a Docker container, or installed on a Kubernetes cluster node.
What Is CVE-2023-38545?
The high severity vulnerability affects curl and libcurl versions 7.69.0 to 8.3.0, and the low severity vulnerability impacts libcurl versions 7.9.1 to 8.3.0. However, the vulnerabilities cannot be exploited under default conditions. An attacker trying to trigger the vulnerability would need to point curl at a malicious server under the attacker’s control, make sure curl is using a SOCKS5 proxy using proxy-resolver mode, configure curl to automatically follow redirects, and set the buffer size to a smaller size.
According to Yair Mizrahi, a senior security researcher at JFrog, the libcurl library is vulnerable only if the following environment variables are set: CURLOPT_PROXYTYPE set to type CURLPROXY_SOCKS5_HOSTNAME; or CURLOPT_PROXY or CURLOPT_PRE_PROXY set to scheme socks5h://. The library is also vulnerable if one of the proxy environment variables is set to use the socks5h:// scheme. The command-line tool is vulnerable only if it is executed with the -socks5-hostname flag, or with –proxy (-x) or –preproxy set to use the scheme socks5h://. It is also vulnerable if curl is executed with the affected environment variables.
“The set of pre-conditions needed in order for a machine to be vulnerable (see previous section) is more restrictive than initially believed. Therefore, we believe the vast majority of curl users won’t be affected by this vulnerability,” Mizrahi wrote in the analysis.
Scan the Environment for Vulnerable Systems
The first thing organizations need to do is to scope their environments to identify all systems using curl and libcurl to assess whether those preconditions exist. Organizations should inventory their systems and evaluate their software delivery processes using software composition analysis tools for code, scanning containers, and application security posture management utilities, notes Alex Ilgayev, head of security research at Cycode. Even though the vulnerability does not affect every implementation of curl, it would be easier to identify the impacted systems if the team starts with a list of potential locations to look.
The following commands identify which versions of curl are installed:
Linux/MacOS:
find / -name curl 2>/dev/null -exec echo "Found: {}" ; -exec {} --version ;
Windows:
Get-ChildItem -Path C: -Recurse -ErrorAction SilentlyContinue -Filter curl.exe | ForEach-Object { Write-Host "Found: $($_.FullName)"; & $_.FullName --version }
GitHub has a query to run in Defender for Endpoint to identify all devices in the environment that have curl installed or use curl. Qualys has published its rules for using its platform.
Organizations using Docker containers or other container technologies should also scan the images for vulnerable versions. A sizable number of rebuilds are expected, particularly in docker images and similar entities that incorporate liburl copies. Docker has pulled together a list of instructions on assessing all images.
To find existing repositories:
docker scout repo enable --org <org-name> <org-name>/scout-demo
To analyze local container images:
docker scout policy [IMAGE] --org [ORG]
This issue highlights the importance of keeping meticulous track of all open source software being used in an organization, according to Henrik Plate, a security researcher at Endor Labs.
“Knowing about all the uses of curl and libcurl is the prerequisite for assessing the actual risk and taking remediation actions, be it patching curl, restricting access to affected systems from untrusted networks, or implementing other countermeasures,” Plate said.
If the application comes with a software bill of materials, that would be a good place to start looking for instances of curl, adds John Gallagher, vice president of Viakoo Labs.
Just because the flaws are not exploitable doesn’t mean the updates are not necessary. Patches are available directly for curl and libcurl, and many of the operating systems (Debian, Ubuntu, Red Hat, etc.) have also pushed fixed versions. Keep an eye out for security updates from other applications, as libcurl is a library used by many operating systems and applications.
One workaround until the updates can be deployed is to force curl to use local hostname resolving when connecting to a SOCKS5 proxy, according to JFrog’s Mizrahi. This syntax uses the socks5 scheme and not socks5h: curl -x socks5://someproxy.com. In the library, replace the environment variable CURLPROXY_SOCKS5_HOSTNAME with CURLPROXY_SOCKS5.
According to Benjamin Marr, a security engineer at Intruder, security teams should be monitoring curl flags for excessive large strings, as that would indicate the system had been compromised. The flags are –socks5-hostname, or –proxy or –preproxy set to use the scheme socks5h://.
Source: www.darkreading.com