Vulnerabilities

Active Vuln Alert: cURL/libcurl

4 min read

Mar 7, 2023 12:06:30 PM

It all started with a joke with the folks at Trail of Bits, where they contemplated whether anyone had ever performed any fuzzing against the command line options of cURL. Specifically, fuzzing with all sorts of unexpected “malformed” data to command line options that expect nice, well formatted data.

The fuzzing performed by Trail of Bits revealed a few surprising results, including 4 different vulnerability disclosures. For this writing, we’ll be focused on CVE-2022-42915 and CVE-2022-43552, and not the two cURL internally tracked disclosures, TOB-CURL-10 and TOB-CURL-11.

We’ll address the technical details of the CVEs shortly here, but first, we need to understand why these particular disclosures are important: while the discoveries were against the command line options to cURL they also apply to any programmatic implementation of cURL through libcurl!

For this reason alone we feel that the subsequent issues with the use of vulnerable versions of libcurl is highly under-represented, especially where libcurl is an incredibly popular method for programmatically accessing remote content via HTTP, HTTPS, and other protocols. These actions could be for firmware update retrieval and version checks, configuration backup and retrieval, and more.

Why should we care? What is the high-level risk?

cURL, and therefore libcurl, are everywhere, and much like the log4j problem, without accurate SBOMs across the organization, many will be left not knowing whether or not they are actually vulnerable.

While these two vulnerabilities are rated high and medium respectively, they do require some specific conditions to be triggered. However, this is likely just the beginning of more in-depth analysis of cURL and libcurl as a whole, with more fuzzing and exploits to find. With the ubiquitous nature of libcurl, now is the time to populate a detailed SBOM inventory.

Who should care?

If you are developing for any XoT industry, you should be mindful of these libcurl issues as they pose a potentially high security risk, which could result in compromise of the affected device.

As a consumer, attacks against these specific vulnerabilities can cause instability and even denial-of-service of the device, as well as potential for overall device compromise. If compromised, an affected device can be used by an attacker to perform lateral movement, or manipulation of a business/OT process controlled by the affected device.

Technical and process implications

CVE-2022-42915 - Double free when using HTTP proxy with specific protocols

When cURL is configured with proxy for outbound connections the use of cURL for the DICT, GOPHER, LDAP, or TELNET protocol can trigger a double-free vulnerability due to flaws in the error/cleanup handling.

CVE-2022-43552 - Use-after-free when HTTP proxy denies tunneling SMB/TELNET protocols

cURL can be used to tunnel multiple protocols through an HTTP proxy. If the upstream HTTP proxy denies the use of the TELNET or SMB protocols, cURL may use a struct that has already been freed.

Key facts to consider

In these two cases, libcurl is dependent on the end device being configured to use a proxy. This situation for XoT devices is not unique, especially where internet access needs to be granted to these devices where they are used in sensitive, healthcare, and OT/ICS networks, and even enterprise networks with robust security postures.

Our perspective

Having access to the analysis of many binaries through the Finite State platform, we get a unique perspective on how ubiquitous libcurl is used across third-party components. Of the vulnerable version for the two CVEs we were able to observe many thousands of vulnerable implementations.

In even recent analysis, libcurl isn’t just for Linux based firmware: it is known to be used in Windows, vxWorks (through third party ports) and even on bare metal firmware (such as the ESP32, https://github.com/whitecatboard/Lua-RTOS-ESP32/tree/master/components/curl).

Practical risk implications and how to resolve

There are several things to consider to manage libcurl issues, depending on where your organization fits into the supply chain.

As a developer of XoT products, migrate current development efforts utilizing cURL or libcurl to at least version 7.87.0. Update all existing products at the next available update cycle to at least version 7.87.0.

As a consumer (across any number of verticals) you may be unaware if the affected versions are in use in devices in your environment. Consider reaching out to your vendors to obtain an accurate SBOM with cURL/libcurl versions across all first and third-party firmware components. If vulnerable versions exist in products in use, inquire with the vendor on their efforts to remediate.

As a consumer and implementer, consider revising defense in depth capabilities at the network level to further restrict devices using vulnerable versions. This could include limiting overall internet access, restricting internet access, and/or disabling the use of an upstream proxy.