{"id":24865,"date":"2023-06-23T15:30:00","date_gmt":"2023-06-23T15:30:00","guid":{"rendered":"https:\/\/nsfocusglobal.com\/?p=24865"},"modified":"2026-04-17T18:07:40","modified_gmt":"2026-04-17T18:07:40","slug":"an-insight-into-rsa-2023-capabilities-utilization-for-container-escape","status":"publish","type":"post","link":"https:\/\/nsfocusglobal.com\/pt-br\/an-insight-into-rsa-2023-capabilities-utilization-for-container-escape\/","title":{"rendered":"An Insight into RSA 2023: Capabilities Utilization for Container Escape"},"content":{"rendered":"\n

At the RSA Conference this year, researchers from Cyberason shared the topic of Container Escape: All You Need Is Cap (Capabilities), detailing three methods of using Cap permissions for container escape, hoping to make users pay attention to the permission allocation of Capabilities when using containers and maintain best practices. This article will provide a detailed introduction to the technical principles of Capabilities Utilization for container Escape, one of the security risks and threats of containerized infrastructure.<\/a><\/p>\n\n\n\n

I. Capabilities Utilization<\/h1>\n\n\n\n

Introduction to Capabilities<\/h3>\n\n\n\n

The Capabilities mechanism was introduced after version 2.2 of the Linux kernel. It is designed to divide and control the root permissions in a more granular way and achieve on-demand authorization. Common Capabilities information can be found on the Linux manual page [1], with some examples shown in Figure 1:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 1 Capabilities Permissions and System Calls<\/p>\n\n\n\n

Most Capabilities have atomic capabilities with a limited number of system calls, but there are also some Capabilities with excessively high permissions, such as CAP_ SYS_ ADMIN:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 2 CAP_ SYS_ ADMIN Details<\/p>\n\n\n\n

As shown in Figure 2, the official information also indicates the risk of permission “overload”, which was analyzed by researchers as early as the article “CAP_SYS_ADMIN: the new root” [2].<\/sup> CAP_ SYS_ ADMIN not only allows the execution of system calls such as mount, umount, and quotacrl, but also includes permissions for other Capabilities, such as CAP_ PERFMON, CAP_ BPF and CAP_ RESTORE_ CHECKPOINT et al.<\/p>\n\n\n\n

Capabilities<\/strong> Discover<\/strong>y<\/h3>\n\n\n\n

By default, the Docker container has the Capabilities shown in Figure 3:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 3: Default Capabilities in Docker V20.10.7<\/p>\n\n\n\n

You can also proactively assign specified Capabilities when starting a container based on business needs, in the following ways:<\/p>\n\n\n\n

1) Add specified Capability:<\/p>\n\n\n\n

docker run — cap add=- it<\/p>\n\n\n\n

2) Add all Capabilities:<\/p>\n\n\n\n

docker run — cap add=ALL – it<\/p>\n\n\n\n

3) Delete specified Capability:<\/p>\n\n\n\n

Docker run — cap drop=- it<\/p>\n\n\n\n

4) Delete all Capabilities:<\/p>\n\n\n\n

Docker run — cap drop=ALL – it<\/p>\n\n\n\n

In Kubernetes, it can be configured through the securityContext field:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 4 SecurityContext Configuration in Kubernetes<\/p>\n\n\n\n

In actual container environment attack and defense scenarios, this permission can be viewed through the cat\/proc\/1\/status command, as shown in Figure 5:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 5 Capabilities Discovery<\/p>\n\n\n\n

The values of Capabilities are displayed in the form of BITMASK. For ease of viewing, it is necessary to use the capsh –decode=CAP BITMASK command (most container environments do not have the capsh tool installed) for decoding, as shown in Figure 6:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 6 CAP BITMASK Decoding<\/p>\n\n\n\n

Utilizing CAP_SYS_ Module for Container Escape<\/strong><\/h3>\n\n\n\n

The CAP_ SYS_ MODULE permission allows for the installation and uninstallation of kernel modules, as shown in Figure 7:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 7 Details of CAP_ SYS_ MODULE<\/p>\n\n\n\n

When the container is granted this permission, attackers can install custom modules inside the container. One way is to upload compiled kernel modules, but due to differences between kernel versions, pre-compiled modules may not be universal, but they can be compiled by simulating and targeting the same environment locally; Another way is to directly compile in the target container environment, and the specific usage method can be referred to in “Abusing CAP_SYS-MODULE to Cause Container Escape”[3]<\/sup>. The general principle is shown in Figure 8:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 8 Attack process for installing kernel modules<\/p>\n\n\n\n

Utilizing CAP_ SYS_ PTRACE for Container Escape<\/h3>\n\n\n
\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 9 Details of CAP_SYS_PTRACE<\/p>\n\n\n\n

When a container is assigned a CAP_SYS_PTRACE permission, this permission allows for the use of ptrace system calls.<\/p>\n\n\n\n

The ptrace() system call is one of the inter process communication mechanisms provided by Linux systems. Its main function is to allow one process (called a tracer process) to monitor and control another process (called a tracer process). The tracer process can read and write registers and memory of the tracee process, and control the execution of the tracee process, such as single step execution, interrupt execution, etc. The ptrace() system call is typically used to implement debugger tools, such as GDB, for debugging applications, tracking the cause of program crashes, or generating dump files when the application crashes. Ptrace () can also be used to implement Code injection and other advanced debugging techniques. When the container shares the host’s pid namespace, it can escape the container through process injection.<\/p>\n\n\n\n

The following will introduce two methods of using the ptrace() system to call for escape.<\/p>\n\n\n\n

1) Process<\/strong> Debugging<\/strong><\/p>\n\n\n\n

The attack principle of process debugging is shown in Figure 10:<\/p>\n\n\n

\n
\"Red<\/a><\/figure>\n<\/div>\n\n\n

Figure 10 Using Process Debugging for Container Escape<\/p>\n\n\n\n

The prerequisite for the use of this technique:<\/p>\n\n\n\n