Addressing the high severity vulnerability in curl

On October 4, 2023, the curl project maintainers sent out a pre-notification that curl version 8.4.0, expected to be released on October 11 (around 06:00 UTC), will address what they denote as the most serious vulnerability in recent years. Curl is a de-facto standard in the software business when it comes to web requests, and supports a wide range of communication protocols. Depending on the vulnerability, it could have far reaching implications.

Update from October 11: This section was updated following the release of curl version 8.4.0.

In review, the vulnerabilities under specific conditions are dangerous. However, the pre-conditions include very specific configurations, including a SOCKS5 proxy, slow responses, and a buffer overwrite, with limitations on valid characters for input.

Affected versions: libcurl 7.69.0 to and including 8.3.0
1. Upgrade curl to version 8.4.0
2. Apply the patch to your local version
3. Do not use CURLPROXY_SOCKS5_HOSTNAME proxies with curl
4. Do not set a proxy environment variable to socks5h://

What is curl?

Curl is used by very large sets of software, both as a component, or embedded in the code as a software library. Curl is often used in automation tools, scripts and other administrative functions in the background of how organizations work. It may also be present in embedded devices, IOT units and more. Its wide distribution and tendency to be deeply linked with automated processes means that while we are likely to see a relatively fast initial patching, the risk will remain dormant in many less maintained or updated systems – most likely for a substantial amount of time.

This is not the new Log4j, right?

No, it is not, not nearly. The reason for this is that curl is a client-side library and software. It is used to send requests to other systems. As we do not know the nature of the vulnerability yet, it is too early to speculate on how the risk is likely to impact organizations as exploitation will depend on an ability to interact with affected systems.

This makes the vulnerability more akin to the recent CVE-2023-4863, in that it is a vulnerability hiding dormant under the surface, yet still one more step harder to target for attackers.

How will you detect the vulnerability?

This is a standard product and a standard library, but it is a client-side vulnerability. This means that authenticated scanning will be required, or the use of an installed agent. Some deviations may exist, such as cases where curl is found to be embedded in a software which in turn is observable by known signatures or network services and the presence of it can be deduced based on those elements. The most important conclusion will be that authenticated access to a system is required.

What can organizations do to prepare?

First, if your organization provides software or distributions for others, you must determine your product dependencies on curl. On release day, be prepared to update to version 8.4.0, as your customers cannot patch your provided solution themselves without such updates. Second, ensure that patching is timely for all systems using curl.

If you are a HIAB or OUTSCAN NX customer using the NETSEC solutions, this is relatively straight-forward. Go to the Reporting view, select Advanced Filters, and enter curl. This will initially give you findings for any vulnerabilities, and not just installed software. If you want to reduce this to one entry per host, filter on Script ID “1221985”, or Name “Products Installed” in the Reporting view.

high severity vulnerability curl

The above will give you good insight on where curl is already installed in your environments. This does not help you identify dependencies or where it is embedded in other software, but those detections will come as soon as that information is available from affected vendors.

What to do next

Set aside some time for patch and maintenance on the 11th of October. If you have systems using curl against untrusted sources, consider not running those process before the patch has been deployed. Do not forget about your container’s virtual machines.

This post will be followed by a more in-depth analysis once the vulnerability report is disclosed by the maintainers.

About the Author

Martin Jartelius
Martin Jartelius CISO, Outpost24

Martin is the esteemed Outpost24 group CISO, bringing with him a wealth of experience in penetration testing and forensics. With more than a decade of dedicated work in the vulnerability management field, Martin not only oversees but also provides support to the teams engaged in researching threat actors, malware, and vulnerabilities.