System call hijacking method and device compatible with multi-version Linux kernel

Abstract

The invention discloses a system call hijacking method and device compatible with multiple versions of Linux kernels, a first hijacking channel and a second hijacking channel are deployed in parallel in a target version of Linux kernel in advance, the first hijacking channel is adapted to a Linux kernel version executing system call through a system call table, and the second hijacking channel is adapted to a second hijacking channel which is adapted to a Linux kernel version executing system call through a system call table. The second hijacking channel is adapted to a Linux kernel version which executes system calling through a system calling distribution function, and the method comprises the following steps: in response to a system calling request, hijacking the system calling request to a pre-defined target address through a target hijacking channel which actually takes effect in a Linux kernel of a target version, determining a corresponding target function based on the target address; sorting system call parameters carried in the system call request into a data format required by a preset hook entry function through a target function, and sending the data subjected to format sorting to the hook entry function; and determining a security processing strategy for the system call request through a hook entry function on the basis of the formatted data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer security, and in particular to a system call hijacking method and device compatible with multiple versions of Linux kernel. BACKGROUND

[0002] Currently, the mainstream Linux system call hijacking methods mainly fall into two categories. The first category of hijacking method is based on the Linux Security Modules (LSM) framework, and its core principle is to register a custom hook function to the LSM framework. When the kernel runs to a specific checkpoint of the LSM framework, the corresponding hook function is called for security check. However, the hook function of this scheme is not completely consistent with the system call parameters, and the parameters are different in different kernel versions, which is inconvenient for developers to interface. The second category of hijacking method is to directly replace the corresponding function pointer in the system call table (sys_call_table), and the process will directly call the replaced hook function for security check when making a system call. However, this method is invalid in the kernel version later than 6.9 of x86_64 architecture linux, because the kernel no longer reads the function pointer in the system call table for indirect call when making a system call, but directly hardcodes the function address into the code.

[0003] Therefore, it has become a technical problem to be solved urgently to develop a system call hijacking method that can ensure the consistency of hook function and system call parameters, and is compatible with low version and high version of Linux kernel later than 6.9. SUMMARY

[0004] The present application relates to the technical field of computer security, and in particular to a system call hijacking method and device compatible with multiple versions of Linux kernel.

[0005] According to one aspect of the present application, a system call hijacking method compatible with multiple versions of Linux kernel is provided, and a first hijacking channel and a second hijacking channel are deployed in parallel in a target version of Linux kernel in advance. The first hijacking channel is adapted to the Linux kernel version that executes system call through a system call table, and the second hijacking channel is adapted to the Linux kernel version that executes system call through a system call dispatch function. The method comprises: In response to a system call request, the system call request is hijacked to a pre-defined target address through a target hijacking channel actually in effect in the target version of Linux kernel, and a corresponding target function is determined based on the target address. The target hijacking channel is the first hijacking channel or the second hijacking channel. arranging, by the target function, system call parameters carried in the system call request into a data format required by a preset hook entry function, and sending the data in the arranged format to the hook entry function; determining, by the hook entry function, a security processing strategy for the system call request based on the data in the arranged format.

[0006] Optionally, when the target hijacking channel is the first hijacking channel, the hijacking, by the actually effective target hijacking channel in the target version of the Linux kernel, of the system call request to the pre-defined target address includes: obtaining a target system call number from the system call parameters; reading a system call table from the target version of the Linux kernel, and determining a target function pointer associated with the target system call number from the system call table; wherein when the first hijacking channel is deployed in the target version of the Linux kernel, an original pointer function associated with the target system call number in the system call table is modified into a pre-defined target pointer function; pointing to a memory address pointed to by the target function pointer as the target address, and jumping to the target address to hijack the system call request to the target address.

[0007] Optionally, when the target hijacking channel is the second hijacking channel, the hijacking, by the actually effective target hijacking channel in the target version of the Linux kernel, of the system call request to the pre-defined target address includes: starting a target system call distribution function in the target version of the Linux kernel; wherein when the second hijacking channel is deployed in the target version of the Linux kernel, a Ftrace hook function is registered at an execution entry of the target system call distribution function based on a Ftrace framework in the target version of the Linux kernel; modifying, by the Ftrace hook function, a value of a RIP register into a pre-defined target address, and jumping to the target address to hijack the system call request to the target address.

[0008] Optionally, the determining, by the hook entry function, of the security processing strategy for the system call request based on the data in the arranged format includes: obtaining, by the hook entry function, a target system call number in the data in the arranged format, querying a state identifier of the target system call number from a preset system call state table, and detecting whether the state identifier represents a temporary closing state; If yes, target original system call logic corresponding to the target hijacked channel is executed, a system call result is obtained, and the system call result is returned to a requester initiating the system call request; If no, a security processing strategy for the system call request is determined based on the target system call number.

[0009] Optionally, the determining the security processing strategy for the system call request based on the target system call number comprises: all client registries are acquired, wherein each system call number to be intercepted and a front-interception callback function pointer and / or a rear-interception callback function pointer associated with each system call number to be intercepted are included in the client registries, the front-interception callback function pointer is a callback function pointer to be executed before the target original system call logic is called, and the rear-interception callback function pointer is a callback function pointer to be executed after the target original system call logic is called; all callback function pointers associated with the target system call number are extracted from the acquired all client registries; when the extracted callback function pointers include the front-interception callback function pointer, a callback function pointed to by the front-interception callback function pointer is called to detect whether the system call request meets a security requirement specified by the callback function, a front-interception detection result is obtained, and whether the target original system call logic is executed is determined based on the front-interception detection result; when the extracted callback function pointers do not include the front-interception callback function pointer, the target original system call logic is executed, and the system call result is obtained.

[0010] Optionally, the determining the security processing strategy for the system call request based on the target system call number further comprises: when the extracted callback function pointers include the rear-interception callback function pointer, a callback function pointed to by the rear-interception callback function pointer is called to detect whether the system call result meets a security requirement specified by the callback function based on the data in the arranged format, a rear-interception detection result is obtained, and whether the system call result is returned to the requester is determined based on the rear-interception detection result; when the extracted callback function pointers do not include the rear-interception callback function pointer, the system call result is returned to the requester.

[0011] In order to achieve the above object, the application further provides a system call hijacking device compatible with multiple versions of Linux kernel, a first hijacking channel and a second hijacking channel being deployed in a target version of Linux kernel in advance, the first hijacking channel being adapted to a Linux kernel version executing system calls through a system call table, the second hijacking channel being adapted to a Linux kernel version executing system calls through a system call distribution function, the device comprising: a data hijacking module, configured to hijack a system call request to a target address predefined in advance through a target hijacking channel actually in effect in the target version of Linux kernel in response to the system call request, and determine a target function corresponding to the target address based on the target address, wherein the target hijacking channel is the first hijacking channel or the second hijacking channel; a data arrangement module, configured to arrange system call parameters carried in the system call request into a data format required by a preset hook entry function through the target function, and send the data in the arrangement format to the hook entry function; a security detection module, configured to determine a security processing strategy for the system call request based on the data in the arrangement format through the hook entry function.

[0012] Optionally, the security detection module is specifically configured to: obtain a target system call number in the data in the arrangement format through the hook entry function, query a state identifier of the target system call number from a preset system call state table, and detect whether the state identifier represents a temporary closing state; if yes, execute a target original system call logic corresponding to the target hijacking channel, obtain a system call result, and return the system call result to a requester initiating the system call request; if no, determine the security processing strategy for the system call request based on the target system call number.

[0013] In order to achieve the above object, the application further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor being used to implement the steps of the system call hijacking method compatible with multiple versions of Linux kernel when executing the computer program.

[0014] In order to achieve the above object, the application further provides a computer readable storage medium, having a computer program stored thereon, the computer program being used to implement the steps of the system call hijacking method compatible with multiple versions of Linux kernel when executed by a processor.

[0015] The application provides a system call hijacking method and device compatible with multiple versions of Linux kernels, which deploys two hijacking channels in parallel, accurately adapts to the calling mechanisms of different versions of Linux kernels, realizes full coverage of multiple versions of Linux kernels, and breaks through the adaptation bottleneck of high-version kernels. The target function standardizes and arranges the system call native parameters, ensures the consistency of the hook function parameters, and greatly reduces the development docking difficulty. The unified hook entry function makes centralized decisions, simplifies the control logic, significantly improves the safety processing efficiency and refinement degree, and meets the cross-version reuse demand. BRIEF DESCRIPTION OF DRAWINGS

[0016] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of the preferred embodiments and are not intended to limit the scope of the application. Moreover, the same reference numerals are used throughout the same figures. In the drawings: Figure 1 A flowchart of the system call hijacking method compatible with multiple versions of Linux kernels provided for embodiment one is shown in Figure 1. Figure 2 An architecture schematic diagram of the system call hijacking scheme compatible with multiple versions of Linux kernels provided for embodiment one is shown in Figure 2. Figure 3 A block diagram of the system call hijacking device compatible with multiple versions of Linux kernels provided for embodiment two is shown in Figure 3. Figure 4 A block diagram of the computer device suitable for implementing the system call hijacking method compatible with multiple versions of Linux kernels provided for embodiment three is shown in Figure 4. DETAILED DESCRIPTION

[0017] In order to make the purpose, technical solutions and advantages of the application clearer, the application will be further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application and not to limit the application. Based on the embodiments in the application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of the application.

[0018] Embodiment one Embodiment one of the application provides a system call hijacking method compatible with multiple versions of Linux kernels, which pre-deploys a first hijacking channel and a second hijacking channel in parallel in a target version of Linux kernel, the first hijacking channel is adapted to a Linux kernel version that executes system calls through a system call table, and the second hijacking channel is adapted to a Linux kernel version that executes system calls through a system call dispatch function. As shown in the figure, the method comprises steps S1-S3, wherein: Figure 1 ​Step S1, in response to a system call request, hijacking the system call request to a pre-defined target address through an actual effective target hijacking channel in the target version of the Linux kernel, and determining the corresponding target function based on the target address; wherein the target hijacking channel is the first hijacking channel or the second hijacking channel.

[0019] When the target version of Linux is x86_64 architecture linux6.9 and earlier versions, the target hijacking channel is the first hijacking channel; when the target version of Linux is x86_64 architecture linux6.9 and later versions, the target hijacking channel is the second hijacking channel.

[0020] The first hijacking channel and the second hijacking channel coexist in the Linux kernel, and the Linux kernel naturally selects the effective path according to its own architecture without active detection. Low version kernel: Ftrace hook fails, and system call table modification takes effect; high version kernel: system call table modification is invalid, and Ftrace hook takes effect.

[0021] The normal system call process is: after the application program initiates a system call request, such as the application program calling the open() library function, the library function stores the system call number and the system call parameters (such as file path, permission, length) required to implement the specific system call function into the corresponding register, and prepares to trigger the system call. The library function executes the syscall assembly instruction to trigger the CPU mode switching, and the CPU switches from user mode to kernel mode. The syscall instruction will make the CPU jump to the fixed entry point defined by the Linux kernel, and the kernel will execute the assembly code at the entry point to save the user state register value to the kernel stack to prevent context loss; the kernel reads the system call number from the RAX register to confirm the type of system call currently needed to be executed. Further, for system calls that rely on the system call table: the kernel reads the function pointer corresponding to the index from the system call table with the extracted system call number as the index, and the kernel takes the address pointed to by the function pointer as the original address and calls the original system call function at the original address, and passes the parameters in the RDI, RSI, etc. registers to the function to complete the system call logic. For system calls that rely on the system call dispatch function: the kernel passes the extracted system call number into the pre-defined system call dispatch function, and the system call dispatch function generates an assembly instruction that directly jumps to the original address according to the system call number. When the CPU executes this assembly instruction, the hard-coded original address is written into the RIP register, and then the CPU automatically jumps to the address pointed to by the RIP register to call the original system call function at the address and pass the register parameters to complete the system call logic.

[0022] In order to prevent the system call request from flowing to the native function and achieve the purpose of hijacking, the original address is modified to a pre-defined target address, so as to hijack the system call request to the target address, and use the target function corresponding to the target address to arrange the system call parameters, and transmit the data with uniform format to the hook entry function for security detection. The essence of hijacking the system call request to the target address is to guide the hijacked system call request to the pre-defined target address to change the execution direction of the system call. The original system call will execute the original system call function of the kernel, and after hijacking, it will jump to the pre-defined target address, which is equivalent to transferring the processing right of the system call request to the function corresponding to the target address.

[0023] Optionally, when the target hijacking channel is the first hijacking channel, the target hijacking channel actually effective in the target version of the Linux kernel is used to hijack the system call request to a pre-defined target address, including: obtaining a target system call number from the system call parameters; reading a system call table from the target version of the Linux kernel, and determining a target function pointer associated with the target system call number from the system call table; wherein when the first hijacking channel is deployed in the target version of the Linux kernel, an original pointer function associated with the target system call number in the system call table is modified to a pre-defined target pointer function; using a memory address pointed to by the target function pointer as the target address, and jumping to the target address to hijack the system call request to the target address.

[0024] Specifically, the system call parameters include a system call number, in order to distinguish the system call number in the system call parameters from other system call numbers in the system call table, the system call number in the system call parameters is referred to as a target system call number. Through the system call number, it can be determined which system call (such as open, read) is currently hijacked, which prepares for subsequent queries to the system call table. The system call table has been modified in the process of deploying the first hijacking channel, and the original function pointer corresponding to the target system call number in the system call table is replaced with a pre-defined target function pointer, wherein the memory address pointed to by the original function pointer is the original address, and the function pointed to by the original function pointer is the original system call function. As shown in Figure 2 The left half part is the first hijacking channel using the system call table, and the system call table stores the replaced function pointer corresponding to the target system call number, that is, the target function pointer. Further, when querying the system call table based on the target system call number, the target pointer function can be obtained, and the target address pointed to by the target pointer function can also be obtained.

[0025] Optionally, when the target hijacking channel is the second hijacking channel, the hijacking of the system call request to the pre-defined target address through the actually effective target hijacking channel in the target version of the Linux kernel comprises: starting a target system call dispatch function in the target version of the Linux kernel; wherein, when the second hijacking channel is deployed in the target version of the Linux kernel, a Ftrace hook function is registered at the execution entry of the target system call dispatch function based on the Ftrace framework in the target version of the Linux kernel; modifying the value of the RIP register to a pre-defined target address through the Ftrace hook function, and jumping to the target address to hijack the system call request to the target address.

[0026] Specifically, the target system call dispatch function is a certain system call dispatch function, such as x64_sys_call or ia32_sys_call. The Ftrace framework is a built-in tracing and debugging tool of the Linux kernel. When an application initiates a system call, the CPU switches to the kernel mode and starts executing the corresponding target system call dispatch function. Since the Ftrace hook is registered at the entry of the function, the kernel will first jump to the Ftrace hook function registered by the developer for execution. In the x86-64 architecture, the RIP register stores the address of the next instruction to be executed by the CPU, and the Ftrace hook function modifies the original address stored in the RIP by directly modifying the RIP value in the current execution context (i.e. the pt_regs structure) to the pre-defined target address set by the developer. When the Ftrace hook function returns after execution, the CPU will obtain the target address from the new RIP and jump to the address.

[0027] The Ftrace hook function also has an intelligent judgment function. Optionally, the modification of the value of the RIP register to a pre-defined target address through the Ftrace hook function, and the jumping to the target address to hijack the system call request to the target address, comprises: judging, through the hook function, whether the system call request meets the pre-set hijacking requirement based on the system call parameters; when it is determined that it meets, modifying, through the hook function, the value of the RIP register to a pre-defined target address.

[0028] Specifically, in the x86-64 architecture, system call parameters are typically passed through registers (such as RDI, RSI, and RDX registers). The Ftrace hook function can read the values ​​of these registers to obtain the system call parameters. Predefined hijacking requirements exist, such as: for specific calls: only hijacking critical calls like `open` and `execve`; for specific parameters: only hijacking `open` calls accessing ` / etc / shadow`, or only hijacking calls from specific processes; for specific actions: only hijacking calls deleting files or creating network connections. When a rule is not met, the Ftrace hook function returns directly, and the system call continues its original process. Hijacking only occurs when the rules are met.

[0029] like Figure 2 As shown, Figure 2 The right half of the diagram represents the second hijacking channel, utilizing system call dispatch functions. An Ftrace hook function is deployed for each system call dispatch function in this second hijacking channel. Each system call request matches one of these system call dispatch functions, denoted as the target system call dispatch function. When the target system call dispatch function is started, the Ftrace hook function is enabled because it is located at its entry point. Figure 2 The steps to enter the FtraceHook stub are as follows: Upon first entering the Ftrace Hook stub function, it checks whether the system call requires hijacking. If so, it modifies the RIP register and returns, which will cause subsequent execution flow to switch to the Ftrace Hook replacement function.

[0030] Optionally, determining the corresponding objective function based on the target address includes: When the target address points to a pre-defined replacement function, the replacement function is used as the target function; When the target address points to a pre-defined function fingerprint mapping table: A function storage address is selected from the function fingerprint mapping table as a relay address; wherein, the function fingerprint mapping table includes multiple numerical fingerprints and function storage addresses associated with each numerical fingerprint, and the function pointed to by each function storage address is the replacement function, decoy function or trap function, the decoy function is used to call the replacement function, and the trap function is used to organize the data format of the system call parameters and track the behavior of the target process that initiated the system call request; The function pointed to by the intermediate address is taken as the target function.

[0031] Specifically, there are two ways to determine the objective function.

[0032] Scheme one: a pre-defined replacement function is directly stored at the target address, which is the target function to be found. The function of the replacement function is to arrange the system call parameters carried in the system call request into the data format required by the preset hook entry function, and then call the hook entry function according to the unified calling convention.

[0033] As shown in Figure 2 The first hijacking channel part corresponds to: the replacement function can be directly called through the replaced function pointer. The second hijacking channel part corresponds to: the replacement function can be directly called through the target address.

[0034] Scheme two: a function fingerprint mapping table is stored at the target address, and a function storage address is obtained from the function fingerprint mapping table each time, and then the function at the function storage address is taken as the target function. Each function at the function storage address in the mapping table has the function of arranging the parameter format. The core idea of scheme two is to evolve a single replacement function into a multi-state replacement function cluster, to realize the unpredictability of the execution path through dynamic fingerprint routing and intelligent copy management, thereby enhancing the ability to resist advanced attacks.

[0035] Specifically, the function fingerprint mapping table includes a replacement function, a bait function and a trap function. The core definition of the bait function is that it does not execute the core business logic itself, but only calls the replacement function as an intermediate layer. That is, the bait function behaves the same as the replacement function, and will also arrange parameters, call hook entry functions, etc. For attackers, the bait function looks like a real target and needs to spend time to reverse analyze. That is, the bait function has no special effect on the system, but only increases the analysis target of the attacker, consumes the resources of the attacker, and realizes confusion. The core definition of the trap function is to perform parameter arrangement, behavior tracking, risk interception and other operations for abnormal risk scenarios. That is, the trap function will also arrange the parameter format and call the hook entry function, but will additionally perform security operations such as adding an exception tag to track user behavior, recording behavior logs, sending alerts, deliberately returning error information to mislead attackers, etc. For attackers, the trap function also looks like a real target, but once it interacts with it, it will expose itself and trigger a counterattack by the defense system. That is, the trap function can actively detect and respond to attacks.

[0036] It should be noted that, since the replacement function is located in the system call hijacking scheme, it is the first self-defined code encountered by the attacker (after the system call distribution function and before the original system call processing function). If the attacker can locate and skip the replacement function, the subsequent hook entry function and all security detection will be useless. Therefore, the replacement function is strengthened and confused, not to protect a format converter, but to protect the entrance of the entire security monitoring system.

[0037] Optionally, the step of selecting a function storage address as the transit address from the function fingerprint mapping table comprises: collecting a numerical target context snapshot when the target hijacking channel hijacks the system call request to the target address from the target version of the Linux kernel; calculating a numerical fingerprint belonging to a preset first numerical set based on the target context snapshot, and screening a function storage address associated with the calculated numerical fingerprint from the function fingerprint mapping table; wherein the first numerical set includes numerical fingerprints associated with function storage addresses of the replacement function and each decoy function in the function fingerprint mapping table, respectively; collecting historical behavior parameters of the target process, and determining whether the historical behavior parameters conform to a preset abnormal behavior rule; If not, the screened function storage address is used as the transit address; If so, revising the calculated numerical fingerprint so that the revised numerical fingerprint belongs to a preset second numerical set, determining a function storage address associated with the revised numerical fingerprint from the function fingerprint mapping table, and using the function storage address as the transit address; wherein the second numerical set includes numerical fingerprints associated with function storage addresses of each trap function in the function fingerprint mapping table, respectively.

[0038] Specifically, when the target hijacking channel is the first hijacking channel, the step of collecting a numerical target context snapshot when the target hijacking channel hijacks the system call request to the target address comprises: collecting a numerical target context snapshot when jumping to the target address after querying the target address pointed to by the target function pointer.

[0039] When the target hijacking channel is the second hijacking channel, the step of collecting a numerical target context snapshot when the target hijacking channel hijacks the system call request to the target address comprises: collecting a numerical target context snapshot when jumping to the target address after modifying the value of the RIP register to a pre-defined target address through the Ftrace hook function.

[0040] Among them, the data of the target context snapshot are all numerical, including but not limited to: timestamp counter, system call number, current process ID, kernel stack frame base address. When the target hijacking channel is the first hijacking channel, the target context snapshot can also include: system call table index; when the target hijacking channel is the second hijacking channel, the target context snapshot can also include: entry address of the target system call distribution function. The target context snapshot is a multi-dimensional, instantaneous unique, and native data set for completely describing the execution environment of a specific system call.

[0041] The target context snapshots are combined together through a series of XOR and shift operations to generate a temporary hash value, and the temporary hash value is subjected to a modulo operation to limit the operation result within the first numerical set. For example, the positions of 0-255 in the function fingerprint mapping table store the function storage addresses of the replacement function and the decoy function, and the temporary hash value can be subjected to a modulo operation of 256 to ensure that the modulo result is within the set of 0-255. The purpose of the embodiment of controlling the calculated numerical fingerprint to be associated with the replacement function or the decoy function instead of the trap function is to avoid monitoring the security process and wasting resources.

[0042] Further, whether the target process is a security process is not known at present, and needs to be judged in combination with the historical behavior parameters of the target process. For example, all historical behavior parameters of the target process in the time period from receiving the system call request to screening the function storage address are collected, and for example, all historical behavior parameters of the target process in the time period from receiving the system call request to hijacking the system call request to the pre-defined target address are collected.

[0043] When it is determined that the target process is abnormal, the trap function needs to be used for security control, and therefore the calculated numerical fingerprint needs to be revised so that the revised numerical fingerprint points to the function storage address of the trap function. Among them, the revision method is, for example, that a plurality of sets of specific values of each parameter in the target context snapshot are pre-set, and the calculated numerical fingerprint is revised by any one set of values to point to the function storage address of the trap function. For another example, the calculated numerical fingerprint is subjected to a bit operation (such as a bit OR operation), and some binary bits of the fingerprint are forcibly set to 1 or 0, so as to ensure that the result falls within the second numerical set.

[0044] In step S2, the target function is used to arrange the system call parameters carried in the system call request into a data format required by the pre-set hook entry function, and the data arranged in the format is sent to the hook entry function.

[0045] When the target function is the replacement function, the replacement function is used to arrange the system call parameters carried in the system call request into a data format required by the pre-set hook entry function, and the data arranged in the format is sent to the hook entry function.

[0046] When the target function is the decoy function, the decoy function is used to call the replacement function, so that the function arranges the system call parameters carried in the system call request into a data format required by the pre-set hook entry function, and the data arranged in the format is sent to the hook entry function.

[0047] When the target function is the trap function, step S2 includes: When the historical behavior parameter matches a low-risk behavior rule in the abnormal behavior rule, the system call parameter is arranged into a data format required by the hook entry function by the trap function, a preset abnormal label is added to the arranged data, and the data with the abnormal label is sent to the hook entry function.

[0048] When the target function is the trap function, the method further includes: When the historical behavior parameter matches a high-risk behavior rule in the abnormal behavior rule, a pre-forged response result is returned to the target process by the trap function, and an alarm information is sent in the target version of the Linux kernel.

[0049] Specifically, the abnormal behavior rule is divided into a high-risk behavior rule and a low-risk behavior rule. The abnormal label can follow the entire system call processing flow, that is, it plays a tracking role. The forged response result is an error response result, which is used to confuse the attacker.

[0050] In step S3, the hook entry function determines a security processing strategy for the system call request based on the arranged data.

[0051] In order to ensure that the system call request is normally responded, the target original system call logic corresponding to the target hijacking channel is called through the hook entry function. When the target hijacking channel is the first hijacking channel, the target original system call logic is the logic of executing the system call through the system call table; when the target hijacking channel is the second hijacking channel, the target original system call logic is the logic of executing the system call through the target system call distribution function. Before and / or after calling the target original system call logic, the security detection logic is set to determine the security processing strategy for the system call request.

[0052] Optionally, the determination of the security processing strategy for the system call request by the hook entry function based on the arranged data includes: The target system call number in the arranged data is obtained by the hook entry function, the state identifier of the target system call number is queried from a preset system call state table, and it is detected whether the state identifier represents a temporary closed state; If yes, the target original system call logic corresponding to the target hijacking channel is executed, a system call result is obtained, and the system call result is returned to a requester initiating the system call request; If no, the security processing strategy for the system call request is determined based on the target system call number.

[0053] Specifically, the system call number uniquely identifies the type of the requested operation, such as file opening, process creation, etc. The state identifier represents at least two states: a temporary closed state and a check required state. When the state identifier of the target system call number represents the temporary closed state, it indicates that no security detection needs to be performed on the system call request, and the data after the format arrangement is directly restored to the original data format, the system call parameters in the original data format are obtained, and then the target original system call logic is executed based on the system call parameters in the original data format. When the target hijacking channel is the first hijacking channel, the target original system call logic is to obtain a pre-reserved original function pointer, and call the original system call function pointed by the original function pointer to execute the system call request. When the target hijacking channel is the second hijacking channel, the target original system call logic is that the hook entry function calls the target system call distribution function and passes the system call parameters to the target system call distribution function. At this time, the Ftrace hook function is entered again, and the Ftrace hook function detects that the target system call distribution function is called by the hook entry function instead of the Linux kernel, and returns the control to the Ftrace framework. Because the RIP is not modified in the previous step, the process continues to run the target system call distribution function, which calls the kernel original system call function to complete the system call logic.

[0054] When the state identifier of the target system call number represents the check required state, a security processing strategy for the system call request is determined based on the target system call number. For example, before the target original system call logic is called, a callback function associated with the target system call number and used to perform security detection before the target original system call logic is called is determined, and security detection logic is performed on the system call request based on the callback function; and / or after the target original system call logic is called, a callback function associated with the target system call number and used to perform security detection after the target original system call logic is called is determined, and security detection logic is performed on the system call result based on the callback function.

[0055] If security detection logic is set before the target original system call logic is called, the security processing strategy can include but is not limited to: allowing the system call request to pass, intercepting the system call request, or passing after modifying the system call request, etc.

[0056] If security detection logic is set after the target original system call logic is called, the security processing strategy can include but is not limited to: retaining the execution result of the original system call and directly returning it to the user process that initiates the system call, returning after modifying the execution result of the original system call, triggering a security alarm and notifying an administrator or linking other security components for abnormal execution results, etc.

[0057] Optionally, the determining of the security processing policy for the system call request based on the target system call number comprises: obtaining all client registries, wherein each client registry includes a system call number to be intercepted and a front-interception callback function pointer and / or a back-interception callback function pointer associated with each system call number to be intercepted, the front-interception callback function pointer being a callback function pointer to be executed before the target original system call logic is invoked, and the back-interception callback function pointer being a callback function pointer to be executed after the target original system call logic is invoked; extracting all callback function pointers associated with the target system call number from the obtained all client registries; when the extracted callback function pointers include a front-interception callback function pointer, invoking the callback function pointed to by the front-interception callback function pointer to detect whether the system call request meets a security requirement specified by the callback function based on the data in the arranged format, obtaining a front-interception detection result, and determining whether to execute the target original system call logic based on the front-interception detection result; when the extracted callback function pointers do not include a front-interception callback function pointer, executing the target original system call logic to obtain the system call result.

[0058] Specifically, the client registry is a table pre-registered by a front-end module, and each client registry includes a system call number concerned by the front-end module registering the client registry, i.e., a system call number to be intercepted. After extracting all callback function pointers associated with the target system call number, the extracted all callback function pointers can be stored in a temporary array. The callback function pointed to by the front-interception callback function pointer is referred to as a front-interception callback function. The front-interception callback function is used to detect whether the system call request meets a security requirement specified by the front-interception callback function based on the data in the arranged format before the target original system call logic is invoked. If the front-interception detection result indicates that the requirement is not met and the interception is needed, the interception result is directly returned to the requester, and the target original system call logic is not invoked any more; if the front-interception detection result indicates that the requirement is met but needs to be modified, the data in the arranged format is modified, and the target original system call logic is invoked based on the modified data to obtain the system call result; if the front-interception detection result indicates that the requirement is met, the target original system call logic is invoked based on the data in the arranged format to obtain the system call result.

[0059] When the extracted callback function pointers do not include a front-interception callback function pointer, it is indicated that no front-end module registers the front-interception check for the target system call number. At this time, the framework skips the front-interception detection stage and directly executes the target original system call logic to obtain the system call result.

[0060] Optionally, the determining the security processing policy for the system call request based on the target system call number further comprises: When the extracted callback function pointer contains a post-interception callback function pointer, calling the callback function pointed to by the post-interception callback function pointer to detect whether the system call result meets the security requirements specified by the callback function, obtaining a post-interception detection result, and determining whether to return the system call result to the requestor based on the post-interception detection result; When the extracted callback function pointer does not contain a post-interception callback function pointer, returning the system call result to the requestor.

[0061] Specifically, the callback function pointed to by the post-interception callback function pointer is referred to as a post-interception callback function. The post-interception callback function is used to detect whether the system call result meets the security requirements specified by the post-interception callback function after the target original system call logic is called. If the post-interception detection result indicates that the requirements are not met and interception is required, the interception result is returned to the requestor and the system call result is not returned; if the pre-interception detection result indicates that the requirements are met, the system call result is returned to the requestor. When the extracted callback function pointer does not contain a post-interception callback function pointer, it indicates that no front-end module registers post-interception checking for the target system call number. At this time, the framework will skip the post-interception detection stage and directly return the system call result to the requestor.

[0062] Through the above design scheme, the Linux kernel using the system call table and the Linux kernel not using the system call table are compatible in the target of hijacking the system call, and the parameters obtained in the security check logic are consistent with the system call parameters.

[0063] As Figure 2As shown, the Hook unified entry function is a hook entry function, and the function is called to perform the security check logic before the system call. Specifically, in the Hook unified entry function, it is checked whether the system call is in the temporary closing state in the hook state table (i.e., the system call state table). If it is in the closing state, the target original system call logic is directly called and returned. If it is in the hook state, all callback function pointers of the system call applied for hooking are obtained from the client registry to form a temporary array (i.e., a client group) for this use, which will be used in the subsequent pre hook and after hook. For the pre hook stage, all non-empty pre hook callback functions, i.e., the front interception callback functions, are called by traversing the client group. The pre hook stage is the security software check and protection logic, which supports modifying the return value of the request. If all callback functions in the pre hook do not block the request, the target original system call logic is entered. For the system call using the Ftrace mechanism, the x64_sys_call function is called through the system call parameters received by the Hook unified entry function. At this time, the Ftrace Hook stub function (i.e., the Ftrace hook function) is entered for the second time. The anti-recursion check is performed here, and the RIP is not modified, so the process continues to run x64_sys_call, which calls the original system call function of the kernel to complete the system call logic. Further, the security check logic after the system call is performed. For the after hook stage, all non-empty after hook callback functions, i.e., the rear interception callback functions, are called by traversing the client group. The after hook stage is also the security software check and protection logic, which supports modifying the return value of the request. Figure 2 The left half and the right half of the middle part cover different versions of Linux kernels by different technical means, and unify the running logic of the hijacked system call to the Hook unified entry function, i.e., the Hook unified entry function, and the subsequent parameters consistent with the system call can be obtained, so that the security check logic can be more smoothly performed.

[0064] Embodiment Two The embodiment of the application provides a system call hijacking device compatible with multiple versions of Linux kernels. A first hijacking channel and a second hijacking channel are deployed in parallel in a target version of Linux kernel in advance. The first hijacking channel is adapted to a Linux kernel version that executes a system call through a system call table, and the second hijacking channel is adapted to a Linux kernel version that executes a system call through a system call distribution function. Figure 3As shown, the system call hijacking device 30 compatible with the multi-version Linux kernel specifically includes the following components: a data hijacking module 301 configured to, in response to a system call request, hijack the system call request to a pre-defined target address through a target hijacking channel actually in effect in the target version of the Linux kernel, and determine a target function corresponding to the target address based on the target address; wherein the target hijacking channel is the first hijacking channel or the second hijacking channel; a data arrangement module 302 configured to arrange system call parameters carried in the system call request into a data format required by a preset hook entry function through the target function, and send the data in the arranged format to the hook entry function; a security detection module 302 configured to determine a security processing strategy for the system call request based on the data in the arranged format through the hook entry function.

[0065] Optionally, when the target hijacking channel is the first hijacking channel, the data hijacking module, in executing the target hijacking channel actually in effect in the target version of the Linux kernel to hijack the system call request to the pre-defined target address, is specifically configured to: obtain a target system call number from the system call parameters; read a system call table from the target version of the Linux kernel, and determine a target function pointer associated with the target system call number from the system call table; wherein, when the first hijacking channel is deployed in the target version of the Linux kernel, an original pointer function associated with the target system call number in the system call table is modified to a pre-defined target pointer function; use a memory address pointed to by the target function pointer as the target address, and jump to the target address to hijack the system call request to the target address.

[0066] Optionally, when the target hijacking channel is the second hijacking channel, the data hijacking module, in executing the target hijacking channel actually in effect in the target version of the Linux kernel to hijack the system call request to the pre-defined target address, is specifically configured to: start a target system call distribution function in the target version of the Linux kernel; wherein, when the second hijacking channel is deployed in the target version of the Linux kernel, a Ftrace hook function is registered at an execution entry of the target system call distribution function based on a Ftrace framework in the target version of the Linux kernel; The value of the RIP register is modified to a pre-defined target address by the Ftrace hook function, and jumps to the target address to hijack the system call request to the target address.

[0067] Optionally, the security detection module is specifically configured to: The target system call number in the data in the arranged format is obtained by the hook entry function, the state identifier of the target system call number is queried from a preset system call state table, and it is detected whether the state identifier represents a temporary closing state; If yes, the target original system call logic corresponding to the target hijacking channel is executed, a system call result is obtained, and the system call result is returned to a requestor initiating the system call request; If no, a security processing strategy for the system call request is determined based on the target system call number.

[0068] Optionally, when the security detection module executes the security processing strategy determined based on the target system call number, it is specifically configured to: All client registries are obtained; wherein the client registries include each system call number to be intercepted and a front interception callback function pointer and / or a rear interception callback function pointer associated with each system call number to be intercepted, the front interception callback function pointer is a callback function pointer executed before the target original system call logic is called, and the rear interception callback function pointer is a callback function pointer executed after the target original system call logic is called; All callback function pointers associated with the target system call number are extracted from the obtained all client registries; When the extracted callback function pointers include the front interception callback function pointer, the callback function pointed to by the front interception callback function pointer is called to detect whether the system call request meets the safety requirements of the callback function based on the data in the arranged format, a front interception detection result is obtained, and it is determined whether to execute the target original system call logic based on the front interception detection result; When the extracted callback function pointers do not include the front interception callback function pointer, the target original system call logic is executed to obtain the system call result.

[0069] Optionally, when the security detection module executes the security processing strategy determined based on the target system call number, it is specifically further configured to: When the extracted callback function pointer contains a post-interception callback function pointer, a callback function pointed by the post-interception callback function pointer is called to detect whether the system call result meets safety requirements defined by the callback function, a post-interception detection result is obtained, and it is determined whether to return the system call result to the requester based on the post-interception detection result; When the extracted callback function pointer does not contain a post-interception callback function pointer, the system call result is returned to the requester.

[0070] Optionally, when the data hijacking module determines the target function based on the target address, the data hijacking module is specifically configured to: When the target address points to a pre-defined replacement function, the replacement function is taken as the target function. When the target address points to a pre-defined function fingerprint mapping table, the data hijacking module is specifically configured to: select a function storage address from the function fingerprint mapping table as a transfer address; wherein the function fingerprint mapping table includes a plurality of numerical fingerprints and function storage addresses associated with each numerical fingerprint, each function storage address points to a function, the function is the replacement function, a bait function or a trap function, the bait function is used to call the replacement function, and the trap function is used to arrange the data format of the system call parameter and track the behavior of a target process that initiates the system call request; the function pointed by the transfer address is taken as the target function.

[0071] Optionally, when the data hijacking module selects a function storage address from the function fingerprint mapping table as a transfer address, the data hijacking module is specifically configured to: collect a numerical target context snapshot when the target hijacking channel hijacks the system call request to the target address from the target version of the Linux kernel; calculate a numerical fingerprint belonging to a preset first numerical set based on the target context snapshot, and select a function storage address associated with the calculated numerical fingerprint from the function fingerprint mapping table; wherein the first numerical set includes numerical fingerprints associated with function storage addresses of the replacement function and each bait function in the function fingerprint mapping table; collect historical behavior parameters of the target process, and determine whether the historical behavior parameters meet a preset abnormal behavior rule; If not, the selected function storage address is taken as the transfer address. If yes, revising the calculated numerical fingerprint so that the revised numerical fingerprint belongs to a preset second numerical set, determining a function storage address associated with the revised numerical fingerprint from the function fingerprint mapping table, and taking the function storage address as the transit address; wherein the second numerical set includes numerical fingerprints respectively associated with function storage addresses of each trap function in the function fingerprint mapping table.

[0072] Optionally, when the target function is the trap function, the data processing module is specifically configured to: When the historical behavior parameter meets the low-risk behavior rule in the abnormal behavior rule, processing the system call parameter into a data format required by the hook entry function through the trap function, adding a preset abnormal label to the processed data, and sending the data with the abnormal label to the hook entry function.

[0073] Optionally, when the target function is the trap function, the device further comprises: When the historical behavior parameter meets the high-risk behavior rule in the abnormal behavior rule, the attack feedback module returns a pre-forged response result to the target process through the trap function, and issues an alarm in the target version of the Linux kernel.

[0074] Embodiment three The embodiment also provides a computer device, such as a smartphone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server, or a cabinet server (including a single server or a server cluster composed of multiple servers), which can execute programs. As shown in the figure, the computer device 40 of the embodiment at least includes but is not limited to a memory 401 and a processor 402 which can be connected to each other through a system bus. Figure 4 It should be noted that, Figure 4 Only the computer device 40 with components 401-402 is shown, but it should be understood that all the shown components are not required to be implemented, and more or fewer components can be alternatively implemented.

[0075] In this embodiment, the memory 401 (i.e., a readable storage medium) includes a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the memory 401 can be an internal storage unit of the computer device 40, such as a hard disk or a memory of the computer device 40. In other embodiments, the memory 401 can also be an external storage device of the computer device 40, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device 40. Of course, the memory 401 can also include both the internal storage unit and the external storage device of the computer device 40. In this embodiment, the memory 401 is generally used to store an operating system and various application software installed on the computer device 40. In addition, the memory 401 can also be used to temporarily store various data that have been output or will be output.

[0076] The processor 402 can be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip in some embodiments. The processor 402 is generally used to control the overall operation of the computer device 40.

[0077] Specifically, in this embodiment, the processor 402 is used to execute the program of the system call hijacking method compatible with multiple versions of Linux kernel stored in the memory 401.

[0078] The specific implementation process of the above method steps can be referred to Embodiment One, which will not be repeated here.

[0079] Embodiment Four This embodiment also provides a computer readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, a server, an App application store, etc., having a computer program stored thereon, which is used to implement the steps of the system call hijacking method compatible with multiple versions of Linux kernel when executed by a processor.

[0080] The specific embodiment process of the above method steps can be seen from Example 1, which is not repeated here.

[0081] It should be noted that in this paper, the term "includes", "contains" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or includes elements inherent to such process, method, article or device. Without more limitations, the element defined by the statement "includes a" does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0082] The above-mentioned embodiment number of the application is only for description, not representing the advantages and disadvantages of the embodiments.

[0083] Through the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment.

[0084] The above is only the preferred embodiment of the application, and does not limit the patent scope of the application. Any equivalent structure or equivalent process transformation using the content of the application specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the application.

Claims

1. A system call hijacking method compatible with multiple Linux kernel versions, characterized in that, A first hijacking channel and a second hijacking channel are pre-deployed in parallel within the target version of the Linux kernel. The first hijacking channel is adapted to Linux kernel versions that execute system calls via the system call table, and the second hijacking channel is adapted to Linux kernel versions that execute system calls via system call dispatch functions. The method includes: In response to a system call request, the system call request is hijacked to a pre-defined target address through a target hijacking channel that is actually active in the target version of the Linux kernel, and the corresponding target function is determined based on the target address; wherein, the target hijacking channel is either the first hijacking channel or the second hijacking channel; The target function organizes the system call parameters carried in the system call request into a preset data format required by the hook entry function, and sends the formatted data to the hook entry function. The hook entry function determines the security handling strategy for the system call request based on the formatted data.

2. The system call hijacking method compatible with multiple Linux kernel versions according to claim 1, characterized in that, When the target hijacking channel is the first hijacking channel, the step of hijacking the system call request to a pre-defined target address through the target hijacking channel that is actually active in the target version of the Linux kernel includes: Obtain the target system call number from the system call parameters; The system call table is read from the target version of the Linux kernel, and the target function pointer associated with the target system call number is determined from the system call table; wherein, when the first hijacking channel is deployed in the target version of the Linux kernel, the original pointer function associated with the target system call number in the system call table is modified to a pre-defined target pointer function; The system call request is hijacked to the target address by using the memory address pointed to by the target function pointer as the target address and jumping to the target address.

3. The system call hijacking method compatible with multiple Linux kernel versions according to claim 1, characterized in that, When the target hijacking channel is the second hijacking channel, the step of hijacking the system call request to a pre-defined target address through the target hijacking channel that is actually active in the target version of the Linux kernel includes: The target system call dispatch function is started in the target version of the Linux kernel; wherein, when the second hijacking channel is deployed in the target version of the Linux kernel, an Ftrace hook function is registered at the execution entry point of the target system call dispatch function based on the Ftrace framework in the target version of the Linux kernel; The Ftrace hook function modifies the value of the RIP register to a pre-defined target address and jumps to that target address to hijack the system call request to the target address.

4. The system call hijacking method compatible with multiple Linux kernel versions according to claim 1, characterized in that, The step of determining a security handling strategy for the system call request based on the formatted data through the hook entry function includes: The target system call number is obtained from the formatted data through the hook entry function. The status identifier of the target system call number is queried from the preset system call status table, and it is detected whether the status identifier indicates a temporary closed state. If so, the target original system call logic corresponding to the target hijacking channel is executed to obtain the system call result, and the system call result is returned to the requester who initiated the system call request; If not, then a security handling strategy for the system call request is determined based on the target system call number.

5. The system call hijacking method compatible with multiple Linux kernel versions according to claim 4, characterized in that, The step of determining the security handling strategy for the system call request based on the target system call number includes: Obtain all client registry entries; wherein, the client registry entries include each system call number to be intercepted and the pre-interception callback function pointer and / or post-interception callback function pointer associated with each system call number to be intercepted, wherein the pre-interception callback function pointer is the callback function pointer executed before the target original system call logic is called, and the post-interception callback function pointer is the callback function pointer executed after the target original system call logic is called; Extract all callback function pointers associated with the target system call number from all the obtained client registry entries; When the extracted callback function pointer contains a pre-interception callback function pointer, the callback function pointed to by the pre-interception callback function pointer is called to detect whether the system call request meets the security requirements specified by the callback function based on the formatted data, obtain the pre-interception detection result, and determine whether to execute the target original system call logic based on the pre-interception detection result; When the extracted callback function pointer does not contain the previous intercepted callback function pointer, the original system call logic of the target is executed to obtain the system call result.

6. The system call hijacking method compatible with multiple Linux kernel versions according to claim 5, characterized in that, The step of determining the security handling strategy for the system call request based on the target system call number further includes: When the extracted callback function pointer contains a post-interception callback function pointer, the callback function pointed to by the post-interception callback function pointer is called to check whether the system call result meets the security requirements specified by the callback function, obtain the post-interception detection result, and determine whether to return the system call result to the requester based on the post-interception detection result; If the extracted callback function pointer does not contain a post-interception callback function pointer, the system call result is returned to the requester.

7. A system call hijacking device compatible with multiple Linux kernel versions, characterized in that, A first hijacking channel and a second hijacking channel are pre-deployed in parallel within the target version of the Linux kernel. The first hijacking channel is adapted to Linux kernel versions that execute system calls via the system call table, and the second hijacking channel is adapted to Linux kernel versions that execute system calls via system call dispatch functions. The apparatus includes: The data hijacking module is used to respond to system call requests by hijacking the system call requests to a pre-defined target address through a target hijacking channel that is actually active in the target version of the Linux kernel, and determining the corresponding target function based on the target address; wherein, the target hijacking channel is either the first hijacking channel or the second hijacking channel; The data processing module is used to process the system call parameters carried in the system call request into a preset data format required by the hook entry function through the target function, and send the processed data to the hook entry function; The security detection module is used to determine the security handling strategy for the system call request based on the formatted data through the hook entry function.

8. The system call hijacking device compatible with multiple Linux kernel versions according to claim 7, characterized in that, The security detection module is specifically used for: The target system call number is obtained from the formatted data through the hook entry function. The status identifier of the target system call number is queried from the preset system call status table, and it is detected whether the status identifier indicates a temporary closed state. If so, the target original system call logic corresponding to the target hijacking channel is executed to obtain the system call result, and the system call result is returned to the requester who initiated the system call request; If not, then a security handling strategy for the system call request is determined based on the target system call number.

9. A computer device, the computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, is used to implement the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it is used to implement the steps of the method according to any one of claims 1 to 6.

Images