cURL is a popular project, providing both the libcurl library (used for URL transfers) and the curl command-line tool (used for getting and sending data using URLs). cURL was initially released 27 years ago and has been used universally since the mid-90’s. As one of the most widely used open source projects, it is included in many standard Linux distributions and their container images. Its popularity is comparable to that of Apache Log4j.
There are two vulnerabilities: one impacts both libcurl and curl (CVE-2023-38545) and is said to be the most severe, while the other impacts only libcurl (CVE-2023-38546) and is considered less severe.
The maintainer and original author of curl, Daniel Stenberg, posted to X and LinkedIn to sound an alarm, saying, “Buckle up. This is probably the worst security problem found in curl in a long time.” It’s important for the open source community and curl users to take this issue very seriously and lay out a plan to discover and fix impacted software. On Wednesday, October 11, Stenberg released curl 8.4.0 with fixes for both vulnerabilities.
Threat actors will undoubtedly begin to exploit these vulnerabilities and perhaps post false “fixed” versions of a project with malware to take advantage of teams attempting to patch vulnerable software. Organizations need to work quickly to assess their exposure and exposure for their customers before full vulnerability details are published, monitor their systems for indications of exploit attempts, and be vigilant as to where they get their patches and fixed versions of curl.
Steps to take:
- Start now to understand your total exposure by knowing what’s in your code and the dependencies within your applications. Check your container and package usage now to gauge your exposure, identify hosts that have curl installed and determine how it was installed, and check the curl version you are using. Software Composition Analysis solutions like Code Insight can scan the software you create, acquire, and consume.
- If you can’t create a Software Bill of Materials (SBOM), now is the time to add this functionality to your standard operating practices for development and security teams. An SBOM is a formal and queryable record containing the details and relationships of various components used in building software. It’s similar to the ingredients list on your food labels. SBOMs will show where curl is used, which versions are in use, and where the origin point for that version is. SBOM Insights tracks all software components in your software, regardless of where in the supply chain they originate.
- As soon as the new version of curl is released, organizations should be prepared to respond immediately. You should have all applicable teams—security, software development and legal—focused on evaluating exposure and carefully monitoring package providers for updates.
In addition to the upstream patched version, several Linux distributions have already published fixed versions of curl, most notably Debian, Ubuntu, Alpine and SUSE.
A few things to keep in mind:
- As always, security patches tend to take a few attempts to fully resolve, so keep an eye our for subsequent patches as more exploit scenarios are uncovered and/or additional security issues are reported.
- Even if you are not a software supplier, don’t forget to check your servers as you likely have cURL installed on them in your data center. Make sure you upgrade all instances to the appropriate “latest” version as patches are released.
- Finally, do not forget to check derivative projects that were base on or ported from cURL for impact… i.e., pycurl, python-pycurl, and others.
