Verifying the correctness of intercepted system calls

Abstract

A system, method and computer program product for monitoring programs, processes and applications is provided. [Solution] First, a system call related to a process is received. Then, from a modified system call table of an operating system, (i) a modified handler corresponding to the received system call and (ii) an unmodified handler corresponding to the received system call are identified. Next, in parallel, the correctness of the process is analyzed using the modified handler and the system call, and the system call is implemented by the unmodified handler. Based on the analysis, the implementation of the system call is maintained or stopped.

Description

[Technical field]

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 269,047, filed March 9, 2022.

[0002] This application claims priority under 35 U.S.C. Sections 119 and 365 of Indian Patent Application No. 202241001242, filed on January 10, 2022.

[0003] The entire teachings of the above application are incorporated herein by reference. [Background technology]

[0004] Cyber ​​attacks are becoming more sophisticated with every passing day. They are often targeted at exploiting specific vulnerabilities in specific programs, processes and applications. Although there are various methods and tools to protect against such attacks, the existing methods and tools are not enough. Summary of the Invention [Problem to be solved by the invention]

[0005] Embodiments provide systems, methods and computer program products for monitoring programs, processes and applications. [Means for solving the problem]

[0006] One exemplary embodiment is directed to a method for monitoring a process, comprising: receiving a system call related to the process; identifying a modified handler corresponding to the received system call and an unmodified handler corresponding to the received system call in a modified system call table of an operating system; analyzing the correctness of the process with the modified handler and the system call in parallel; and performing the system call with the unmodified handler; and maintaining or stopping the performance of the system call based on the analysis.

[0007] In one embodiment, the received system call is clone, fork, vfork, execve or execveat.

[0008] In an embodiment, the modified system call table may further be generated. In one embodiment, in generating the modified system call table, for at least one system call in the original system call table of the operating system, a correspondence between a modified handler and the at least one system call is added to a memory.

[0009] In one embodiment, the system call includes at least one of a file name, a command line argument, and a variable value. In such an embodiment, the analysis of the legitimacy of the process with the modified handler and the system call determines the legitimacy of at least one of the file name, the command line argument, and the variable value.

[0010] In another embodiment, maintaining or preventing performance of the system call based on the analysis includes maintaining performance of the system call if the analysis determines that the process is legitimate and taking protective action if the analysis determines that the process is invalid. In one embodiment, the protective action includes terminating the process.

[0011] Other exemplary embodiments are directed to a computer system comprising a processor and a memory having computer code instructions stored thereon, the computer code instructions configuring the processor and the memory to cause the system to implement any embodiment or combination of embodiments described herein.

[0012] Yet another embodiment is directed to a computer program product comprising one or more non-transitory computer readable storage devices and program instructions stored on at least one of the one or more storage devices that, when loaded and executed by a processor, cause a device coupled to the processor to implement any embodiment or combination of embodiments described herein.

[0013] The foregoing will become apparent from the following more particular description of exemplary embodiments as illustrated in the accompanying drawings. The same reference numerals refer to the same structures / components throughout the different views. The drawings are not necessarily to scale, rather emphasis is placed upon illustrating the embodiments. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a flow diagram of a method for monitoring a process according to one embodiment. [Diagram 2] 1 is a simplified diagram of a system for monitoring a process in accordance with an illustrative embodiment; [Diagram 3] FIG. 1 illustrates a digital processing environment, such as a computer network, in which embodiments may be implemented. [Figure 4] FIG. 4 illustrates an example of the internal structure of a computer in the environment of FIG. 3. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Exemplary embodiments are described below, each of which provides improved functionality for monitoring computer processes.

[0016] A challenge that modern security solutions face when trying to thwart attacks is the latency between (i) exploitation of a system and (ii) detection of the attack by the current solution. An attacker can execute a highly malicious process (e.g., ransomware) within milliseconds of gaining access to a vulnerable machine. Even with improved response times for security solutions, it is nearly impossible to prevent a determined attacker from executing a malicious process once he has gained access to a machine.

[0017] Modern security solutions need to stop malicious processes before they begin to execute; that is, a zero dwell time solution is desired. This is where embodiments, which may be referred to herein as a "process monitoring engine," come in. Specifically, embodiments provide the ability to identify malicious processes and stop them before they can begin to execute, thereby preventing an attacker from executing malicious code.

[0018] Attempts have been made to provide protection that brings dwell time to zero or close to zero, but existing solutions are not sufficient.

[0019] [kprobes]

[0020] One such existing solution is kprobes. With kprobes one can install pre- and post-handlers for any kernel instruction, as well as handlers for function entry and function return. The handlers can access and modify registers. This gives the functionality the opportunity to both monitor and modify ongoing processes. SystemTap is an example of a dynamic instrumentation tool for the Linux kernel, and uses kprobes internally by default.

[0021] kprobes is just a tool to set breakpoints at specific places in the kernel: to get the values ​​of function arguments or local variables, you need knowledge of exactly where on the stack and in which registers the function arguments or local variables are located.

[0022] The cost of placing a breakpoint is high, even if it is a one-time operation. Although breakpoints do not affect the rest of the function, their processing cost is also relatively high. Fortunately, the jump optimizations implemented in the x86_64 architecture can significantly reduce the cost of using kprobes. However, the cost of kprobes is still higher than the cost of modifying the system call table (as implemented in each implementation).

[0023] Kprobes is interrupt based and manipulates processor registers. Therefore, it is necessary to disable preemption of all handler executions for synchronization purposes. This imposes some restrictions on the handlers: existing approaches cannot wait on handlers, i.e. they cannot allocate large amounts of memory, do I / O, sleep on semaphores or timers, etc.

[0024] [eBPF (Extended Berkeley Packet Filter)]

[0025] eBPF (extended Berkeley Packet Filter) runs sandboxed programs within the operating system. This allows application developers to add functionality to the operating system at runtime by running eBPF programs. The operating system then ensures safety and execution efficiency as if the program had been compiled natively by using a just-in-time (JIT) compiler and verification engine. SystemTap itself has the ability to inject custom code through the eBPF backend.

[0026] However, eBPF also has limitations. The biggest limitation of eBPF is that it is limited to the latest version of the Linux kernel. To make the most of eBPF, the kernel version must be 4.4 or higher. This makes it difficult to implement in older Linux distributions that are still in use. In addition, the size of an eBPF program is limited to a maximum of 4096 bytes. This ensures that the program will terminate without falling into an infinite loop. This also limits the resources that the program can access and the functions that the program can achieve. Therefore, eBPF programs tend to be extremely small.

[0027] Therefore, existing features such as kprobes and eBPF are insufficient as a solution to provide zero dwell time process monitoring. Each embodiment solves these problems and improves the monitoring capabilities of systems and processes.

[0028] 1 is a flow diagram of an example embodiment of a method 100. The method 100 begins by receiving a system call related to a process in step 101. Then, in step 102, identifying a modified handler corresponding to the received system call from a modified system call table of an operating system, as well as identifying an original handler corresponding to the received system call. In parallel, in step 103, analyzing the correctness of the process using the modified handler and the system call, and implementing the system call using the original handler. Then, in step 104, maintaining or stopping implementation of the system call based on the analysis.

[0029] In one embodiment, the system call received in step 101 is clone, fork, vfork, execve, or execveat. Note that although the embodiments are described herein in the context of the Linux operating system, the embodiments are not limited to the Linux operating system and may be implemented in any operating system that uses a system call table.

[0030] An embodiment of method 100 may further include generating a modified system call table. In such an embodiment of method 100, generating the modified system call table includes adding to memory a correspondence between a modified handler and the at least one system call in the original system call table of the operating system. In one embodiment, the modified system call table is generated by creating a "jump" table that jumps from the original system call to the "modified" call and back to the original system call.

[0031] In one embodiment of method 100, the system call includes at least one of a file name, a command line argument, and a variable value. In such an embodiment, in step 103, the analysis of the legitimacy of the process with the modified handler and the system call determines the legitimacy of at least one of the file name, the command line argument, and the variable value. In an exemplary embodiment, the origin of the file, as indicated by the file name, is verified. In one embodiment, a command string is verified to ensure that the command string appearing in the command line of the child process was not supplied by an end user. If so, such an embodiment concludes that an attacker may have influenced the results.

[0032] In another embodiment of method 100, in step 104, maintaining or stopping performance of the system call based on the analysis includes maintaining performance of the system call (103) if the analysis (103) determines that the process is legitimate and implementing protective measures if the analysis determines that the process is invalid. In one embodiment, the protective measures include any desired protective measures. For example, in one embodiment, the protective measures terminate the process.

[0033] In many operating systems, communication between a process and the operating system (OS) is performed by system calls. Typically, a system call is made when a user mode process requests access to a resource. In other words, the process requests the kernel to provide resources via a system call. In terms of the program execution process, a user mode application requests the kernel for permission and resources to run the program. Since processes are created by the OS, malicious attackers who have taken control of user mode also need to use these system calls to run their own malicious programs.

[0034] Each embodiment exploits the fact that an attacker must use system calls to monitor processes. In an exemplary embodiment that runs on the Linux OS, the process verification / monitoring is performed according to one or more system calls in a set of system calls. In such an embodiment, the set of system calls are system calls such as clone, fork, vfork, execve, execveat, etc., that are involved in the creation of processes. Any of the above system calls are used to create a new process. In an embodiment, the above system calls are instrumented before the request reaches the kernel. This allows the process to be analyzed and terminated before it can cause data damage. This is done using the system call table.

[0035] (System Call Table)

[0036] Every time a distribution (e.g., a Linux distribution) boots, a system call table is loaded into kernel memory. Essentially, the system call table is a table of function pointers that directs system calls made from user space to the appropriate kernel function to process the system call. For example, if a process uses the "read" system call from user space, the kernel calls the function that corresponds to the "read" system call, i.e., the "sys_read" function.

[0037] (System call table hijacking)

[0038] Embodiments (e.g., method 100, etc.) monitor processes by hijacking (i.e., modifying) the system call table. In one embodiment, the address of the system call table is first located using the "kallsyms_lookup_name" function. After the address of the system call table is located, such embodiments place a pointer in the system call table according to the system call number defined in the "linux / syscalls.h" header file. Then, embodiments overwrite the system call table with a desired function so that any desired system call can be intercepted.

[0039] (Intercepting process creation)

[0040] By hijacking the system call table as described above, embodiments can intercept any system call from user space. By intercepting the system call, embodiments can verify the legitimacy of the process requesting the system call.

[0041] In one embodiment, not all system calls are subject to interception, but rather system calls related to process creation, such as the "execve" system call. In such an embodiment, the "execve" system call is intercepted when the "execve" system call is made. In one embodiment, an analysis of the process that made the "execve" system call is performed accordingly.

[0042] 2 is a block diagram of a system 220 illustrating such an embodiment. Specifically, the system 220 illustrated in FIG 2 may be used to implement zero residence time process monitoring according to one embodiment.

[0043] The system 220 has user space code 221 and kernel code 222. The user space code 221 includes an endpoint client 223, and the kernel code 222 includes a hijacked system call driver 224, an operating system 225, and an analysis engine 226. In one embodiment, shared memory is used between the analysis engine 226 and the user space code 221.

[0044] In one non-limiting exemplary embodiment of system 220, in step 1, endpoint client 223 sends an "execve" system call to kernel 222. In one embodiment, the "execve" system call takes three types of arguments: a filename (i.e., executable code (to be executed)), command line arguments, and environment variables. The "execve" system call is intercepted by hijacked system call driver 224. In such an embodiment, this stage proceeds to two parallel steps, namely, step 2a and step 2b. In step 2a, the system call is sent to operating system 225 (as per standard system call response procedure). In particular, the unmodified function corresponding to execve is called with the unchanged arguments. Operating system 225 grants the requested resource to system call driver 224 in step 3. Meanwhile (in parallel with the function of step 2a), in step 2b, hijacked system call driver 224 calls a custom function in the kernel module. The custom function is either called by hijacking a system call table that stores the custom function, or is pointed to via a mapping between the execve system call and the custom function. The custom function is implemented by analysis engine 226, which extracts the filename and arguments from the execve system call to verify the integrity of the code being executed (e.g., as seen from the filename and arguments). Thus, system 220 performs two parallel passes: a traditional pass to respond to the system call (steps 2a and 3), and a pass to determine the integrity of the code being executed (step 2b).

[0045] Based on the results of the analysis performed by the analysis engine 226, the system 200 performs, in step 4, the provision of the resource to the endpoint 223 if the given resource is the result of normal execution (steps 2a and 3). If not, the system 220 takes some protective action 227. This protective action may consist of terminating the process 223 and performing cleanup.

[0046] (Application examples and results)

[0047] In the following, application examples and the results obtained by the application examples will be described.

[0048] The application used the hijacked system call table described in this document. Decisions about process reservation were made by a concurrently running user space application. Memory was shared between the kernel module and the user space application by mapping memory allocated by the kernel module into the address space of the user space application using the "mmap" system call. Data in this memory was shared by circular buffers.

[0049] The overall implementation flow according to one embodiment is described below. An incoming or outgoing system call is intercepted and the data is stored in a "syscall" object and added to the "system call ring buffer". The thread then waits until a decision is made. A concurrently running user space application detects the entry and starts to process it. The user space application analyzes the calling thread's system call data (arguments and return value) and past system call data to decide whether to kill the thread or leave it alone. This decision is then stored in a "response" object and added to the "response ring buffer". Another kernel thread then retrieves the response and, depending on the content of the response, either allows the calling thread to continue or terminates it.

[0050] To analyze the impact of the kernel module and its cost-effectiveness, we ran some benchmark tests both with and without the kernel module. The benchmark we applied to this driver was a simple one that only considered the execve system call. The benchmark was run by calling execve 10 6 This means that the total number of execve system calls made is 5x10 6 In testing this benchmark, I used perf to get the CPU clock consumed by the benchmark, which gave me the following results:

[0051] [Table 1]

[0052] As can be seen from Table 1, the difference (%) due to the application of the embodiment (i.e., the presence of the hijacked system call driver) is extremely small. In other words, the impact of the embodiment on CPU resource consumption is extremely small, and there is still room to add appropriate code.

[0053] Each embodiment inserts code into the system call path, so another statistic that represents the impact of the embodiments is the time it takes to complete a system call with a driver. Table 2 below summarizes the time taken without a driver, i.e., without the embodiments described herein. Table 3 below summarizes the time taken with a system call driver, i.e., with the embodiments described herein:

[0054] [Table 2]

[0055] [Table 3]

[0056] From Tables 2 and 3, it can be seen that the embodiment slightly impacts the time it takes to perform a system call, but this impact is well within an acceptable range.

[0057] Embodiments provide significant advantages over existing methods. By hijacking the system call table, embodiments can capture (and store for analysis) the arguments and return values ​​of every traced system call. In one embodiment, code (such as code in analysis engine 226 and / or endpoints 223) runs with preemption enabled. This allows embodiments to use semaphores, allocate large chunks of memory, handle input / output to make the code more dynamic, and protect critical sections.

[0058] Moreover, modifying the system call table is extremely cost-effective. Also, the embodiments are applicable to both old and new versions of the Linux kernel. Moreover, since the embodiments overwrite the system call table itself, there is no constraint on the size of the code to be injected. Moreover, since the decision is made inside the kernel, there is no need for context switching and / or waiting for a response from user space.

[0059] (Computer Assisted)

[0060] FIG. 3 illustrates a digital processing environment, such as a computer network, in which embodiments of the present disclosure may be implemented.

[0061] One or more client computers / devices 50 and one or more server computers 60 provide processing, storage, and input / output devices for executing application programs and the like. The client computers / devices 50 may also be connected to other computing devices, such as other client devices / processes 50, server computers 60, etc., via a communications network 70. The communications network 70 may be part of: a remote access network; a global network (e.g., the Internet); a collection of computers around the world; a local area network or a wide area network; and gateways that currently communicate with each other using their respective protocols (TCP / IP, Bluetooth, etc.). Other electronic device / computer network architectures are also suitable.

[0062] The client computers / devices 50 and / or the servers 60 may be configured to perform the embodiments described herein (e.g., method 100, etc.) either alone or in cooperation with each other. The server computers 60 may be part of a cloud network 70 rather than being separate server computers.

[0063] FIG. 4 is a diagram illustrating an example of the internal structure of a computer (e.g., client processor / device 50, server computer 60, etc.) in the computer system of FIG. 3. Each computer 50, 60 includes a system bus 79, which is a series of hardware lines used to transfer data between components of a computer or processing system. The system bus 79 is essentially a shared conduit connecting the components of a computer system (e.g., processor, disk storage, memory, input / output ports, network ports, etc.) and allowing information to be transferred between the components. Attached to the system bus 79 is an input / output (I / O) device interface 82 for connecting various input / output devices (e.g., keyboard, mouse, display, printer, speakers, etc.) to the computer 50, 60. A network interface 86 allows the computer to connect to various other devices attached to a network (e.g., network 70 of FIG. 3, etc.). The memory 90 provides volatile storage of computer software instructions 92 and data 94 used to implement embodiments of the present disclosure (e.g., method 100, etc.). Disk storage 95 provides non-volatile storage of computer software instructions 92 and data 94 utilized in implementing embodiments of the present disclosure. Central processing unit 84 is also attached to system bus 79 and executes computer instructions.

[0064] The embodiments or aspects of the embodiments may be implemented in hardware, such as, but not limited to, hardware circuits, firmware, or software. If implemented in software, the software may be stored on any non-transitory computer-readable medium configured to cause a processor to load instructions for the software, or portions thereof, and the processor is configured to execute the instructions to operate or cause the device to operate in the manner described herein.

[0065] Furthermore, although hardware, firmware, software, routines, or instructions may be described herein as performing certain operations and / or functions of a data processor, it will be understood that such description contained herein is for convenience only, and that such operations actually result from a computing device, processor, controller, or other apparatus executing the firmware, software, routines, instructions, etc.

[0066] In addition, the number of components in the flow diagrams, block diagrams, and network diagrams may be increased or decreased, the arrangement may be changed, and the representation may be changed, but it should be understood that the contents of the block diagrams and network diagrams showing the implementation of the embodiment, as well as the number of block diagrams and network diagrams, may need to be predetermined depending on the mode of implementation.

[0067] That is, alternative embodiments may be implemented using different computer architectures and / or physical computers and / or virtual computers and / or cloud computers and / or any combination thereof. Accordingly, the data processors described herein are for illustrative purposes only and are not limiting of the embodiments.

[0068] The entire teachings of each patent, published patent application and publication cited herein are incorporated by reference.

[0069] Although exemplary embodiments have been specifically shown and described, those skilled in the art will recognize that various changes in form and detail may be made therein without departing from the scope of the embodiments encompassed by the appended claims.

Claims

1. 1. A method for monitoring a process, comprising: receiving a system call relating to a process; identifying, from a modified system call table of an operating system, (i) a modified handler corresponding to the received system call, and (ii) an unmodified handler corresponding to the received system call; In parallel, (i) analyzing the correctness of the process using the modified handler and the system call, and (ii) executing the system call using the unmodified handler; maintaining or stopping the performance of the system call based on the analysis; A method comprising:

2. 2. The method of claim 1, wherein the received system call is clone, fork, vfork, execve, or execveat.

3. The method of claim 1 further comprising: generating the modified system call table; A method comprising:

4. 4. The method of claim 3, wherein the step of generating the modified system call table includes the substep of adding to memory, for at least one system call in the original system call table of the operating system, a correspondence between a modified handler and the at least one system call.

5. 2. The method of claim 1, wherein the system call includes at least one of a file name, a command line argument, and a variable value.

6. 6. The method of claim 5, wherein the step of analyzing the validity of the process with the modified handler and the system calls includes the substep of determining the validity of at least one of the file name, the command line arguments, and the variable values.

7. 2. The method of claim 1, wherein the step of maintaining or stopping performance of the system call based on the analysis includes a substep of maintaining performance of the system call if the analysis determines that the process is legitimate, and a substep of implementing protective measures if the analysis determines that the process is invalid.

8. The method of claim 7 , wherein the protective action is to terminate the process.

9. A processor; a memory having computer code instructions stored therein; A system comprising: The computer code instructions cause the processor and the memory to: A procedure for receiving system calls related to a process, identifying from a modified system call table of an operating system: (i) a modified handler corresponding to the received system call; and (ii) an unmodified handler corresponding to the received system call; In parallel, (i) analyzing the correctness of the process using the modified handler and the system call, and (ii) performing the system call using the unmodified handler; and maintaining or stopping said performance of said system call based on said analysis; A system that is configured to run

10. 10. The system of claim 9, wherein the received system call is clone, fork, vfork, execve, or execveat.

11. 10. The system of claim 9, wherein the computer code instructions further cause the processor and the memory to: generating said modified system call table; A system that is configured to run

12. 12. The system of claim 11, wherein the computer code instructions cause the processor and the memory to generate the modified system call table for the system, the processor and the memory comprising: a substep of adding to a memory, for at least one system call in a pre-modification system call table of the operating system, a correspondence between the pre-modification handler and the at least one system call; A system that is configured to run

13. 10. The system of claim 9, wherein the system call includes at least one of a file name, a command line argument, and a variable value.

14. 14. The system of claim 13, wherein the computer code instructions cause the processor and the memory to, in the step of analyzing the correctness of the process using the modified handler and the system call, perform the following steps: a sub-step of determining the validity of at least one of the file name, the command line arguments, and the variable values; A system that is configured to run

15. 10. The system of claim 9, wherein the computer code instructions cause the processor and the memory to instruct the system to: maintain or stop performing the system call based on the analysis; a substep of maintaining execution of the system call if the analysis determines that the process is legitimate; and a substep of implementing protective measures if said analysis determines that said process is invalid; A system that is configured to run

16. 16. The system of claim 15, wherein the protective action is to terminate the process.

17. one or more non-transitory computer readable storage devices; program instructions stored in at least one of the one or more storage devices; 1. A computer program product comprising: program instructions which, when loaded into a processor and executed, cause a device coupled to the processor to: A procedure for receiving system calls related to a process, identifying, in a modified system call table of the operating system, (i) a modified handler corresponding to the received system call, and (ii) an unmodified handler corresponding to the received system call; In parallel, (i) analyzing the correctness of the process using the modified handler and the system call, and (ii) performing the system call using the unmodified handler; and maintaining or stopping said performance of said system call based on said analysis; A computer program product that causes the

18. 18. The computer program product of claim 17, wherein the program instructions, when loaded and executed by the processor, cause the device coupled to the processor to: generating the modified system call table by adding to a memory a correspondence between a modified handler and at least one system call in the pre-modification system call table of the operating system; A computer program product that causes the

19. 18. The computer program product according to claim 17, wherein the program instructions, when loaded into and executed by the processor, instruct the device connected to the processor to analyze the validity of the process using the changed handler and the system call: a sub-step of determining the validity of at least one of the file name, the command line arguments, and the variable values; A computer program product that causes the

20. 20. The computer program product of claim 17, wherein the program instructions, when loaded and executed by the processor, cause the device coupled to the processor to maintain or stop making the system call based on the analysis in the process of: a substep of maintaining execution of the system call if the analysis determines that the process is legitimate; and a substep of implementing protective measures if said analysis determines that said process is invalid; A computer program product that causes the

Images