CN118246021A

CN118246021A - Method, device, equipment and storage medium for defending container escape attack

Info

Publication number: CN118246021A
Application number: CN202410279270.4A
Authority: CN
Inventors: 宋振宇; 林雨晴; 贾晓启; 张伟娟; 郭璇; 刘歌; 张正
Original assignee: Institute of Information Engineering of CAS
Current assignee: Institute of Information Engineering of CAS
Priority date: 2024-03-12
Filing date: 2024-03-12
Publication date: 2024-06-25

Abstract

The invention discloses a defending method, a defending device, defending equipment and a storage medium aiming at container escape attacks, and belongs to the technical field of computer network security. The method aims at the right-lifting attack model, blocks a specific kernel function used in a process of attacking by utilizing the right-lifting loophole in the container, automatically intercepts the right-lifting behavior of the container process, and prevents the container from escaping.

Description

Method, device, equipment and storage medium for defending container escape attack

Technical Field

The present invention relates to the field of computer network security, and in particular, to a method, an apparatus, a device, and a storage medium for defending container escape attacks.

Background

Virtualization technology is a technology that manages and reassigns mirrored resources of computer hardware by means of software. The hardware resources such as CPU, memory, hard disk and the like on one physical machine are abstracted into a group of virtual resources, so that a plurality of operating systems are operated on one physical machine, and each operating system independently has own hardware resources. Conventional virtualization architectures typically include a hypervisor for managing various resources of physical machines to support virtual machine operations thereon, each having an independent kernel. Because each virtual machine has an independent client operating system, the mirror image of the virtual machine is usually between a plurality of G and even tens of G, the occupied storage space is relatively large, and the distribution granularity of resources is too thick, so that a certain resource waste is caused.

The container technology is an operating system level virtualization technology for constructing an independent running environment for a process by utilizing kernel characteristics, does not need to virtualize hardware, directly uses hardware resources of a host machine, and all containers on the host machine share the same kernel. Thus, compared to traditional virtualization techniques, the size of the container is typically only tens to hundreds of MB, enabling smaller and more flexible operating environments to be created, with less impact on system performance, while also being lighter weight. The existing experiments show that the container technology is better in performance aspects such as memory throughput, CPU utilization rate, disk throughput and the like compared with the traditional virtualization technology. However, the container is used as a virtualization technology at the operating system level, has no independent resource configuration and does not perform resource isolation at the system kernel level, and all containers share the same kernel, so that there is a potential risk of incomplete resource isolation and resource limitation.

As cloud protogenesis, devOps, CI/CD, etc. become more popular and popular, container cloud technology is also becoming more and more widely used. Many cloud service providers have begun to offer container-based cloud services to meet their growing demands, such as Google container engine (Google GKE), amazon elastic container service (Amazon ECS), and Azure container service (Azure ACS). Among the numerous container technologies, docker is one of the container technologies currently in wide use. The use of Docker and Kubernetes mentioned in Flexera, 2022, cloud computing report is still considerable. Docker and Kubernetes are still in the list of container tools, with each container tool having over 40% of interviewee usage.

The escape of the container means that an attacker escapes from the container by utilizing the loopholes or weaknesses in the environment of the container and acquires the access rights to the host, so that the escaped rights are utilized to attack other containers or data on the host, and serious security risks are caused. A plurality of containers on the same host share a Linux kernel, the containers can directly obtain Root rights of the host, and can directly communicate with the host kernel, once users in the containers are lifted from common rights to Root rights, or the containers are started to enter a host system with Root identities due to improper configuration, the right-lifting attack is caused, and the operation safety of the host or other containers is affected. For example, the CVE-2019-5736 vulnerability is to cover runC binary files on a host computer by using a malicious container, so that an attacker obtains Root rights.

Since privilege escalation vulnerabilities can completely disable the container protection mechanism and all containers on one host share the same Linux kernel, the isolation of the container will fail if the kernel is compromised. Thus, the container mechanism is not secure due to the nature of kernel sharing. To prevent the container from escaping, some background techniques may be employed to enhance the safety of the container environment. One such defense approach is to use security features of the container runtime, such as Namespace and Cgroups of Linux. These features can help isolate the container from the host and other container resources and limit the access rights of the container to the host; another defense approach is to use container security solutions such as container security monitoring tools, vulnerability scanning tools, and security reinforcement tools. These tools can help discover security vulnerabilities and weaknesses in the container environment and repair them in time, thereby reducing the risk of the container escaping. However, these methods have a certain limitation in practical application, and cannot effectively cope with advanced threats such as right-raising attacks. Meanwhile, a specific kernel function related in the right-raising attack model becomes a key link of attack and needs to be defended in a targeted manner.

Disclosure of Invention

In order to effectively cope with advanced threats such as right-raising attacks, reduce security risks facing the system and improve the overall security and stability of the system, the invention provides a defending method, a defending device, defending equipment and a storage medium aiming at container escape attacks by adopting the idea of blocking a specific kernel function of the container process, wherein the attack is carried out by utilizing the right-raising loopholes.

In order to achieve the above object, the present invention provides the following.

A method of defending against container escape attacks, the method comprising:

Before a caller process attempts to modify the kernel data structure real_cred and the kernel data structure cred, judging whether the caller process is in a container or on a control host;

If the caller process is in the container, detecting whether the operation of calling the kernel static function commit_ creds () from the interior of the container is a right upgrading operation, and generating an instruction for stopping modifying the kernel data structure real_cred and the kernel data structure cred under the condition that the operation of calling the kernel static function commit_ creds () from the interior of the container is a right upgrading operation, so that the caller process cannot modify the kernel data structure real_cred and the kernel data structure cred;

if the caller process is on the control host, the process continues to run the original function flow.

Further, the determining whether the caller process is in the container or on the control host includes:

Acquiring a value of nsproxy fields in a caller process;

Acquiring the value of an init_ nsproxy field on a process on a Linux control host;

Comparing the value of the nsproxy field with the value of the init_ nsproxy field;

if the value of the nsproxy field is equal to the value of the init_ nsproxy field, the caller process is on a control host;

if the value of the nsproxy field is not equal to the value of the init_ nsproxy field, the caller process is within the container.

Further, the detecting whether the operation of calling the kernel static function commit_ creds () from the inside of the container is a rights upgrade operation includes:

comparing the data in the coded data structure pointed by the input parameter of the operation of calling the kernel static function commit_ creds () from the interior of the container with the data in the kernel data structure real_coded in the current process; wherein, the data in the coded data structure pointed by the input parameter of the operation of calling the kernel static function commit_ creds () from the container or the data in the kernel data structure real_coded in the current process includes: a parameter uid, a parameter gid, and a parameter cap_ bset;

If the parameter uid or parameter gid corresponding to the operation of calling the kernel static function commit_ creds () from the interior of the container is smaller, or the parameter cap_ bset corresponding to the operation of calling the kernel static function commit_ creds () from the interior of the container is larger, determining that the operation of calling the kernel static function commit_ creds () from the interior of the container is an authority upgrading operation;

If the argument uid and the argument gid corresponding to the operation of calling the kernel static function commit_ creds () from the inside of the container are larger and the argument cap_ bset corresponding to the operation of calling the kernel static function commit_ creds () from the inside of the container is smaller, it is determined that the operation of calling the kernel static function commit_ creds () from the inside of the container is not a right upgrade operation.

Further, the method further comprises:

In the case that the operation of calling the kernel static function commit_ creds () from the inside of the container is not the authority upgrade operation, the process continues to run the original function flow.

A defensive apparatus against container escape attacks, the apparatus comprising:

The kernel reinforcement module is used for adding a process check program into the original commit_ creds () function based on the hook function;

The process checking module is used for enabling the caller process to be incapable of modifying the kernel data structure real_cred and the kernel data structure cred based on the process checking program under the condition that a certain condition is met; wherein under the condition that a certain condition is met, the process checking program is used for enabling the caller process to not modify the kernel data structure real_cred and the kernel data structure cred, and the method comprises the following steps:

Before a caller process invokes the kernel data structure real_cred and the kernel data structure cred, judging whether the caller process is in a container or on a control host;

Further, the process checking module is further configured to:

Acquiring a value of nsproxy fields in a caller process;

Further, the process checking module is further configured to:

Comparing the data in the coded data structure pointed by the input parameter of the operation of calling the kernel static function commit_ creds () from the interior of the container with the data in the kernel function real_coded in the current process; wherein, the data in the coded data structure pointed by the input parameter of the operation of calling the kernel static function commit_ creds () from the container or the data in the kernel data structure real_coded in the current process includes: a parameter uid, a parameter gid, and a parameter cap_ bset;

Further, the process checking module is further configured to:

An electronic device, the electronic device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the defense method against container escape attacks of any one of the above.

A computer readable storage medium, wherein computer program instructions are stored on the computer readable storage medium, which when executed by a processor implement the method of defending against container escape attacks of any of the above.

The beneficial effects of the invention are as follows:

1) Blocking the key function, and ensuring a simple and clear thought;

2) The original code is changed less, the stability and the performance of the system are not obviously affected, and the added code quantity is less, so that the implementation and the maintenance are easy;

3) The method can automatically intercept the right-raising behavior of the container process and effectively prevent most containers from escaping attacks.

Drawings

Fig. 1 is a diagram of a kernel-based challenge model.

Fig. 2 is a schematic diagram of the blocking attack process.

FIG. 3 is a flow chart of the process execution check of the present invention.

FIG. 4 is a schematic diagram of a credential data structure in a process fabric.

Figure 5 is a flow chart of the system of the present invention.

FIG. 6 is a graph of test results.

Detailed Description

In order to better understand the technical solution in the embodiments of the present invention and make the objects, features and advantages of the present invention more obvious and understandable, the technical core in the present invention is further described in detail below with reference to the accompanying drawings and the embodiments.

Programs in the container platform have similar hierarchical structures with programs in the general-purpose operating system, and programs in different hierarchies can cause different influence ranges when being attacked. Taking application software as an example, attacks against them will usually only affect the application itself, with a small impact range. In contrast, the leakage impact of the Linux kernel is greatest, as it can cause other co-resident containers to be compromised as well. Attacks on server programs (e.g., apache, nginx) and libraries (e.g., glibc, libgig) have a moderate impact and may cause problems for all applications that rely on them. Based on the consequences of the attack, we can divide vulnerabilities into four categories: sensitive information leakage, remote control, denial of service, and kernel override. The kernel privilege is the most serious attack result, because an attacker obtains Root privileges through the kernel privilege.

The CPU protection mechanism may typically bypass from inside the container. And the authority upgrading attack mainly utilizes kernel loopholes such as Use-After-Free, race Condition, improper Verification, buffer Overflow and the like to cover certain kernel function pointers so as to obtain Root authorities. However, the interaction between the kernel security mechanism and the container isolation mechanism results in a short plate effect, impairing the protection capability. The attack flow is generally to cover some function pointers through kernel vulnerabilities (such as UAF, race Condition, improper Verification, buffer Overflow, etc.), and further cover specific kernel data structures to obtain Root rights. An attacker can successfully launch an attack from the inside of the container by using default configuration, the attacker obtains Root rights due to privilege upgrading holes, and the container protection mechanism can be completely disabled after the Root rights are obtained, so that the protection measures are invalid. Therefore, the kernel security mechanism Capability, seccomp, MAC plays a more important role in preventing the authority from upgrading than the container isolation mechanism NAMESPACE, CGROUPS.

Exploitation of this vulnerability is typically accomplished using two methods, namely memory modification and file modification. "memory modification" refers to an attacker either changing the control flow by overlaying some data structure in memory, or by modifying the stack memory to execute a malicious privileged binary file. "File modification" refers to an attacker modifying a privileged file (e.g., "/etc/passwd", "/etc/crontab") to alter the password of a Root, or modifying a file attribute of control rights (e.g., ACL xattr) to execute a malicious program with Root rights. For example, an attacker first links a malicious object symbol to a privilege directory, or injects a malicious command into a component in the privilege context, and then implements privilege escalation by executing setuid (0) in the privilege context or directory. The flow of the challenge attack is shown in figure 1.

First, the kernel virtual base address is obtained by bypassing or manually disabling KASLR mechanisms, and the offset of the kernel base address of a key kernel static function (such as active_write_cr4 (), commit_ creds (), and preparation_kernel_cred ()) in the kernel is constant, so that the target function address can be calculated.

Then, using loopholes UAF, race condition, inproper verification, buffer overflow, etc. of the kernel, pointers of kernel functions which are easy to trigger to execute are covered. For example, the vulnerability to EDB-ID 41994 exploits the inproper verification vulnerability of the setsockopt () system call (i.e., CVE-20177308), and a timer timeout triggers the "retir _blk_timer- > func" pointer whenever a user attempts to send a packet using a packet socket. During normal packet socket operation retire _blk_timer- > func points to the prb_ retire _rx_blk_timer_expided (), the attacker replaces the content of the "retir _blk_timer- > func" pointer with the address of the active_write_cr4 (), and when the received packet is too slow, the function handled by the "retir _blk_timer- > func", i.e. the replaced active_write_cr4 ().

The SMAP mechanism may be disabled next by using either a replaced critical kernel static function (e.g., native_write_cr4 ()) or by using the kernel address of the gadget of the ROP chain. After setting the 20 th position in the CR4 register to 0, the attacker can execute the code in the user mode. Typically, CR4 will be set using 0x6f0 (011011110000 b) so that both SMAP and SMEP are turned off.

When SMEP & SMAP is disabled, the user space functions or shell code may be executed in the managed mode. At this time, the attacker may repeat the second step, rewrite the pointer of the kernel function to point to the malicious user space function or shellcode, and call the kernel function commit_ creds (preparation_kernel_coded (0)) to apply for Root rights.

Considering that overlaying a particular kernel function pointer is implemented through Linux kernel holes and it is almost impossible to completely patch all of Linux kernel holes, overlaying some kernel function pointers can easily disable SMEP & SMAP etc. protection mechanisms, disabling commit_ creds () to prevent an attacker from taking his right as shown in fig. 2 is a relatively simple and efficient way.

Based on the discussion above, it can be demonstrated that restricting the invocation of kernel function commit creds () can prevent most of the right-of-way attacks. Thus modifying the implementation of the commit_ creds () function and enforcing a check before updating the real_cred and cred of the caller process, as shown in fig. 3, can effectively defend against container escape attacks.

Specifically, it is first checked whether the caller process (task_struct) is within a container or on a control host. the task_struct contains a nsproxy field to store Namespace information (e.g., NAMESPACE ID) for the process. A process on the Linux control host (e.g., init process) is also associated with a nsproxy field whose value is fixed, i.e., init_ nsproxy. Thus, it can be determined whether a process is in the container by comparing whether nsproxy of the process is equal to init_ nsproxy.

If a process calls commit_ creds (), from within the container, it is further checked whether there is a rights upgrade operation for that process, and if so, the modification of the data structures real_cred and cred in the kernel representing the process credentials (credentials) is stopped. The in-process credential structure is shown in fig. 4.

Whether it is a rights upgrade operation is determined by comparing the input parameter (a pointer to the structure of the coded) of the commit_ creds () method with the real_coded data structure of the current process. If the uid/gid in the input parameter cred structure is smaller or cap_ bset in the input parameter is larger, it is determined that the rights upgrade operation is performed, and the modification of real_cred and cred is stopped.

Corresponding to the above method, the present invention provides an LKM module that modifies code and a process check module that blocks container right-lifting attacks. And a kernel reinforcement module: the hook function is used for changing the original commit_ creds () function, and a process checking program is added. And a process checking module: the task_struct of the caller process is checked to determine if it is a host/container.

As shown in fig. 4, which is a system flow chart designed based on the method, the kernel reinforcement module registers the kernel module in the form of LKM, modifies the commit_ creds () program with a hook function, and adds a check program before updating the current process creds.

As shown in table 1, the experimental equipment configuration was verified.

Table 1 experimental setup configuration

As shown in fig. 5, a result test chart using an example of the present method is shown. After the commit_ creds () function is modified, the CVE-2017-7308 upgrade vulnerability analyzed before is found, root rights can be obtained from the inside of the container before modification, and upgrade cannot be realized after modification, so that the effectiveness of the scheme is proved.

Although the specific details, algorithms for implementation, and figures of the present invention have been disclosed for illustrative purposes to aid in understanding the contents of the present invention and the implementation thereof, it will be appreciated by those skilled in the art that: various alternatives, variations and modifications are possible without departing from the spirit and scope of the invention and the appended claims. The invention should not be limited to the preferred embodiments of the present description and the disclosure of the drawings, but the scope of the invention is defined by the claims.

Claims

1. A method of defending against container escape attacks, the method comprising:

2. The method of claim 1, wherein determining whether the caller process is within a container or on a control host comprises:

Acquiring a value of nsproxy fields in a caller process;

3. The method of claim 1, wherein the detecting whether the operation of calling the kernel static function commit_ creds () from the inside of the container is a rights upgrade operation comprises:

4. A method according to any one of claims 1 to 3, further comprising:

5. A defensive apparatus against container escape attacks, the apparatus comprising:

6. The apparatus of claim 5, wherein the process check module is further to:

Acquiring a value of nsproxy fields in a caller process;

7. The apparatus of claim 5, wherein the process check module is further to:

8. The apparatus of claim 5, wherein the process check module is further to:

9. An electronic device, the electronic device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements a defense method against container escape attacks as claimed in any one of claims 1-4.

10.A computer-readable storage medium, having stored thereon computer program instructions that, when executed by a processor, implement the defense method against container escape attacks according to any one of claims 1-4.