What Is Container Escape?

What does container escape mean?

Container escape – also sometimes called Docker escape or container breakout  – is the ability of applications or processes running inside a container to access resources outside of the container that are not supposed to be available to them. Using this technique, threat actors can exfiltrate sensitive data, as well as install malicious software, like cryptominers.

For example, most containers are not configured to have direct access to the file system of the server that hosts them. But if a container gains the ability to read or write data from the host server’s file system, it would be an example of container escape.

The problem with container escape

In most cases, the primary reason for running an application inside a container – as opposed to deploying it directly on a host server – is to allow the app to operate inside a lightweight virtual environment that isolates it from everything else running on the server. This is beneficial from an application performance and stability standpoint because it helps ensure that configurations that are external to the container environment won’t affect application behavior – so no matter how the host server is configured, containers behave in a consistent way.

The separation that containers provide between applications and host environments is also beneficial from a security perspective because it mitigates the risk that a security issue within a container will spill over to affect other applications or the server as a whole. If you were to run applications directly on a server without using containers, an attacker who takes control of an application by exploiting a vulnerability in it could in many cases take control of the entire server, since there is no separation between the application and the server.

But with containers, compromising an app typically only gives attackers access to resources hosted inside the container. Unless the attacker is able to “escape” the container, the harm is limited.

This brings us to why container escape is problematic: In the event that attackers manage to escape containers, the impact of a successful exploit is likely to be much greater. Instead of affecting just one app, attackers who exploit a container escape vulnerability can compromise all apps and resources on a server. They could potentially even spread their attack to other servers, especially if the server they compromise is part of a cluster managed by a single control plane.

How container escape occurs

Most container escape events happen for one of two reasons:

• Insecure settings allow a container to access resources or make system calls that were not intended to be accessible to it. For example, due to a configuration oversight, admins might grant a container special capabilities (like the ability to interact with the host file system) that would not normally be available to it. 
• Attackers exploit a vulnerability in the container runtime or the host server’s operating system that allows them to circumvent the access controls that are supposed to restrict the capabilities available to containers.

Common container escape techniques: Excess container capabilities

We just defined the two main reasons why container escape can occur. To dive deeper into what container escape looks like in practice, let’s examine common container escape techniques and the specific types of attacks they enable.

We’ll look in this section at container escape techniques that rely on configuration oversights. In the next section, we’ll discuss examples of escape techniques that exploit container escape vulnerabilities.

Accessing the host file system with SYS_ADMIN

Containers can access host file systems if they are configured to run with the SYS_ADMIN capability. This capability allows containers to perform a variety of actions through the Linux kernel that would normally be available only to root users on a Linux server.

Typically, containers gain this escape capability because admins grant it explicitly when running the container. If you launch containers from the command line with Docker, you can add this capability using the following flag:

--cap-add=SYS_ADMIN

You can also configure this capability when deploying containers in Kubernetes by adding the CAP_SYS_ADMIN option to the container’s spec.

Injecting malicious processes using SYS_PTRACE

Containers that have the SYS_PTRACE capability enabled, and that also share process namespace with their host server, can write to the memory space of other processes. This effectively means they can execute code outside of their dedicated environments.

This capability becomes available to containers if admins specify the following flag when running a container with Docker:

--cap-add=SYS_PTRACE

In Kubernetes, the capability is available for containers configured with a spec like the following:

securityContext:

capabilities:

add:

- SYS_PTRACE

Inserting kernel modules using SYS_MODULE

Containers that have the SYS_MODULE capability can load modules into the Linux kernel. Modules can modify kernel behavior – which means that by using this technique, attackers can escape containers and take control of the host server.

SYS_MODULE is available to containers that are deployed with the following flag:

--cap-add=SYS_MODULE

Why would containers have escape capabilities?

You might be wondering why an admin would allow a container to run with capabilities that enable container escapes in the first place. There are two main reasons.

One is that, in some cases, admins simply make mistakes. They might be reusing a Kubernetes deployment template that had a certain capability enabled and forget to remove the capability before deploying a new container, for example. Or, an inexperienced admin who is still learning Docker or Kubernetes might copy code from the Internet to run a container, not realizing that it contains certain arguments that grant the container capabilities it should not have. Insecure settings could also be imported into containers if developers pull code from a public repository without inspecting all of it.

The other main reason why this happens is that admins deliberately deploy containers with extra capabilities in order to support specialized use cases, but don’t properly control for the security risks that come with those capabilities. For instance, if you want to allow a container to interact with the Linux kernel using eBPF, a framework that can help with legitimate tasks like performance and security monitoring, you may need to grant the container specific capabilities beyond those available by default. But attackers could seize on those same capabilities to escape a container environment.

Container escape vulnerability examples

To date, a variety of software vulnerabilities have enabled container and Docker escape exploits. Here’s a look at a couple of the most serious ones.

Leaky Vessels

Leaky Vessels is a set of security vulnerabilities involving runC (a container runtime) and parts of the Docker software stack. The vulnerabilities, which were announced in 2024, allow attackers to perform container escape exploits like modifying the host file system. In a severe case, the vulnerability can enable full-scale escape that gives attackers unfettered access to the host system.

To protect against this vulnerability, admins must install patches for the vulnerable software components.

Dirty Pipe

Dirty Pipe is a container escape vulnerability disclosed in 2022 that allows containers to modify external file system resources.

Dirty Pipe exploits flaws in the Linux kernel, rather than a container runtime. To fix the issue, admins need to upgrade to Linux kernel 5.8 or later.

How to prevent and detect container escape

Since there are several potential causes of container escape, organizations must adopt a multi-pronged defense by leveraging a variety of techniques both to prevent container escape from happening in the first place, and to detect instances of container escape when they do occur.

Vulnerability management

Preventing container escape risks that stem from vulnerable software components requires effective vulnerability management. This means that organizations must know which specific container runtimes, build tools, operating systems, and other software components they rely on to deploy containers. They must then track vulnerability databases, identify any vulnerabilities that impact their software, and fix vulnerabilities that affect them.

Container escape vulnerability management can be a bit challenging because there are many different software tools and systems available for running containers today, and most vulnerabilities affect only some of them. For example, a Kubernetes escape vulnerability would be a serious issue for any organization that orchestrates containers using Kubernetes, but not everyone does. Likewise, the Leaky Pipe vulnerability described above is a serious issue for any team that uses an unpatched version of the runC container runtime. But runC is only one of several container runtimes that are in widespread use today.

The bottom line here is tracking news about the latest software vulnerabilities is not enough. You must also have the ability to map vulnerabilities onto your actual software stack. In addition, you need to know whether a given vulnerability is actually exploitable on your systems; many vulnerabilities require certain configurations to be in place, or for attackers to have certain types of access (like physical access), in order for successful attacks to occur.

Adopt least privilege

Least privilege means granting the minimum permissions necessary to support an intended use case or user need. When applied to containers, least privilege ensures that by default, containers have no capabilities beyond the bare minimum. If they require additional capabilities, admins grant those capabilities to individual containers on an as-needed basis.

Adhering to the principle of least privilege can help reduce the risk of accidentally granting containers excess capabilities that enable attack.

Container configuration scanning

What if, despite following the principle of least privilege, you accidentally grant unnecessary permissions to your containers? That’s where container scanning comes in.

Scanning containers and the configurations associated with them helps to detect container escape vulnerabilities. Scanning allows teams to identify risky settings, such as the granting of capabilities that enable container escape.

As with vulnerability management, container scanning is complex because there are many ways to configure containers, and different organizations may use different approaches. For instance, if you run containers in Kubernetes, you can scan the YAML code that governs how your containers operate to look for misconfigurations. But if you run containers from the command line using the Docker CLI, you’d need to audit your deployment commands to detect insecure settings. This means that you must tailor your scanning operations to the types of configurations you deploy.

Scanning should also extend to the operating systems that host containers, since insecure configurations at that layer of the stack could also enable container escape or other security issues.

Runtime monitoring

Runtime monitoring doesn’t prevent container escape, but it can help organizations detect it.

Runtime monitoring involves tracking the behavior of containers in a runtime environment and looking for anomalies that might alert you to a security issue. For example, runtime monitoring tools could detect unusual system calls or file system activity, which might occur in the event that attackers escape a container.

Mitigating container escape risks with Aqua

Aqua Security’s Cloud Workload Protection Platform (CWPP) provides the comprehensive set of capabilities teams need to guard against container escape vulnerabilities and risks. No matter which technology you use to deploy containers or how you configure them, Aqua provides the scanning, runtime protection and vulnerability management features you need to keep your containers safe against escape risks – not to mention a variety of other forms of attack.

See for yourself by scheduling a demo.