No you can’t ‘WAF patch’ curl vulns CVE-2023-38545 and CVE-2023-38546
Anyone who’s responsible for WAF or “perimeter security” might get asked by their manager or colleagues today whether they can “virtually patch” new curl CVEs CVE-2023-38545 and CVE-2023-38546.
I hope you don’t get asked, but the short answer is NO and you should be armed with the means to defend yourself.
For the sake of specificity, let us assume the “WAF” under your purview is a “traditional” one like Google Cloud Armor WAF, AWS WAF, or Azure Web Application Firewall (WAF). Something like Signal Sciences or, better yet, Traceable is more probable help here. A separate discussion.
We’ll go through each actual vulnerability. It will become clear that these are much more varied than Log4J in their manifestations.
CVE-2023-38545
CVE-2023-38545 : “SOCKS5 heap buffer overflow” (High) : https://curl.se/docs/CVE-2023-38545.html
Conditions for exploit
- Exploitable if curl is a version between 7.9.1 to 8.3.0 (inclusive), used in proxy-resolver mode via a SOCKS5 proxy, on a vulnerable curl version, with a way for attackers to control which server curl is pointing at, e.g. with untrusted user inputs on a public application
- curl must be exposed somewhere attacker-accessible
- The attacker must be able to point curl at a malicious server they control
- curl must be using a SOCKS5 proxy using proxy-resolver mode
- curl must be configured to automatically follow redirects
- An overflow is only possible in applications that do not set CURLOPT_BUFFERSIZE when using libcurl, or set it smaller than 65541
- Since curl sets CURLOPT_BUFFERSIZE to 100kB by default it is not vulnerable in its default state
- The SOCKS5 handshake to trigger the local variable bug needs to be “slow enough” to trigger the local variable bug
- This is unclear but vulnerability disclosure does suggest “typical server latency is likely slow enough”
How to identify exploitation
- If curl runs with any of the following flags set to “excessively large” string values
--socks5-hostname
--proxy
or--preproxy
then value starts withsocks5h://
- If curl runs and any of the following environment variables are set as described
CURLOPT_PROXYTYPE
set toCURLPROXY_SOCKS5_HOSTNAME
CURLOPT_PROXY
orCURLOPT_PRE_PROXY
set to value starting with `
CVE-2023-38546
CVE-2023-38546 : “cookie injection with none file” (Low) : https://curl.se/docs/CVE-2023-38546.html
Conditions for exploit
- Exploitable if curl is a version between 7.9.1 to 8.3.0 (inclusive), attacker is able to place a specially crafted file
none
into the working directory from which libcurl runs, then curl_easy_duphandle function makes a duplicate handle, then that duplicate handle will load the attacker’s crafted cookies file by default when it runs in the future under otherwise cookie-less circumstanceslibcurl
is used andcurl_easy_duphandle
function is called- A transfer with cookies enabled is taking place when
curl_easy_duphandle
function is called - The source handle (the handle being duplicated) doesn’t actually provide cookies, causing the duplicate handle to point to a file named
none
(4 ASCII characters) for its cookie state - The duplicated handle gets called without any cookies provided
- This causes it to look for a local-to-
libcurl
file namednone
to load the cookies from, as its default behavior - A malicious file none exists, local to where libcurl runs, and its contents are correctly-formatted cookie data, which will be loaded and used as default cookies for connections made by the duplicated handle (so only taking effect when the connection would’ve otherwise been cookie-less)
How to identify exploitation
- Presence of a file named
none
in a location local to wherelibcurl
runs from, with contents that adhere to curl cookie struct file format
Closing thoughts
Given all the above, these CVEs are not feasible to detect/block via WAF rules (or whatever OSI Model Layer 7 logic).
For the sake of being thorough, you might ask your Big Public Cloud WAF vendor whether they’ll be adding any managed rules for this (like they’ve previously done for Log4j).
Hopefully you’ve never had to “hand-craft” and deploy any CVE WAF “virtual patches” at scale. And anyway, this doesn’t seem like a situation that warrants it. Even Log4j was largely just a matter of spreading out vendor-provided rules.
The WAF folks should not be a dumping ground for other security people. A “junk drawer,” if you will, for unclear-to-assign security tasks.
Big scary-sounding, press-fueled CVEs are just the kinds of conditions to get work routed your unfortunate way, WAF Wranglers of the Earth.