Methods, systems, and computer-readable storage media for detecting privilege escalation vulnerabilities

By configuring the target function and using a whitelist to determine privilege escalation, the problem of complex SELinux configuration is solved, and a lightweight and convenient privilege escalation vulnerability detection method is implemented, which is applicable to the Linux operating system.

CN113868626BActive Publication Date: 2025-12-02HANGZHOU MORESEC TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202111153626.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-09-29
Publication Date
2025-12-02
Estimated Expiration
2041-09-29

AI Technical Summary

Technical Problem

The high barrier to entry and complex configuration of existing technologies make it difficult to effectively detect privilege escalation vulnerabilities in the Linux operating system.

Method used

By configuring target functions, such as permission modification functions or system call functions, and using entry and exit probe functions to obtain process permission data, and combining this with a whitelist to determine whether permissions have been illegally elevated, lightweight, universal, and convenient vulnerability detection can be achieved.

Benefits of technology

It achieves lightweight, hot-swappable detection of privilege escalation vulnerabilities, reducing system overhead and improving the versatility and convenience of detection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113868626B_ABST
    Figure CN113868626B_ABST
Patent Text Reader

Abstract

This invention discloses a method, system, and computer-readable storage medium for detecting privilege escalation vulnerabilities. The method includes the following steps: configuring at least one target function, which is a permission modification function or a system call function; after the target function is executed, determining whether the privilege data of the process calling the target function has been illegally escalated, specifically including the following steps: before the target function is executed, obtaining the process's privilege data to obtain a first privilege set; after the target function is executed, obtaining the process's privilege data to obtain a second privilege set; obtaining a preset whitelist; based on the first privilege set, the second privilege set, and the preset whitelist, determining whether the process's privilege data has been illegally escalated, and obtaining the corresponding detection result. This invention determines whether there is privilege escalation permission through a whitelist, and determines whether privilege escalation has occurred through the first and second privilege sets, effectively detecting processes with illegal privilege escalation, and has universality and convenience.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of kernel vulnerability detection, and more particularly to a technique for detecting privilege escalation vulnerabilities. Background Technology

[0002] Linux, short for GNU / Linux, is a free and open-source UNIX-like operating system and is currently the most widely used server operating system.

[0003] Privilege escalation vulnerabilities refer to privilege escalation caused by kernel-level overflows in Linux, that is, escalating from ordinary user privileges to privileged root user privileges.

[0004] SELinux is now commonly used to detect privilege escalation vulnerabilities.

[0005] Security-Enhanced Linux (SELinux) is a general-purpose Linux distribution.

[0006] SELinux was primarily developed by the U.S. National Security Agency. Linux kernel versions 2.6 and above have integrated the SELinux module. However, due to the complexity of SELinux's structure and configuration, as well as the large number of conceptual elements, it has a high learning curve. Nowadays, most Linux system administrators often disable SELinux because of the difficulty in using it. Summary of the Invention

[0007] This invention addresses the shortcomings of existing technologies such as the high barrier to entry and complex configuration of SELinux by providing a universal and convenient technique for detecting privilege escalation vulnerabilities.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0009] A method for detecting privilege escalation vulnerabilities includes the following steps:

[0010] Configure at least one target function, which can be a permission modification function or a system call function;

[0011] The permission modification function is a function used in the Linux system at the kernel state to update the permissions of the current process, namely commit_creds;

[0012] System call functions are called syscalls. The number of syscalls varies depending on the kernel version. In practice, the total number of syscalls in the system can be obtained through the NR_syscalls macro. Syscalls are usually sequentially numbered and have unique codes, so knowing the total number of syscalls allows you to know the number of each syscall.

[0013] In practical use, those skilled in the art can choose the permission modification function as the target function and / or specify at least one system call function as the target function according to actual needs.

[0014] After the target function is executed, it is determined whether the privilege data of the process that called the target function has been illegally elevated, specifically including the following steps:

[0015] Before the objective function is executed, the permission data of the process is obtained to obtain a first permission set;

[0016] After the objective function is executed, the permission data of the process is obtained to obtain the second permission set;

[0017] Obtain a preset whitelist. When the target function is a system call function, the whitelist is the system call whitelist. When the target function is a permission modification function, the whitelist is the path whitelist.

[0018] It also obtains data to be matched and uses it to match the whitelist. When the match fails, it means that the current process does not have permission to modify it. Those skilled in the art can determine the data to be matched based on the set whitelist. In this application, when the whitelist is a system call whitelist, the data to be matched is the identifier (syscall number) of the system call function. When the whitelist is a path whitelist, the data to be matched is the full path of the corresponding executable file.

[0019] Based on the first permission set, the second permission set, and the preset whitelist, it is determined whether the permission data of the process has been illegally elevated, and the corresponding detection results are obtained.

[0020] The whitelist used in existing privilege vulnerability detection technologies is often a list of privileges corresponding to the system. During system calls or process execution, the current privileges are obtained and then compared with the pre-configured privilege list. If they are inconsistent, it is determined to be malicious privilege escalation.

[0021] However, since different kernel versions have different permission management rules, based on the existing detection schemes mentioned above, a detailed permission list needs to be configured as a whitelist for each system according to the requirements of each kernel version. This lacks universality and convenience. Furthermore, to ensure the accuracy of detection, permission checks need to be performed on each kernel function, which is costly.

[0022] The whitelist used in this application is used to exclude processes that have legitimate privilege escalation. For example, the list of syscalls used to modify process permissions in the Linux system is used as the system call whitelist, and the list of privileged paths is used as the path whitelist. It is universal and easy to configure.

[0023] As one possible implementation, when the target function is a system call function, the step of determining whether the process's privilege data has been illegally elevated includes:

[0024] When the target function fails to match the system call whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated.

[0025] As one possible implementation, when the target function is a permission modification function, the step of determining whether the permission data of the process has been illegally elevated includes:

[0026] Obtain the full path of the executable file corresponding to the process;

[0027] When the full path of the executable file fails to match the path whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated.

[0028] As one possible implementation method:

[0029] Configure entry and exit probe functions for each objective function;

[0030] The entry probe function is used to obtain the permission data of the corresponding process before the target function is executed, and to obtain the first permission set of the process;

[0031] The exit probe function is used to obtain the permission data of the corresponding process after the target function is executed, and to obtain the second permission set of the process.

[0032] As one possible implementation method:

[0033] Permission data includes the corresponding process's uid (actual user ID);

[0034] Permission data may also include euid (effective user ID), suid (set user ID), and fsuid (file system user ID).

[0035] In practical use, only the uid is needed to determine whether privileges have been elevated. To further improve accuracy, euid, suid, and fsuid can also be used as privilege data to comprehensively determine whether privileges have been elevated.

[0036] As one possible implementation method, the method for determining whether process privilege data has been elevated is as follows:

[0037] Extract permission update data from the second permission set, wherein the permission update data is data in the second permission set that is inconsistent with the first permission set;

[0038] Determine whether the permission update data is root privileges. If the permission update data is root privileges, it is determined that the process's permission data has been elevated.

[0039] As one possible implementation method:

[0040] If the privilege data of a process is determined to have been illegally elevated, the process shall be terminated.

[0041] This invention also discloses a system for detecting privilege escalation vulnerabilities, comprising:

[0042] The configuration module is used to configure at least one target function, which can be a permission modification function or a system call function.

[0043] The detection module is used to determine whether the privilege data of the process calling the target function has been illegally elevated after the target function is executed. The detection module includes a first detection unit, a second detection unit, an extraction unit, and a judgment unit.

[0044] The first detection unit is used to obtain the permission data of the process and obtain a first permission set before the target function is executed;

[0045] The second detection unit is used to obtain the permission data of the process and obtain a second permission set after the target function is executed;

[0046] The extraction unit is used to obtain a preset whitelist. When the target function is a system call function, the whitelist is a system call whitelist. When the target function is a permission modification function, the whitelist is a path whitelist.

[0047] The judgment unit is used to determine whether the permission data of the process has been illegally elevated based on the first permission set, the second permission set and the preset whitelist, and to obtain the corresponding detection result.

[0048] As one possible implementation method:

[0049] It also includes a blocking module, which is used to terminate the process in which privilege data is illegally elevated.

[0050] The present invention also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0051] This invention, by adopting the above technical solutions, has significant technical effects:

[0052] This invention determines whether the corresponding processes of the first and second permission sets have been privilege escalated, and combines this with a preset whitelist to determine whether the privilege escalation operation is legal, thereby detecting processes that have illegally escalated privileges. This invention provides a lightweight, hot-swappable, low-overhead, and highly versatile Linux operating system kernel vulnerability privilege escalation detection technology. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a flowchart illustrating the vulnerability detection steps in a method for detecting privilege escalation vulnerabilities according to the present invention.

[0055] Figure 2 This is a schematic diagram of the module connections of a privilege escalation vulnerability detection system according to the present invention;

[0056] Figure 3 yes Figure 2 A schematic diagram of the module connection of the detection module 200. Detailed Implementation

[0057] The present invention will be further described in detail below with reference to the embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following embodiments.

[0058] Example 1: A method for detecting privilege escalation vulnerabilities based on system call functions, comprising the following steps:

[0059] S100, Data Configuration:

[0060] S110. Configure the objective function:

[0061] In this embodiment, each system call function (syscall) is used as the target function;

[0062] In practical use, those skilled in the art can configure the syscall as the target function themselves;

[0063] If the syscall to be monitored is used as the target function, and the syscalls with privilege escalation privileges in the target function are added to the system call whitelist, processes that escalate privileges through the target function can be detected and recorded, providing data support for subsequent analysis. It can also automatically block processes that illegally escalate privileges, thereby improving security.

[0064] S120. Configure the entry probe function func_entry and the exit probe function func_exit for the target function:

[0065] The kretprobe is used to hook each target function, and an entry probe function func_entry and an exit probe function func_exit are configured for each target function. The entry probe function runs at the entry point of the corresponding target function, and the exit probe function runs when the corresponding target function ends.

[0066] In this embodiment, both the ingress probe function and the egress probe function are used to obtain the permission data in the cred structure, namely uid, euid, suid, and fsuid.

[0067] The `cred` structure is used to store process permissions.

[0068] Kretprobe is an existing, publicly available kernel debugging technique for tracking the execution status of kernel functions.

[0069] In this embodiment, all syscalls are treated as target functions. Therefore, it is only necessary to obtain the total number of syscalls through the NR_syscalls macro to link all syscalls with Kretprobe.

[0070] S130, Configure whitelist:

[0071] Use the list of syscalls with elevated privileges as a whitelist for system calls;

[0072] Syscalls that can modify uid, euid, suid, and fsuid include:

[0073] execve, setuid, setreuid, setresuid and setfsuid;

[0074] Obtain the syscall number of the above five syscalls in the corresponding system to obtain the system call whitelist;

[0075] S200, vulnerability detection:

[0076] Reference Figure 1After the target function is executed, it is determined whether the privilege data of the process that called the target function has been illegally elevated. This includes the following steps:

[0077] S210. Before the target function is executed, obtain the permission data of the process to obtain the first permission set;

[0078] When a process enters kernel mode through the target function, the entry probe function at the entry point of the target function is triggered. The entry probe function obtains the permission data (uid, euid, suid, fsuid) of the process and obtains the first permission set S1.

[0079] S220. After the objective function is executed, obtain the permission data of the process to obtain the second permission set;

[0080] After the target function is executed, the exit probe function will be triggered. The exit probe function obtains the identifier corresponding to the target function, that is, the syscall number corresponding to the target function, and also obtains the permissions of the process (uid, euid, suid, fsuid), and obtains the first permission set S2.

[0081] S230. Based on the first permission set, the second permission set, and the preset whitelist, determine whether the permission data of the process has been illegally elevated, and obtain the corresponding detection result.

[0082] In this embodiment, the preset whitelist is the system call whitelist, and the data to be matched is the syscall number corresponding to the target function. When the data to be matched is not in the system call whitelist, it is determined that the target function fails to match the system call whitelist.

[0083] When the target function fails to match the system call whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated.

[0084] The fact that the privilege data of the second privilege set was elevated compared to the first privilege set indicates that the privileges of the corresponding process were elevated after the target function was executed. However, the target function failed to match the system call whitelist, indicating that the target function did not have the privilege to be elevated. Therefore, this privilege escalation was an illegal privilege escalation performed through a vulnerability.

[0085] In the actual judgment process, whitelist matching can be performed first. If whitelist matching fails, it can be judged whether privilege escalation has occurred. Alternatively, it can be judged whether privilege escalation has occurred first, and then whether the target function called by the process with privilege escalation is in the whitelist. This embodiment does not impose detailed limitations on these aspects.

[0086] The method for determining whether process privilege data has been elevated is as follows:

[0087] S231. Extract permission update data from the second permission set, wherein the permission update data is data in the second permission set that is inconsistent with the first permission set;

[0088] Taking UID as an example, it is determined whether the UID in the first permission set and the second permission set are the same. If they are the same, it is determined that the UID has not undergone permission elevation. If they are different, the UID in the second permission set is used as the permission update data.

[0089] S232. Determine whether the permission update data is root privileges. If the permission update data is root privileges, determine that the permission data of the process has been elevated.

[0090] Taking UID as an example, when UID is 0, it has root privileges (the highest privileges in the Linux operating system);

[0091] Therefore, it is determined whether the uid is 0. When the uid is 0, it is determined that the privilege data of the process has been elevated.

[0092] S300, Process Blocking:

[0093] When a process is detected to have its privilege data illegally elevated, that is, after determining in step S200 that the privilege data of a process has been illegally elevated, the corresponding process is terminated.

[0094] The specific implementation method is as follows:

[0095] Get the PID of the corresponding process. The PID is a unique identifier for the corresponding process.

[0096] Use the kill_pid function to terminate the corresponding process.

[0097] The detection method disclosed in this embodiment can be compiled into a kernel module for detecting privilege escalation vulnerabilities by kernel code. Hot-plugging is achieved by inserting or removing this kernel module, without recompiling the kernel or restarting the computer.

[0098] Example 2: A method for detecting privilege escalation vulnerabilities based on privilege escalation functions. Compared with Example 1, the privilege escalation function is used as the target function, the whitelist is a path whitelist, and the rest is the same as in Example 1.

[0099] The specific steps are as follows:

[0100] S100, Data Configuration:

[0101] S110. Configure the objective function:

[0102] In this embodiment, the permission modification function (commit_creds function) is used as the target function;

[0103] The `commit_creds` function is a function in the Linux system used in kernel mode to update the permissions of the current process.

[0104] S120. Configure the entry probe function func_entry and the exit probe function func_exit for the target function:

[0105] In this embodiment, the functions of the ingress probe function and the egress probe function are also to obtain the permission data in the cred structure, namely uid, euid, suid, and fsuid.

[0106] S130, Configure whitelist:

[0107] Use the list of privileged paths as a path whitelist. For example, a privileged path might be:

[0108] / bin /

[0109] / sbin /

[0110] / usr / bin /

[0111] / usr / sbin /

[0112] / usr / local / bin /

[0113] / usr / local / sbin / .

[0114] In Linux, only users with root privileges can write to programs in privileged paths. When performing privilege escalation using kernel vulnerabilities, an executable file must first be written to the operating system. Attackers with ordinary user privileges cannot write executable files to these privileged paths.

[0115] S200, vulnerability detection:

[0116] This embodiment uses a path whitelist to determine whether the full path of the executable file of each process that calls the permission modification function is in the privileged path or a subdirectory of the privileged path, thereby determining whether the privilege escalation operation is legal.

[0117] Reference Figure 1 After the target function is executed, it is determined whether the privilege data of the process that called the target function has been illegally elevated. This includes the following steps:

[0118] S210. Before the objective function is executed, obtain the permission data of the process to obtain the first permission set S1;

[0119] When a process calls the target function to modify permissions, the entry probe function at the entry point of the target function is triggered. The entry probe function obtains the permission data (uid, euid, suid, fsuid) of the process and obtains the first permission set S1.

[0120] S220. After the objective function is executed, obtain the permission data of the process to obtain the second permission set;

[0121] After the target function is executed, the exit probe function will be triggered. The exit probe function will obtain the full path of the executable file corresponding to the currently executing program, denoted as exe_path, and also obtain the permissions of the process (uid, euid, suid, fsuid) to obtain the first permission set S2.

[0122] S230. Based on the first permission set, the second permission set, and the preset path whitelist, determine whether the permission data of the process has been illegally elevated, and obtain the corresponding detection result.

[0123] The specific steps are as follows:

[0124] S231. Obtain the full path of the executable file corresponding to the process;

[0125] S232. When the full path of the executable file fails to match the path whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated.

[0126] If the full path of the executable file is in a privileged path or a subdirectory of a privileged path in the path whitelist, it is determined that the full path of the executable file matches the path whitelist successfully; otherwise, it is determined that the match has failed.

[0127] S300, Process Blocking:

[0128] When a process is detected to have its privilege data illegally elevated, that is, after determining in step S200 that the privilege data of a process has been illegally elevated, the corresponding process is terminated.

[0129] The detection method disclosed in this embodiment can also be compiled into a kernel module for detecting privilege escalation vulnerabilities by kernel code, and hot-plugging can be achieved by inserting or removing the kernel module.

[0130] Example 3: A system for detecting privilege escalation vulnerabilities, such as... Figure 2 As shown, it includes:

[0131] Configuration module 100 is used to configure at least one target function, which is a permission modification function or a system call function;

[0132] The detection module 200 is used to determine whether the privilege data of the process calling the target function has been illegally elevated after the target function is executed. The detection module includes a first detection unit 210, a second detection unit 220, an extraction unit 230, and a judgment unit 240.

[0133] The first detection unit 210 is used to obtain the permission data of the process and obtain a first permission set before the target function is executed;

[0134] The second detection unit 220 is used to obtain the permission data of the process and obtain a second permission set after the target function is executed;

[0135] The extraction unit 230 is used to obtain a preset whitelist. When the target function is a system call function, the whitelist is a system call whitelist. When the target function is a permission modification function, the whitelist is a path whitelist.

[0136] The judgment unit 240 is used to determine whether the permission data of the process has been illegally elevated based on the first permission set, the second permission set and the preset whitelist, and to obtain the corresponding detection result.

[0137] Furthermore, it also includes a blocking module 300, which is used to terminate the process in which permission data is illegally elevated.

[0138] This embodiment is a device embodiment corresponding to Embodiment 1 and Embodiment 2. Since it is basically similar to Embodiment 1 and Embodiment 2, the description is relatively simple. For relevant parts, please refer to the description of Embodiment 1 and Embodiment 2.

[0139] Example 4: A computer-readable storage medium storing a computer program, characterized in that, when executed by a processor, the program implements the steps of the method described in Example 1 or Example 2.

[0140] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0141] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0142] This invention is described with reference to flowchart illustrations and / or block diagrams of the method, terminal device (system), and computer program product according to the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0143] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0144] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0145] It should be noted that:

[0146] The phrase "an embodiment" or "an embodiment" used in this specification means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Therefore, the phrase "an embodiment" or "an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0147] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0148] Furthermore, it should be noted that the shapes and names of the parts and components described in the specific embodiments described in this specification may differ. All equivalent or simple variations made to the structure, features, and principles described in this patent concept are included within the protection scope of this patent. Those skilled in the art to which this invention pertains may make various modifications or additions to the described specific embodiments or use similar methods to replace them, as long as they do not depart from the structure of this invention or exceed the scope defined in these claims, they should all fall within the protection scope of this invention.

Claims

1. A method for detecting privilege escalation vulnerabilities, characterized in that, Includes the following steps: Configure at least one target function, which can be a permission modification function or a system call function; After the target function is executed, it is determined whether the privilege data of the process that called the target function has been illegally elevated, specifically including the following steps: Before the objective function is executed, the permission data of the process is obtained to obtain a first permission set; After the objective function is executed, the permission data of the process is obtained to obtain the second permission set; Obtain a preset whitelist. When the target function is a system call function, the whitelist is the system call whitelist. When the target function is a permission modification function, the whitelist is the path whitelist. Based on the first permission set, the second permission set, and the preset whitelist, it is determined whether the permission data of the process has been illegally elevated, and the corresponding detection results are obtained. The steps for determining whether the privilege data of the process has been illegally elevated include: When the target function fails to match the system call whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated. Configure entry and exit probe functions for each objective function; The entry probe function is used to obtain the permission data of the corresponding process before the target function is executed, and to obtain the first permission set of the process; The exit probe function is used to obtain the permission data of the corresponding process after the target function is executed, and to obtain the second permission set of the process; The process enters kernel mode through the target function, and the Kretprobe technique is used to track the execution status of the kernel function; The step of determining whether the privilege data of the process has been illegally elevated also includes: Obtain the full path of the executable file corresponding to the process; When the full path of the executable file fails to match the path whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated. If the full path of the executable file is in a privileged path or a subdirectory of a privileged path in the path whitelist, it is determined that the full path of the executable file matches the path whitelist successfully.

2. The method for detecting privilege escalation vulnerabilities according to claim 1, characterized in that: Permission data includes the UID of the corresponding process.

3. The method for detecting privilege escalation vulnerabilities according to claim 2, characterized in that, The method for determining whether process privilege data has been elevated is as follows: Extract permission update data from the second permission set, wherein the permission update data is data in the second permission set that is inconsistent with the first permission set; Determine whether the permission update data is root privileges. If the permission update data is root privileges, it is determined that the process's permission data has been elevated.

4. The method for detecting privilege escalation vulnerabilities according to claim 1, characterized in that: If the privilege data of a process is determined to have been illegally elevated, the process shall be terminated.

5. A system for detecting privilege escalation vulnerabilities, characterized in that... include: The configuration module is used to configure at least one target function, which can be a permission modification function or a system call function. The detection module is used to determine whether the privilege data of the process calling the target function has been illegally elevated after the target function is executed. The detection module includes a first detection unit, a second detection unit, an extraction unit, and a judgment unit. The first detection unit is used to obtain the permission data of the process and obtain a first permission set before the target function is executed; The second detection unit is used to obtain the permission data of the process and obtain a second permission set after the target function is executed; An extraction unit is used to obtain a preset whitelist. When the target function is a system call function, the whitelist is a system call whitelist; when the target function is a permission modification function, the whitelist is a path whitelist. The judgment unit is used to determine whether the permission data of the process has been illegally elevated based on the first permission set, the second permission set and the preset whitelist, and to obtain the corresponding detection result; The steps for determining whether the privilege data of the process has been illegally elevated include: When the target function fails to match the system call whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated. Configure entry and exit probe functions for each objective function; The entry probe function is used to obtain the permission data of the corresponding process before the target function is executed, and to obtain the first permission set of the process; The exit probe function is used to obtain the permission data of the corresponding process after the target function is executed, and to obtain the second permission set of the process; The process enters kernel mode through the target function, and the Kretprobe technique is used to track the execution status of the kernel function; The step of determining whether the privilege data of the process has been illegally elevated also includes: Obtain the full path of the executable file corresponding to the process; When the full path of the executable file fails to match the path whitelist, and the permission data of the second permission set is elevated compared to the first permission set, it is determined that the permission data of the process has been illegally elevated. If the full path of the executable file is in a privileged path or a subdirectory of a privileged path in the path whitelist, it is determined that the full path of the executable file matches the path whitelist successfully.

6. The system for detecting privilege escalation vulnerabilities according to claim 5, characterized in that... include: It also includes a blocking module, which is used to terminate the process in which privilege data is illegally elevated.

7. A computer-readable storage medium storing a computer program, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1 to 4.

Citation Information

Patent Citations

  • Kernel security detection method, apparatus and equipment, and storage medium

    CN111259386A

  • Information determination method, function calling method and electronic equipment

    CN111523115A