A Guide to Managing Docker CVEs

What is a Docker CVE?

Let’s begin by discussing how Docker security vulnerabilities are reported and tracked.

Typically, this happens using the Common Vulnerabilities and Exposure (CVE) system, which tracks known security vulnerabilities. By scanning software they are running and checking the results against lists of CVEs (like those in the Aqua Vulnerability Database), businesses can determine whether any of the software they use is subject to a known vulnerability.

It’s important to note that CVEs record only vulnerabilities that have been publicly documented; it’s possible for risks to exist that have not yet been reported through the CVE system, although scanning for CVEs is a first step toward identifying risks in your software.

Docker CVEs are CVEs associated with any aspect of the Docker software ecosystem – such as the Docker runtime (which executes Docker containers), Docker’s tools for building container images and Docker’s desktop software.

Types of Docker vulnerabilities

Docker vulnerabilities come in many forms. Common examples of risks associated with  Docker vulnerabilities include:

• Container escape: This occurs when configuration mistakes or software bugs allow containers to “escape” their container environments and access the host system.
• Malware execution: Vulnerabilities could enable to execute arbitrary code, which means they can plant and run malware on an affected system.

• Container registry security flaws: Container registries can become vulnerable due to misconfigurations, such as missing access controls that allow anyone to download or modify sensitive container images.

• Image vulnerabilities: Vulnerabilities can appear in container images if the images are based on code that contains unpatched vulnerabilities, or if a container image uses vulnerable packages or libraries.
• Runtime vulnerabilities: Bugs in container runtimes like runC, which are the software responsible for executing containers, can allow attackers to take control of containers or, in extreme cases, the host system.

As we mentioned above, risks like these are inherent to application deployment strategies that leverage Docker. They wouldn’t impact traditional applications because those apps don’t typically use resources like images and dedicated runtimes. But when you use containers, your attack surface broadens due to the additional tools necessary to run containerized apps.

Docker security examples: Top 4 Docker CVEs

To illustrate common examples of Docker security vulnerabilities in the real world, here’s a look at what we consider the four most significant Docker CVEs issued to date.

#1. CVE-2019-5736

CVE-2019-5736 is a vulnerability that affects runC, a popular container runtime. It allows attackers to gain root access on vulnerable systems – which effectively means they can take over not just containers, but the entire server that hosts them.

#2. CVE-2018-15664

CVE-2018-15664 also enables attackers to gain root-level privileges on the systems that host containers. In this case, they do so using directory traversal. The direct impact of this vulnerability is limited to allowing root-level read and write access to host file systems; however, by modifying system directories, attackers could potentially plant malware or escalate privileges.

#3. CVE-2022-0185

CVE-2022-0185 is a vulnerability that impacts the Linux kernel, not Docker specifically. Nonetheless, by exploiting the vulnerability, threat actors can launch container escape attacks.

#4. CVE-2019-14271

The vulnerability reported as CVE-2019-14271 allows arbitrary code injection through containers. This effectively means that attackers can load software of their choosing, including malware, onto affected systems.

Best practices to manage Docker risk and vulnerabilities

Typically, vulnerabilities arise due to flaws in the source code for Docker tools or images. This means there’s not much that most organizations that use Docker can do to prevent vulnerabilities, because they don’t typically control the source code.

But what Docker users can do is take steps to identify and protect themselves against vulnerabilities via practices like the following.

Regularly scan Docker images

A key best practice is to scan Docker images regularly using Docker scanning tools. For example, using Trivy, a popular open source scanning tool, teams can generate lists of vulnerabilities inside container images:

Since each new or updated image could contain new vulnerabilities – and because new vulnerabilities are regularly disclosed that could exist in images that were scanned previously – scanning should occur regularly, not just prior to image pulls or application deployment.

Scan software supply chains

Docker tools that a business uses to deploy containers are examples of components in its software supply chain, since Docker is third-party software. This means that the principles of software supply chain security apply to an organization that uses Docker.

Teams should know which Docker tools they’re using, as well as the specific version of each tool. With this information, they can determine whether any Docker components, such as the runtime, are subject to CVEs.

Keep Docker and dependencies updated

Installing updates for Docker and related software (like Kubernetes) whenever they become available is important because updates may patch CVEs. Typically, software vendors or developers release patches to remediate vulnerabilities soon after disclosure of a new CVE, but until users update their software, the vulnerability remains exploitable.

Harden systems

System hardening doesn’t prevent vulnerabilities, but it can make them harder to exploit in some cases. Examples of hardening steps include:

• Configuring file systems to operate in read-only mode.
• Implementing network segmentation to isolate resources from each other.
• Applying the principle of least privilege when configuring access permissions for users and containers.

Aqua CNAPP: Leading platform for container security

As the pioneer and recognized leader in container security, Aqua provides complete end-to-end protection for your container workloads, regardless of where they are deployed. We help you shift left to comprehensively scan your container images, empowering your developers to fix risks early-on, when it costs less. With key acceptance gates set up in the CI/CD pipeline, you can reduce the attack surface before deployment by allowing only authorized images to run. In addition, you can ensure real-time protection of your container workloads in production, prevent drift, detect malware and stop known and sophisticated zero-day attacks as they happen.