A CURL your toes fright fest: CVE-2023-38545 two weeks later

At Slim.AI, we constantly monitor containers for security issues, both for our customers and for approximately 500 of what we deem to be the world’s most popular public containers. So when major vulnerabilities come to the fore — as happened two weeks ago when cURL, one of the world’s most popular and ubiquitous dev tools, announced a HIGH severity vulnerability — we naturally ask the question: Who’s fixed this and who hasn’t?

In the case of CVE-2023-38545, which cURL maintainers dubbed “the worst security issue we’ve seen in curl in a long time”, what we found was both promising and a bit scary. Two weeks later, despite major distros having patched the vulnerability quickly and the security community making sure it was no secret via social media, some 33-percent of the world’s most popular public containers still haven’t been updated.

‍

Remediating the vulnerability is as simple as updating your cURL version to 8.4, yet several containers in our dataset have failed to do so. Initially, we discovered 103 vulnerable images out of the approximately 500 images we track on a regular basis across multiple public image registries. That is to say, these 103 contained a vulnerable version of cURL in their latest version that was flagged by open source scanners Grype and Trivvy that we use for analysis.

Just one day later, 39-percent of those images had been fixed, with Slim’s container profiling system detecting new versions of cURL (8.4) and open source vulnerability scanners Grype and Trivvy no longer recording the CVE.

Over the course of two weeks, another 29 public images took in the updates. Considering  most public container images follow a 1-day or 7-day update cycle, meaning in two weeks, most should have already patched this issue.

So why do we still see so many images still impacted by CVE-2023-38545? And what does that mean for your security profile?

‍

What is cURL?

For those who don’t know, cURL is probably the most used and one of the most loved Linux dev tools on the planet. It was released the same year (1996) as Space Jam and the Spice Girls’s debut album, Spice, if that means anything to you.

cURL is used by developers to make HTTP requests, useful for say, pinging websites, testing API endpoints, or downloading assets. Its “bottle opener”-level utility means that it is commonly included in container base images as a convenience for developers.

Less commonly, developers actually NEED cURL in their containers to perform certain functions. While having a tool that can make HTTP calls to the open internet gives most DevSecOps teams a tingling feeling on the back of their necks, production environments are often locked down to prevent outbound traffic and have other controls. These types of production configurations have a big impact on the “exploitability” of a given CVE.

Still, best practice would dictate that once dev and testing suites are completed, cURL should be removed if it isn’t being used by the production application. Zero-day vulnerabilities such as CVE-2023-38545 provide a textbook case for why shipping only what you need to production is a container best practice.

About CVE-2023-38545: The exploit and its reachability profile

It should be said that the disclosure of this vulnerability was well done. The cURL maintainers made it known to the community that an important vulnerability — “the worst security issue we’ve seen in curl in a long time”, they wrote — was coming in the 8.4 patch and that users should upgrade immediately.

It should also be said that while the CVE was rated as a High, the relative exposure was relatively low. Remember:

‍

This vulnerability required certain configurations to be present (use of the SOCKS5 proxy), and experts estimated that only a small number of users would be exposed. In fact, in our analysis of these containers, we did not find a single instance of where cURL would be reachable within the container (that is to say, there was no application code that explicitly called cURL based on Slim’s proprietary profiling analysis).

‍

Still, the impact of the vulnerability being exploited is dire, according to experts. At Slim, we’ve recently launched to customers a “CVE Chatbot” that can answer questions about CVE information — it is, naturally, based on an LLM. According to our “Codi P.I.” bot: 'If an attacker successfully exploited this CVE, they could potentially execute arbitrary code or crash the application.'

‍

Why aren’t top public containers updating?

So if this CVE was such a big deal, why do we still see so many popular public images that are still impacted? There are plenty of reasons, some more valid than others.

At Slim, we’re working hard to eliminate the friction that comes with vulnerability remediation. Here are some reasons these images may not be fixed, and how Slim is working to make these blockers easier for teams to manage, whether you are the one using the image or the one maintaining it.

• Not exposed: While vulnerability scanners present issues as black-and-white, reality is often more grayscale. As shown above, this vulnerability is only exploitable under specific conditions. It’s possible the security and dev teams for these images did an assessment and determined their exposure risk to be low.Still, if this were the case, it’d be nice to have that communicated clearly. That’s one reason Slim is working on Collaborative Workspaces for vulnerability remediation.
• Not aware: In our dataset, we include both open source images and those supported by for-profit organizations. While one hopes organizations are scanning their images for vulnerabilities, it’s possible open source communities are less likely to do so, given their images are *caveat emptor (*buyer beware).  At Slim, we’re aiding organizations and open source communities both by allowing them to automatically watch container images and get notifications when new vulnerabilities appear.‍
• Not incentivized: Too often, security is a reactive pursuit, and organizations won’t fix items without pressure from their customers. Customers may be consuming public images and trying to patch issues themselves, or the focus of security teams may be on paying customers, who consume an alternative set of “enterprise” images.Whatever the case, customers have a hard time managing all of their suppliers and the vulnerabilities related to their containers. The Slim platform helps, by creating a shared, prioritized view of vulnerabilities.

So, which ones are still vulnerable?

Our goal for this article was not to “name and shame” containers whose versions of cURL are out of date. We’ve reached out directly to maintainers of those container images where we could to notify them.

Container vulnerability scanner technology — including the engines we host on Slim.AI — are sufficient to detect the outdated versions. If you are concerned about your containers, login to Slim and start scanning your own containers today.

Want to manage vulnerability remediation and cURL updates more effectively? Join our beta to get access to our collaborative workspaces for vulnerability management.

‍

‍