Method for preventing Usermode Helper privilege lifting attack based on Linux Capability mechanism
Through the defense method based on the Linux Capability mechanism, the problem of usermode helper's power-elevating attack is solved by constructing the function call graph and defining new permission checks, and the effective permission check on usermode helper is realized, which prevents the power-elevating attack and ensures the system Security.
Patent Information
- Application Number
- CN202411278039.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-12
- Publication Date
- 2025-01-03
AI Technical Summary
The existing technology is difficult to effectively prevent the new power-elevated attacks carried out using usermode helper. The attacker overwrites the path of the usermode helper program and uses kernel vulnerabilities to execute malicious programs with high authority, resulting in the power-elevated attack being successful, and the existing defense methods cannot be completely Eliminate kernel vulnerabilities.
Adopt the defense method based on the Linux Capability mechanism, obtain the usermode helper's call function, construct the function call diagram, generate a function call chain, determine the location where permission check is added, and define a new capability in the kernel state, grant usermode helper for permission checking. , ensure trust verification is performed before execution.
It effectively prevents the power-elevation attack using usermode helper, fills the defense gap, is extremely low overhead, does not require additional hardware support, and only a small amount of changes to the Linux kernel code is required to ensure system security.
Smart Images
Figure CN119249406A_ABST
Abstract
Description
Technical Field
[0001] The invention relates to a method for preventing usermode helper privilege escalation attacks based on Linux Capability mechanism, and belongs to the field of system security. Background Art
[0002] In Linux systems, processes usually have two types of permissions: ordinary user permissions and root user permissions. Ordinary users cannot perform operations involving sensitive information, while the root user has the highest permissions and can perform unrestricted operations. If an attacker can illegally elevate permissions, they can further obtain sensitive information and execute arbitrary code, thereby posing a serious threat to the system. Since Linux systems are widely used in critical infrastructure such as Web servers, databases, firewalls, and the Internet of Things (IOT), preventing privilege escalation attacks is crucial to protecting the security of these infrastructures.
[0003] Usermode helpers are a set of binary programs that help the kernel complete specific tasks in user mode, including loading kernel modules, handling USB device events, rebooting the system, etc. Although these programs run in user mode, only the root user can modify them. When a specific event occurs, the kernel will use the highest authority (root) to call the corresponding usermodehelper program to ensure that these programs have the necessary permissions during execution. Therefore, in the normal execution process of usermode helpers, the executor of the program has high permissions, and the program itself also has high permissions, and there is no permission leakage problem.
[0004] Linux capability is a fine-grained permission mechanism that divides root permissions into 41 parts. Each capability represents the ability to access a set of privileged operations. Capability is an attribute of a process. Before performing sensitive operations, the kernel will check whether the process requesting access has the required capability. When granting a process capability, in addition to directly modifying the capability of the current process, you can also grant capability to an executable file. When the file is run, it will automatically obtain the corresponding capability.
[0005] Privilege escalation attacks mainly elevate privileges by exploiting kernel vulnerabilities. Traditional attacks target the privilege data of a process, usually by obtaining kernel code execution privileges through vulnerabilities such as buffer overflow or use-after-free, thereby changing the original control flow of the kernel and tampering with the privilege data to a higher privilege. However, due to the complexity of kernel code, it is unrealistic to completely eliminate kernel vulnerabilities. Therefore, existing defense technologies protect the privilege data of the process. For example, they restrict access to the privilege data of the process and monitor the privilege data to prevent illegal tampering. However, attack and defense methods are constantly evolving. Recently, a new privilege escalation attack method using usermode helper has emerged. It can achieve the effect of executing arbitrary code with high privileges without modifying the privilege data of the current process.
[0006] A new type of privilege escalation attack was analyzed in detail. From the existing attack cases, it was concluded that this attack method actually exploited the normal process of the kernel executing the usermode helper program. Usermode helper is a type of user-mode program that is called by the kernel with the highest privilege when needed to provide support for the kernel. The attacker overwrote the path of the usermode helper program with the path of the malicious program before the kernel executed the usermode helper program through a kernel vulnerability. Therefore, when the kernel executes the user-mode program with high privilege, the program called will no longer be the original usermode helper program of the system, but the malicious program prepared by the attacker in advance. Since the malicious program prepared by the attacker does not originally have high privileges, this leads to the phenomenon of executing untrusted programs with high privileges, and finally enables the attacker to complete the privilege escalation attack. It can be seen that the key to the success of the privilege escalation attack is that the kernel does not check the credibility of the usermode helper program before executing it. Summary of the invention
[0007] The present invention aims to propose a lightweight defense method for privilege escalation attacks to make up for the "blind spots" in current defense methods. This solution first conducts an in-depth analysis of the principles of new privilege escalation attacks, clarifies the core reasons why usermode helpers play a role in privilege escalation attacks, and then proposes a defense method based on the Linux capability mechanism. This method does not require hardware support, has extremely low overhead, high flexibility, and can effectively prevent new privilege escalation attacks.
[0008] A method for preventing Usermode Helper privilege escalation attacks based on Linux Capability mechanism, including:
[0009] Get all usermode helper call functions;
[0010] Construct a call graph based on the calling function;
[0011] Generate a function call chain based on the function call graph, determine the location to add the permission check, and add the permission check;
[0012] Add the definition of a new capability in the kernel header file, and grant the new capability to all usermodehelpers in user mode;
[0013] Before executing any usermode helper, its permissions are checked to determine whether the usermode helper can be called.
[0014] Preferably, the calling function of the usermode helper includes:
[0015] Basic usermode helper calling function;
[0016] Starting from the position where the calling function of the basic usermode helper is used, the calling functions of the remaining usermode helpers are found.
[0017] Preferably, through the function call chain, a function at the final call point to which all calling functions of the usermode helper will eventually be executed is obtained; the location for adding permissions is at the function entry at the final call point and before executing the usermode helper.
[0018] Preferably, all usermode helpers are whitelisted.
[0019] Preferably, adding all usermode helpers to the whitelist includes:
[0020] Extract the specific values of the path parameters of the calling functions of all the usermode helpers, save the specific values and add them to the whitelist.
[0021] Preferably, for the new usermode helper, the new capability is granted in advance before it is enabled.
[0022] A system for preventing Usermode Helper privilege escalation attacks based on Linux Capability mechanism, comprising: a location determination module, a permission adding module and a permission checking module;
[0023] The location determination module is used to obtain all usermode helper call functions; based on the call function constructor call graph; based on the function call graph, a function call chain is generated to determine the location to add permission check, and add permission check;
[0024] The permission adding module is used to add the definition of a new capability in the kernel state header file, and grant the new capability to all usermode helpers in the user state;
[0025] The permission checking module is used to check the permission of any usermode helper before executing it, so as to determine whether the usermode helper can be called.
[0026] Preferably, the system further comprises a system adaptation module, and the system adaptation module is used for granting the new capability to the new usermode helper in advance before the new usermode helper is enabled.
[0027] The beneficial effects of the present invention are as follows:
[0028] The method for defending against privilege escalation attacks provided by the present invention does not require additional hardware support, only requires a small modification of the Linux kernel code, and cleverly utilizes existing capability permissions to effectively block the currently popular new privilege escalation attacks using usermode helpers. The present invention fills the gap in defense against new privilege escalation attacks, and the performance overhead is extremely low and almost negligible. BRIEF DESCRIPTION OF THE DRAWINGS
[0029] Figure 1 It is a flow chart of the present invention.
[0030] Figure 2 Flowchart for permission checking. DETAILED DESCRIPTION
[0031] The following is combined with Figure 1 The present invention is further described in detail. The examples given are only used to explain the present invention but not to limit the scope of the present invention.
[0032] A method for preventing Usermode Helper privilege escalation attacks based on Linux Capability mechanism, including:
[0033] Get all usermode helper call functions;
[0034] Construct a call graph based on the calling function;
[0035] Generate a function call chain based on the function call graph, determine the location to add the permission check, and add the permission check;
[0036] Add the definition of a new capability in the kernel header file, and grant the new capability to all usermodehelpers in user mode;
[0037] Before executing any usermode helper, its permissions are checked to determine whether the usermode helper can be called.
[0038] Preferably, the calling function of the usermode helper includes:
[0039] Basic usermode helper calling function;
[0040] Starting from the position where the calling function of the basic usermode helper is used, the calling functions of the remaining usermode helpers are found.
[0041] Preferably, through the function call chain, a function at the final call point to which all calling functions of the usermode helper will eventually be executed is obtained; the location for adding permissions is at the function entry at the final call point and before executing the usermode helper.
[0042] Preferably, all usermode helpers are whitelisted.
[0043] Preferably, adding all usermode helpers to the whitelist includes:
[0044] Extract the specific values of the path parameters of the calling functions of all the usermode helpers, save the specific values and add them to the whitelist.
[0045] Preferably, for the new usermode helper, the new capability is granted in advance before it is enabled.
[0046] A system for preventing Usermode Helper privilege escalation attacks based on Linux Capability mechanism, comprising: a location determination module, a permission adding module and a permission checking module;
[0047] The location determination module is used to obtain all usermode helper call functions; based on the call function constructor call graph; based on the function call graph, a function call chain is generated to determine the location to add permission check, and add permission check;
[0048] The permission adding module is used to add the definition of a new capability in the kernel state header file, and grant the new capability to all usermode helpers in the user state;
[0049] The permission checking module is used to check the permission of any usermode helper before executing it, so as to determine whether the usermode helper can be called.
[0050] Preferably, the system further comprises a system adaptation module, and the system adaptation module is used for granting the new capability to the new usermode helper in advance before the new usermode helper is enabled.
[0051] First, we need to collect all the locations where the usermode helper is called, draw the program call graph based on the usermode helper call points, and determine the location where the usermode helper will actually be executed. From the analysis of existing attacks, we can see that the calling function of the usermode helper usually contains a parameter of file path type, because the usermode helper needs to pass in the user mode binary program path to be executed when it is finally executed. Therefore, starting from the usermode helper call point, the path will be passed down as a parameter. Using this feature, we can start from a call point of the usermode helper and manually analyze or use the LLVM static code analysis tool to find other calling functions. The first parameter of the common usermodehelper calling function call_usermodehelper_setup is the path of the usermodehelper program file to be called. Through forward analysis and backward analysis, we can find other functions that contain this file path parameter. Forward analysis traverses the upper-level function that calls this function to find functions that match the target parameter type; backward analysis traverses the lower-level functions called by this function to find functions that match the target parameter type. Through the analysis of Linux kernel code v6.6.3, four usermode helper calling functions were found, namely call_modprobe(), call_usermodehelper(), call_usermodehelper_setup() and call_usermodehelper_keys().
[0052] Starting from these calling functions, we build a function call graph, clarify the hierarchical relationship of the call chain, and finally determine the calling function or call function set of the usermode helper. In the Linux v6.6.3 kernel code, these calling functions will eventually execute to the kernel_execve() function, which is responsible for starting a user mode process and executing the specified usermode helper. By analyzing the functions that execute the usermode helper, we can determine the specific location to add permission checks. The operation of this check should be as close as possible to the actual operation of executing the usermode helper, otherwise there will be a risk of being bypassed. For example, it is not safe to check in call_modprobe() or other calling functions, because attackers generally use kernel vulnerabilities to hijack the control flow, that is, attackers can directly call kernel_execve() to bypass the permission check in the usermode helper. Therefore, we need to put the permission check before the operation that we really want to protect, that is, at the final call point entry of kernel_execve(), and before starting the usermode helper.
[0053] There are two permission mechanisms enabled by default on Linux, UID-based checks and capability-based checks. The latter is chosen here because it can achieve more fine-grained permission control. However, the 41 capabilities currently provided by the system are all permission checks for the main process, such as determining whether the current process has the CAP_SYS_TIME permission to modify the system time. For the usermode helper scenario, we need to determine whether the program (object) to be executed has specific permissions before the kernel executes the helper program with root permissions. The usermodehelper replaced by the attacker does not have permissions and will not be executed. For this reason, a new capability is introduced, named CAP_OBJ_UMH. "OBJ" is the abbreviation of object, indicating that this permission is used to check the object, and "UMH" is the abbreviation of usermode helper, indicating that this is a permission specifically used to defend against usermode helper privilege escalation attacks. And according to the implementation mechanism of the capability, the check is added to the location identified in the previous step. At the same time, a new permission is added to the header file of the permission definition, and a permission check is performed before executing the usermode helper.
[0054] You need to collect the usermode helper paths on the current system to ensure that the use of existing usermode helper programs is not affected and that new usermode helpers added later can be used normally. Figure 2 Explanation. The usermode helpers on the current system are not concentrated in the same directory, so they cannot be directly extracted from the system. The kernel code still needs to be analyzed to see which paths are called. In order to efficiently extract the usermode helper path, the kernel code can be statically analyzed with the help of LLVM. Combined with the above-mentioned 4 usermode helper call functions and the locations of their path parameters, all the places where these functions are called are traversed, and the specific values of the path parameters are extracted, and the specific values are saved and added to the whitelist. For example, for the function call_usermodehelper_setup(), its path is located in the first parameter, which can be obtained using the method "CallInst->getArgOperand(0)" provided by LLVM. 20 usermode helper paths were extracted on Linux v6.6.3. The user-mode binary programs corresponding to these paths are all pre-installed by the system and have higher permissions. Since these usermode helpers are trustworthy, the existing usermode helpers are added to the exemption whitelist to ensure that the use of the existing helper programs is not affected when the user does not know CAP_OBJ_UMH.
[0055] The Linux system has complex functions and huge code. In the future, it is likely that new usermode helpers will be introduced or existing usermode helpers will be replaced. In order to ensure that the program can be used normally before it is enabled, the system administrator needs to grant it the CAP_OBJ_UMH permission in advance. The authorization process can refer to the authorization process of the capability mechanism, that is, use the setcap command to add capabilities to files. The capability mechanism also ensures that if the authorized program is modified, the permissions granted to it will become invalid, further enhancing security.
[0056] Although the specific embodiments of the present invention are disclosed for the purpose of illustration, the purpose is to help understand the content of the present invention and implement it accordingly, those skilled in the art will understand that various substitutions, changes and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the best embodiment, and the scope of the present invention is subject to the scope defined in the claims.
Claims
1. A method for preventing Usermode Helper privilege escalation attacks based on Linux Capability mechanism, comprising: Get all usermode helper call functions; Construct a call graph based on the calling function; Generate a function call chain based on the function call graph, determine the location to add the permission check, and add the permission check; Add the definition of a new capability in the kernel header file, and grant the new capability to all usermodehelpers in user mode; Before executing any usermode helper, its permissions are checked to determine whether the usermode helper can be called.
2. The method according to claim 1, characterized in that: The calling function of the usermode helper includes: Basic usermode helper calling function; Starting from the position where the calling function of the basic usermode helper is used, the remaining calling functions of the usermodehelper are found.
3. The method according to claim 1, characterized in that Through the function call chain, the function at the final call point that all the calling functions of usermodehelper will finally execute is obtained; The location for adding permissions is at the function entry at the final call point and before executing usermodehelper.
4. The method according to claim 1, characterized in that Whitelist all usermode helpers.
5. The method according to claim 4, characterized in that The above whitelists all usermode helpers, including: Extract the specific values of the path parameters of the calling functions of all the usermode helpers, save the specific values and add them to the whitelist.
6. The method according to claim 1, characterized in that For new usermode helpers, grant the new capability in advance before enabling it.
7. A system for preventing Usermode Helper privilege escalation attacks based on Linux Capability mechanism, comprising: Determine location module, add permission module and permission check module; The location determination module is used to obtain the calling functions of all usermode helpers; Based on the calling function constructor call graph; based on the function call graph, generate a function call chain, determine the location to add permission check, and add permission check; The permission adding module is used to add the definition of a new capability in the kernel state header file, and grant the new capability to all usermode helpers in the user state; The permission checking module is used to check the permission of any usermode helper before executing it, so as to determine whether the usermode helper can be called.
8. The system according to claim 7, characterized in that The system further comprises a system adaptation module, and the system adaptation module is used for granting the new capability to the new usermode helper in advance before the new usermode helper is enabled.
9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, the computer program is configured to be executed by the processor, and the computer program comprises instructions for executing the method according to any one of claims 1 to 8.
10. A storage medium storing a computer program, wherein when the computer program is executed by a computer, the method according to any one of claims 1 to 8 is implemented.