Subscribe
The maintainer and original author of curl, Daniel Stenberg, has taken to X (formerly Twitter) and LinkedIn to sound the alarm on what he refers to as “probably the worst security problem found in curl in a long time.”
According to project maintainers, the fixed version, 8.4.0, is set to be released on Wednesday, October 11. While we won’t know much detail about the vulnerability until the fix is released, the open source community and users of curl have been warned to take this issue seriously.
What we do know is that 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.
cURL, which provides both libcurl and the curl command-line tool, is a popular open source library used to transfer data via URLs. 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, and based on our own data, Synopsys has thousands of customers who depend on it.
Announcing a vulnerability before making technical details or fixes available is done to give teams a head start in assessing their applications and environments for exposure, but this practice doesn’t come without risk. Despite having no additional details about the vulnerability, threat actors will undoubtedly begin exploit attempts. Additionally, it’s not unheard of for attackers to post bogus “fixed” versions of a project riddled with malware to take advantage of teams scrambling to patch vulnerable software. Organizations need to work swiftly to assess the exposure of their company and 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.
So what can your team do right now?
Inventory your dependencies to assess impact
The first step in understanding how exposed you are to a vulnerability is knowing what is in your code and the dependencies that power your applications. Software composition analysis (SCA) tools enable teams to scan all the software they create, acquire, download, or consume, independent of origin or function, and build an open source bill of materials (BOM) to list them. Access to source code or build systems is not a requirement as binary SCA solutions can analyze post-build artifacts and provide BOMs of similar accuracy. These open source BOMs will show where curl is used, which versions are in use, and where the origin point for that version is. Knowing the origin point for packages is crucial: not all origins will respond to vulnerable projects as quickly as others.
Most organizations that leverage SCA tools to manage their open source risk on a continuous basis do so by integrating them directly into their software development life cycles via IDEs, CI/CD tools, binary repositories, etc., but it’s never too late to onboard an SCA tool and run a scan to assess your risk. While it is recommended to eventually build SCA into the application’s life cycle, it’s not necessary for teams that are looking to quickly evaluate their applications for exposure to the curl vulnerability.
Prepare to patch
As soon as the new version of curl is released, organizations should be prepared to respond immediately. Project maintainers announced that this will occur on October 11, but depending on your curl package’s provider, ecosystem, or Linux distribution, the timing of the fixed version’s release may vary. Until then, all organizations should have all applicable teams focused on evaluating their exposure and carefully monitoring their package provider for updates.
This is a developing story, but Synopsys will be providing additional information, including patching advice, as more details about the vulnerability are made available. For current Synopsys SCA customers, the vulnerability associated with CVE-2023-38545 will be covered by Black Duck Security Advisory BDSA-2023-2697.
Continue Reading
Introducing fAST Dynamic: Streamlining dynamic application security testing
Mar 19, 2024 / 3 min read
