New Information From Rezilion Research

A high-severity cURL vulnerability (CVE-2023-38545) is expected to be published in tandem with the 8.4.0 releases of the package on October 11th. While not much is known about the nature of the vulnerability, according to Daniel Stenberg, Curl’s creator and core maintainer, the vulnerability is “the worst security problem found in curl in a long time”. 

A heads-up notice posted on X (formerly Twitter), states that the project has decided to expedite the release cycle in order to address a high-severity vulnerability affecting both cURL as well as the libcurl library.

The vulnerability, CVE-2023-38545, is planned to be published immediately after the release of version 8.4.0 that addresses it, probably in order to minimize the likelihood of exploitation. 

Both the CVE-2023-38545 vulnerability, along CVE-2023-38546, an additional low-severity vulnerability affecting only libcurl, are currently in RESERVED status.

This scenario presents an interesting challenge for security teams wanting to get a headstart on identifying affected assets – Since no vulnerability metadata has yet been published (specifically no CPE values), no vulnerability scanner will be able to detect it. 

This scenario highlights the necessity of having a queriable Software Bill of Materials (SBOM). If you have a queryable SBOM, you should utilize it to pinpoint all occurrences of curl & libcurl in your environment, so that once version 8.4.0 releases, you’ll be able to take immediate action.

The Potential Scope 

cURL is a 25 year old software project providing a library (libcurl) and a command-line tool (curl) for transferring data using various network protocols.

While cURL is an extremely popular utility, libcurl is probably the world’s most popular and widely used HTTP client-side library with over ten billion installations.

Almost every single internet-connected device is utilizing it. This includes most operating systems, servers, medical devices, servers, printers, and even cars, game consoles, and smartwatches. It is literally everywhere!

• A simple GitHub code search reveals over 1.4K Open-Source projects that declare using libcurl as part of the project description. Some of these projects are bindings for at least these 60 different environments, allowing developers to access and use libcurl from most programming languages.

• Most Dockerfiles utilize curl (the ones that don’t use wget) as part of the container build process

• Most modern operating systems use libcurl

• And the number of packages that utilize it as a dependency is enormous! Examples include: git, libcurl4-gnutls-dev, python-pycurl, libcurl4-openssl-dev, rng-tools, gnupg2, zabbix-agent, systemd, apache2-bin, xmlrpc-c-client, sssd-common, ipa-client, certmonger, php-curl, fwupd, libfwupd2, libreoffice-core, librepo, libraptor2-0, libcmis-0.5-5v5, python3-pycurl, passenger, geoipupdate, libappstream4, rsyslog, NetworkManager, python3-librepo, php8.1-curl, elfutils-debuginfod-client, cargo, python27-pycurl, git-core, mariadb-connector-c, apt-transport-https, php7.0-curl, google-chrome-stable, NetworkManager-cloud-setup, google-compute-engine-oslogin, qemu-block-extra, tpm2-tss, strongswan, syslog-ng-core, libcfitsio8, libcurl-devel, gnupg1, and many more.

The impact of the vulnerability is yet to be seen and will probably only become clearer once the vulnerability is officially published on October 11th. Actually, you might recall that almost one year ago, in late October 2022, a similar situation occurred involving the OpenSSL library. Back then, the OpenSSL Project announced a “critical” vulnerability in versions 3.0 and above of the vastly popular cryptographic library.

No additional details were disclosed, yet the critical classification of the vulnerability, only for the second time in the project’s history (the first and only other was the 2014 Heartbleed Bug), caused the security community to speculate the worst-case scenario.

When the vulnerabilities were eventually disclosed the concern was proven to be exaggerated as attack complexity along with a relatively low number of potentially vulnerable systems utilizing OpenSSL 3.x, made exploitation in the wild to be barely seen.

Will this be the case here as well? I guess all we have left to do is wait and see…

Well, actually you shouldn’t wait!

You should use the time until more information about the vulnerability is made public to identify all occurrences of cURL and libcurl, prioritize which to address first based on their location and status  so that once version 8.4.0 releases, you’ll be able to take immediate action 

This scenario underscores the importance of having a queryable Software Bill of Materials (SBOM). If you have such a queryable SBOM, utilize it to pinpoint all occurrences of curl & libcurl in your environment.

If you don’t?

Prepare for a hectic week…

_________________________________________________________________

Get Help with CVE-2023-38545

To help organizations work around potential blindspots in their ability to detect all instances of CVE-2023-38545 within their environment, Rezilion is now offering a free risk assessment program.

Through this opportunity, organizations can access Rezilion’s inherent Dynamic SBOM capability to simply query the dependency tree of any environment in which Rezilion is deployed to instantly identify instances of software components using vulnerable libcurl versions as a dependency. 

For example, in this screenshot from the Rezilion platform, on the right-hand side you can see examples of various components that are dependent on vulnerable versions of libcurl, including whether these components are actually in use (loaded to memory) or not:

No code, no agents, and no formal commitment are required to participate in the free risk assessment. Benefits of the program include: 

• Pinpoint ALL instances of CVE-2023-38545 in your software and dependencies – fast – with instant search capabilities
• Know if instances are exploitable in your unique environments – not just exploitable in the wild – with the platform’s patented Runtime Analysis capabilities
• Get smart guidance on not just what and where to patch, but which version patch to use to avoid breaking your build 
• Share a complete software bill of materials (SBOM) of your dynamic software environment – and its risks – to assure customers that you are in compliance with security policies and requirements

To learn more about the free risk assessment, visit https://info.rezilion.com/lp/curl-risk-assessment 

The post CVE-2023-38545, A High Severity cURL and libcurl CVE, to be published on October 11th appeared first on Rezilion.

*** This is a Security Bloggers Network syndicated blog from Rezilion authored by Yotam Perkal. Read the original post at: https://www.rezilion.com/blog/cve-2023-38545-a-high-severity-curl-and-libcurl-cve-to-be-published-on-october-11th/