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 with socks5h://
  • If curl runs and any of the following environment variables are set as described
    • CURLOPT_PROXYTYPE set to CURLPROXY_SOCKS5_HOSTNAME
    • CURLOPT_PROXY or CURLOPT_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 circumstances
    • libcurl is used and curl_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 named none 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

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.