A container safety detection method and detection device

Abstract

The present application discloses a container security detection method and detection device, which relates to the field of container security, and includes the following steps: obtaining a target information coexistence table generated by a function pre-hooked by the container process execution system; obtaining the IP address in the rebound shell obtained by analyzing the vDSO content in the system, and determining whether the IP address is a container address; if so, determining that the container corresponding to the IP address has escaped, if not, querying the table according to the preset query conditions to determine the container that has escaped. The present application does not depend on the kernel version, nor does it require recompiling the kernel module. It has a wide compatibility with the system, and can identify containers that are escaping from vDSO, and shut them down, which is stable and efficient, and improves system security.

Description

Technical Field

[0001] The present application relates to the field of container safety, and in particular to a container safety detection method and detection device. Background Art

[0002] In modern Linux architecture, whenever the kernel loads an ELF executable program, it will create a memory area called vDSO mapping in its process address space. vDSO is the abbreviation of virtual dynamic shared object, which means that this mapping actually contains an ELF shared object file, commonly known as .so. The act of using vDSO to escape a process is called vDSO escape, which is a new escape method proposed in recent years. It has a great impact on container security, and there is currently no good detection method. Summary of the invention

[0003] A container security detection method provided in the present application is intended to solve the problem that the prior art cannot stably and efficiently detect vDSO escapes and block containers that generate escape behaviors.

[0004] To achieve the above objectives, this application adopts the following technical solutions:

[0005] A container safety detection method of the present application includes the following steps:

[0006] Obtain the target information and storage table generated by the function pre-hooked by the container process execution system;

[0007] Obtain the IP address in the rebound shell obtained by analyzing the vDSO content in the system, and determine whether the IP address is a container address;

[0008] If yes, it is determined that the container corresponding to the IP address has escaped. If not, the table is queried according to a preset query condition to determine the container that has escaped.

[0009] Preferably, the system pre-hooked functions include an execve function for converting a process into a binary program of a real execution flow and a madvise function for suggesting to the kernel a usage pattern for its user virtual memory starting from a specified address in memory and within a range of a length equal to a string parameter value.

[0010] Preferably, the obtaining of the target information co-storage table generated by the function pre-hooked by the container process execution system comprises:

[0011] The target information generated by the container process calling the execve function or the madvise function is obtained and stored in the execve table or the madvise table, wherein the target information stored in the execve table is the process identifier of the container process calling the execve function and its vDSO first address, and the target information stored in the madvise table is the process identifier of the container process calling the madvise function and the memory first address, memory length, and memory usage mode recommended by the madvise function.

[0012] Preferably, the preset query conditions include: a suggested memory usage pattern, a suggested memory length value, a relationship between a suggested memory first address and a vDSO first address of a container process that calls an execve function, and a relationship between a process identifier of a container process that calls an execve function and a process identifier of a container process that calls a madvise function. Preferably, querying the table according to the preset query conditions to determine a container where an escape occurs includes:

[0013] The execve table and the madvise table are jointly queried according to preset query conditions. If a container process that meets the preset query conditions is detected, the container process is determined to be a process that has escaped, and the container to which the container process belongs is found according to the container process.

[0014] Preferably, querying the table according to a preset query condition to determine the container from which the escape occurred includes:

[0015] The execve table and the madvise table are jointly queried according to preset query conditions. If a container process that meets the preset query conditions is detected, the container process is determined to be a process that has escaped, and the container to which the container process belongs is found according to the container process.

[0016] Preferably, the method further comprises: after the escaped container is determined, shutting down the escaped container through Docker or Kubernetes.

[0017] A detection device for implementing the above container security detection method includes: a main module, a perf_event module and a check_vdso module, wherein:

[0018] The perf_event module is used to send target information generated by the container process calling the execve function or the madvise function to the main module;

[0019] The check_vdso module is used to send the IP address in the rebound shell obtained by analyzing the vDSO content in the system to the main module;

[0020] The main module is used to receive the target information sent by the perf_event module and the IP address sent by the check_vdso module, and determine the container where the escape occurs according to the IP address and the target information.

[0021] An electronic device comprises a memory and a processor, wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement a container safety detection method as described in any one of the above.

[0022] A computer-readable storage medium storing a computer program, wherein the computer program enables a computer to implement a container safety detection method as described in any one of the above when executed.

[0023] The present invention has the following beneficial effects:

[0024] In this application, by recording the information generated by the container process calling the execve function or the madvise function and real-time monitoring of the vDSO content in the system, the occurrence of escape behavior can be discovered in time, and the process and its container that modify the vDSO to generate the escape can be found, and the container can be shut down, thereby improving system security. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0026] Figure 1 is a flow chart of a container safety detection method implemented in an embodiment of the present application;

[0027] Figure 2 This is another flow chart of a container safety detection method implemented in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the accompanying drawings to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0029] The terms "first", "second", etc. in the claims and specification of the present application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way are interchangeable under appropriate circumstances. This is merely a way of distinguishing objects with the same properties in the embodiments of the present application. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, so that a process, method, system, product or apparatus that includes a series of units is not necessarily limited to those units, but may include other units not expressly listed or inherent to these processes, methods, products or apparatus.

[0030] Example

[0031] A detection device for implementing a container security detection method comprises: a main module, a perf_event module and a check_vdso module, wherein:

[0032] The perf_event module is used to send target information generated by the container process calling the execve function or the madvise function to the main module;

[0033] The check_vdso module is used to send the IP address in the rebound shell obtained by analyzing the vDSO content in the system to the main module;

[0034] The main module is used to receive the target information sent by the perf_event module and the IP address sent by the check_vdso module, and determine the container where the escape occurs according to the IP address and the target information.

[0035] According to the embodiments, vDSO is a function provided by the Linux system kernel, which can be simply understood as being stored in a piece of physical memory, but the piece of physical memory is mapped to different logical memory blocks in kernel state and user state, in particular: in kernel state, the position of the memory block remains unchanged each time the machine is restarted; in user state, the vDSO logical memory block of each process is different, but the vDSO content of each process, whether it is a user state process, a kernel state process or a container process, is the same. If the vDSO content of one process changes, the vDSO content of other processes will also change.

[0036] When mapped, the kernel-mode vDSO is specified as writable but not executable, and the user-mode vDSO is specified as readable and executable but not writable. When an attacker has a kernel vulnerability, they often invade the kernel, and then modify the code in the vDSO memory in the kernel. When a user-mode process (a process outside the container) calls a vDSO function, the malicious code modified by the attacker is executed, and the attacker escapes. This is called vDSO escape.

[0037] It is worth mentioning that the Dirtycow vulnerability, which appeared in 2016 and caused great harm, used vDSO escape as its escape method, covering Linux 2.6.22 to Linux 4.2, which is a vulnerability that spans nearly ten years. Therefore, it is important to propose a method that can stably and efficiently detect vDSO escape.

[0038] The purpose of this embodiment is to propose a method for implementing security detection of containers by monitoring the vDSO of the operating system to detect the process of modifying the vDSO. The process is as follows: Figure 1 shown.

[0039] Specifically, obtaining a target information co-location table generated by a function pre-hooked by the container process execution system;

[0040] Obtain the IP address in the rebound shell obtained by analyzing the vDSO content in the system, and determine whether the IP address is a container address;

[0041] If yes, it is determined that the container corresponding to the IP address has escaped. If not, the table is queried according to a preset query condition to determine the container that has escaped.

[0042] The perf_event module hooks the execve function and the madvise function, and sends the relevant information of the container process that calls these two functions to the main module. When the main module receives the information sent by the perf_event module, it will store the container process information in the execve table and the madvise table respectively according to the called function. At the same time, the check_vdso module monitors the vDSO content in the system. When it is found that the latest vDSO content is different from the initial content of vDSO, it is determined that a user-mode process has modified vDSO in an unknown way (such as a vulnerability). At this time, the latest content of vDSO is analyzed to determine the corresponding IP address in its rebound shell, and then the IP address is sent to the main module. After receiving the IP information, the main module analyzes it to see if it corresponds to the IP address of any container. If so, it is determined that the corresponding container has escaped. If not, the execve table and the madvise table are jointly queried according to the preset query conditions to determine the process that has escaped. The vDSO module content is stored in the user-mode process, and when it changes, it is checked in time to find the process that modifies the vDSO (causing the escape) and its container, thereby realizing the detection of vDSO escape with high efficiency and stability. Among them, perf_event is a feature that has been introduced into the kernel since Linux 2.6.x version. It has been used for more than ten years and its stability and compatibility are guaranteed. perf_event is a detection point pre-buried in the kernel.

[0043] Specifically, the system pre-hooked functions include an execve function for converting a process into a binary program of a real execution flow and a madvise function for suggesting to the kernel a usage pattern for its user virtual memory starting from a specified address in memory and within a range of a length equal to a string parameter value.

[0044] In this embodiment, two functions execve and madvise are hooked through perf_event. The execve function is closely related to the life cycle of the process. When a process needs to be transformed into a binary program and actually execute the process, execve needs to be called, and its entry point is sys_execve. The madvise function advises the kernel that its user virtual memory should follow a specific usage mode within the range starting from the address specified by addr and with a length equal to the len parameter value. Its entry point is sys_madvise, and the Dirty COW vulnerability uses this function call to modify the vDSO in the kernel.

[0045] Specifically, the target information generated by the container process calling the execve function or the madvise function is obtained and stored in the execve table or the madvise table, wherein the target information stored in the execve table is the process identifier of the container process that calls the execve function and its vDSO first address, and the target information stored in the madvise table is the process identifier of the container process that calls the madvise function and the memory first address, memory length and memory usage mode recommended by the madvise function.

[0046] In this embodiment, the perf_event module is used to record which processes call sys_execve and which processes call sys_madvise. When a process calls sys_execve, perf_event will receive the information and first detect whether the process is a process in the container. If so, the information content will be sent to the main module (because it is a container escape detection, only the process in the container is concerned, and the process outside the container is ignored); when a process calls sys_madvise, perf_event will also receive the information, and also first detect whether the process is a process in the container. If so, the information content will be sent to the main module.

[0047] When the main module receives information sent by the perf_event module, it performs different processing according to the function called by the container process:

[0048] 1. When a sys_execve event is received, the table name is recorded as execve table, and the information in the table is: (execve_pid, vdso_addr), where execve_pid represents the process identifier of the container process that calls the execve function, and vdso_addr represents the vDSO first address of the container process.

[0049] 2. When the sys_madvise event is received, the table name is recorded as madvise table, and the information in the table is: (madvise_pid, arg_addr, arg_length, arg_advise), where madvise_pid represents the process identifier of the container process that calls the madvise function, arg_addr represents the first address of the memory that needs to be recommended, arg_length represents the length of the memory that needs to be recommended, and arg_advise represents the recommended usage mode.

[0050] Specifically, the initial content of the vDSO in the system is obtained, and the updated content of the vDSO is obtained during the operation of the system and compared with the initial content. When the contents are different, the shellcode in the updated content is analyzed to obtain the IP address in the rebound shell.

[0051] At the beginning of the operation, the check_vdso module obtains the initial content of the vDSO in the system and stores it in the table. During the subsequent operation of the system, the updated content of the vDSO is continuously obtained and compared with the content in the table. Once it is found that the obtained vDSO content is different from the vDSO content initially stored in the table, it means that a container process must have modified the vDSO in an unknown way (by exploiting a vulnerability). At this time, the latest vDSO content read is analyzed and processed:

[0052] Attackers often insert a shellcode at the end of the vDSO area. Shellcode is a piece of code used to exploit software vulnerabilities. Shellcode is a hexadecimal machine code. It is named because it often allows attackers to obtain shells. It is often written in machine language. Usually, after the EIP register overflows, a shellcode machine code that can be executed by the CPU is inserted so that the computer can execute any instructions of the attacker. Generally, shellcode is a rebound shell assembly code. By intercepting the rebound shell assembly code, the corresponding IP address in the rebound shell can be obtained.

[0053] Finally, the information about the changed vDSO and the corresponding IP address in the rebound shell are sent to the main module. When the main module receives the information sent by the check_vdso module, it first checks the IP information to determine whether it corresponds to the IP address of any container. If so, it determines that the container has escaped, which is not the container escape method of the Dirty COW vulnerability.

[0054] Specifically, the execve table and the madvise table are jointly queried according to a preset query condition. If a container process that meets the preset query condition is detected, the container process is determined to be a process that has escaped, and the container to which the container belongs is found according to the container process.

[0055] The preset query conditions include: a recommended memory usage mode, a recommended memory length value, a relationship between a recommended memory first address and a vDSO first address of a container process that calls an execve function, and a relationship between a process identifier of a container process that calls an execve function and a process identifier of a container process that calls a madvise function, as follows:

[0056] 1) arg_advise is equal to 4

[0057] 2)arg_length is equal to 2000

[0058] 3)arg_addr is equal to vdso_addr

[0059] 4) madvise_pid is equal to execve_pid

[0060] Among them, arg_advise is the recommended memory usage mode, arg_length is the recommended memory length value, arg_addr is the recommended memory starting address, madvise_pid is the process identifier of the container process that calls the madvise function, and execve_pid is the process identifier of the container process that calls the execve function.

[0061] By jointly querying the execve table and the madvise table, the process that meets the preset query conditions is detected. The process is the container process that escapes using the Dirty COW vulnerability. Then, the container to which the container process belongs is determined based on the container process. The container to which the container process belongs can be determined based on the process identifier of the container process. This belongs to the prior art and will not be described in detail here.

[0062] Specifically, after the escaped container is identified, the escaped container is shut down through Docker or Kubernetes.

[0063] The complete process of this embodiment is as follows Figure 2 As shown, this embodiment does not depend on the kernel version and does not need to recompile the kernel module. It has wide compatibility with the system and can identify the container that is escaping vDSO and shut it down.

[0064] An electronic device includes a memory and a processor, wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the above-mentioned container safety detection method.

[0065] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the electronic device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0066] A computer-readable storage medium storing a computer program, wherein the computer program enables a computer to implement a container safety detection method as described above when executed.

[0067] Exemplarily, a computer program may be divided into one or more modules / units, one or more modules / units are stored in a memory and executed by a processor, and the I / O interface transmission of data is completed by an input interface and an output interface to complete the present invention. One or more modules / units may be a series of computer program instruction segments that can complete specific functions, and the instruction segments are used to describe the execution process of the computer program in a computer device.

[0068] The computer device may be a computing device such as a desktop computer, a notebook, a PDA, a cloud server, etc. The computer device may include, but is not limited to, a memory and a processor. Those skilled in the art may understand that this embodiment is only an example of a computer device and does not constitute a limitation on the computer device. The computer device may include more or fewer components, or a combination of certain components, or different components. For example, the computer device may also include an input device, a network access device, a bus, etc.

[0069] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0070] The memory can be an internal storage unit of a computer device, such as a hard disk or memory of a computer device. The memory can also be an external storage device of a computer device, such as a plug-in hard disk equipped on a computer device, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Furthermore, the memory can also include both an internal storage unit of a computer device and an external storage device. The memory is used to store computer programs and other programs and data required by the computer device. The memory can also be used to temporarily store data in an output device. The aforementioned storage media include various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories ROM, random access memories RAM, disks or optical disks.

[0071] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A container safety detection method, characterized in that: The following steps are involved: Obtain the target information and storage table generated by the function pre-hooked by the container process execution system; Obtain the IP address in the rebound shell obtained by analyzing the vDSO content in the system, and determine whether the IP address is a container address; If yes, it is determined that the container corresponding to the IP address has escaped; if no, the table is queried according to a preset query condition to determine the container that has escaped; The step of obtaining the target information co-location table generated by the function pre-hooked by the container process execution system includes: The target information generated by the container process calling the execve function or the madvise function is obtained and stored in the execve table or the madvise table, wherein the target information stored in the execve table is the process identifier of the container process calling the execve function and its vDSO first address, and the target information stored in the madvise table is the process identifier of the container process calling the madvise function and the memory first address, memory length, and memory usage mode recommended by the madvise function.

2. A container safety detection method according to claim 1, characterized in that: The system pre-hooked functions include an execve function for converting a process into a binary program of a real execution flow and a madvise function for suggesting to the kernel a usage pattern followed by its user virtual memory within a range starting from a specified address in memory and with a length equal to a string parameter value.

3. A container safety detection method according to claim 1, characterized in that: The analysis of the vDSO content in the system includes: The initial content of the vDSO in the system is obtained, and the updated content of the vDSO is obtained during the operation of the system and compared with the initial content. When the content is different, the shellcode in the updated content is analyzed to obtain the IP address in the rebound shell.

4. A container safety detection method according to claim 2, characterized in that: The preset query conditions include: a recommended memory usage mode, a recommended memory length value, a relationship between a recommended memory first address and a vDSO first address of a container process that calls an execve function, and a relationship between a process identifier of a container process that calls an execve function and a process identifier of a container process that calls a madvise function.

5. A container safety detection method according to claim 2, characterized in that: The querying the table according to the preset query condition to determine the container where the escape occurs includes: The execve table and the madvise table are jointly queried according to preset query conditions. If a container process that meets the preset query conditions is detected, the container process is determined to be a process that has escaped, and the container to which the container process belongs is found according to the container process.

6. A container safety detection method according to claim 1, characterized in that: The method further includes: after the escaped container is determined, shutting down the escaped container through Docker or Kubernetes.

7. A detection device for implementing the container safety detection method according to claim 1, characterized in that: include: The main module, perf_event module and check_vdso module, among which, The perf_event module is used to send target information generated by the container process calling the execve function or the madvise function to the main module; The check_vdso module is used to send the IP address in the rebound shell obtained by analyzing the vDSO content in the system to the main module; The main module is used to receive the target information sent by the perf_event module and the IP address sent by the check_vdso module, and determine the container where the escape occurs according to the IP address and the target information.

8. An electronic device, characterized in that: It comprises a memory and a processor, wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement a container safety detection method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that: The computer program enables a computer to implement a container safety detection method according to any one of claims 1 to 6 when executed.

Images