Security Advisory: High Severity Curl Vulnerability

Editor’s note: Following the release of curl 8.4.0, this post was updated on October 11, 2023 to add more detail about the vulnerability and information on how to use Docker Scout to remediate this issue should you discover a dependency on an affected version of curl.

---

The maintainers of curl, the popular command-line tool and library for transferring data with URLs, released curl 8.4.0 on October 11, 2023. This version includes a fix for two common vulnerabilities and exposures (CVEs), one of which the curl maintainers rate as “HIGH” severity and described as “probably the worst curl security flaw in a long time.” 

The CVE IDs are: 

• CVE-2023-38545: SOCKS5 heap buffer overflow, severity HIGH (affects both libcurl and the curl tool)
• CVE-2023-38546: Cookie injection with none file, severity LOW (affects libcurl only, not the tool)

Details on how these CVEs are exploited are published along with the advisory. But curl maintainer, Daniel Stenberg, also published a blog post with more detail about how the vulnerability came about through the specific implementation of support for SOCKS5.

This post explains how you can use Docker Scout to understand if you have a dependency on curl in your container images. We’ll also provide guidance on where the dependency was introduced and how to update curl to 8.4.0.   

Am I vulnerable?

Having a dependency on curl won’t necessarily mean the exploit will be possible for your application. But Docker Scout can help explain if your images have a dependency on curl, how the CVE is exploitable, and how to upgrade to the latest version (should you have a dependency or exploitable implementation).  

Quickest way to assess all images 

The quickest way to assess all images is to enable Docker Scout for your container registry. 

Step 1: Enable Docker Scout

Docker Scout currently supports Docker Hub, JFrog Artifactory, and AWS Elastic Container Registry. Instructions for integrating Docker Scout with these container registries:

• Integrating Docker Scout with Docker Hub
• Integrating Docker Scout with JFrog Artifactory
• Integrating Docker Scout with AWS Elastic Container Registry

Note: If your container registry isn’t supported right now, you’ll need to use the local evaluation method via the CLI, described later.

Step 2: Select the repositories you want to analyze and kick off an analysis

Docker Scout analyzes all local images by default, but to analyze images in remote repositories, you need to enable Docker Scout image analysis. You can do this from Docker Hub, the Docker Scout Dashboard, and CLI. Find out how in the overview guide.

1. Sign in to your Docker account with the docker login command or use the Sign in button in Docker Desktop.
2. Use the Docker CLI docker scout repo enable command to enable analysis on an existing repository:

$ docker scout repo enable --org <org-name> <org-name>/scout-demo

Step 3: Visit scout.docker.com 

On the scout.docker.com homepage, find the policy card called No vulnerable version of curl and select View details (Figure 1). 

The resulting list contains all the images that violate this policy — that is, they contain a version of curl that is likely to be susceptible to the HIGH severity CVE (CVE-2023-38545) listed above.

Step 4: Identify where the curl dependency is introduced

For each of the images in the list that fail to meet the “No vulnerable versions of curl” policy, click on the tag (eg “latest”) to open the layer view.

The layer view breaks down the composition of your container image to help you understand where the vulnerable version of curl is being introduced.

Typically, this will be in one of two places: the base image that you’re image builds on top of or in an application where libcurl is introduced as a package dependency.

Step 5: Choose your remediation path

The results in the image layer view will determine your first course of action. But since curl is distributed in most OS base images, you’ll probably want to start by updating the base image.

If your image uses the latest base image tag, you can kick off a new build (either locally or in your pipeline), push the new image into your registry, and return to Step 3.

If, having returned to Step 3, you still see policy violations and warnings on the base image layers, this may be due to the upstream maintainers still working on updating curl versions. 

If, having returned to Step 3, you still see policy violations and warnings on the application layers, you’ll need to manually bump the version of curl your application code has a dependency on, then build and push again.

Alternative CLI method

Step 1: Evaluate the container image

An alternative method is to use the Docker Scout CLI to analyze and evaluate local container images.

You can use the docker scout policy command to evaluate images against Docker Scout’s built-in policies on the command line, including the No vulnerable version of curl. 

docker scout policy [IMAGE] --org [ORG]

If you’d rather understand all the CVEs identified in an individual container image, you can run the following command. This method doesn’t require you to enable Docker Scout in your container registry but will take a little longer if you have a large number of images to analyze. 

docker scout cves [OPTIONS] [IMAGE|DIRECTORY|ARCHIVE]

Step 2: View recommendations

You can use Docker Scout recommendations to understand which remediation paths are available. More specifically, you can discover what base image updates will remove known vulnerabilities.

docker scout recommendations [IMAGE]

Learn more

• Follow direct updates from the maintainer of curl project via the GitHub issue.
• Learn more about Docker Scout at docs.docker.com/scout.
• Read Announcing Docker Scout GA: Actionable Insights for the Software Supply Chain.