Patent Application
20220092171
Embodiments described herein generally relate to detecting and/or neutralizing malicious code or other security threats on computer systems.
Modern cyber attackers employ a variety of attack patterns, ultimately aimed at running the attacker's code on the target machine without being noticed. The traditional attack pattern requires an executable file that arrives at the target machine through email, through a download from a website, from a neighboring local host, or from some sort of removable media. When the malicious file gets executed, it spawns a full-fledged process of its own. Subsequently, the malicious process may inject some form of code into the memory-space of another running process.
Newer attack patterns are based on vulnerabilities found in various useful programs, such as ADOBE® ACROBAT®. In the case of ADOBE® ACROBAT®, the malicious code (or “payload”) is embedded within a portable data file (PDF) document. The PDF document also contains a chunk of malformed data, designed to exploit the given vulnerability. This chunk is crafted to cause some kind of overflow or similar exception when the file is being read by the vulnerable program. When the program or the operating system seeks to recover, it returns, instead, to a tiny piece of machine code (or primary shellcode) supplied by the malformed data chunk. This primary shellcode takes control of the running program (i.e., the process), completing the so-called “exploit” of the given vulnerability. Subsequently, the primary shellcode loads whatever payload (special-purpose malicious code) is available, into the context of the running process.
In a so-called ‘remote’ attack, the vulnerable program is associated with some network port, either as a server or as a client. The exploit happens when the vulnerable program tries to process a chunk of malformed input, essentially in the same manner as described above. In this case, when the primary shellcode takes control of the running process, it may choose to download secondary shellcode or payload from the network. In both the local and the remote vulnerability-based attacks, the malicious code running within the originally breached process may proceed by injecting code into the running processes of other programs.
Traditional malware-detection tools, such as signature-based antivirus products, are ineffective against such attacks due to the fact these attacks take form in memory, thereby resulting in no visible signature for the malicious file. Conventional runtime activity monitoring, based on the behavioral patterns of such attacks, fail to defend against attacks due to the fact that such attacks morph themselves and change their behavior, thereby making it difficult to define strict rules that lead to the identification of malicious behavior. Accordingly, conventional runtime activity monitoring has some major drawbacks, including: (a) it may miss a new, unknown pattern; (b) detection may occur too late for the monitoring program to take an effective preventive action; and (c) the required computational resources may affect the system's performance. In general, these tools rely on some prior knowledge of an attack pattern or a vulnerability, and will miss so-called “zero-day” attacks (new forms of attack, which exploit unknown vulnerabilities in the target software), whether the attack is remote or local.
Protective techniques such as Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) are used in modern computerized systems to prevent malicious-code attacks. However, recent sophisticated attacks, such as attacks that are able to deduce the location of desired functionality based on relative addressing, have demonstrated the limitations of ASLR and DEP.
Methods, systems, and apparatuses are described for detecting and/or neutralizing malicious code or other security threats on computer systems, substantially as shown in and/or described herein in connection with at least one of the figures, as set forth more completely in the claims.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments of the present invention and, together with the description, further serve to explain the principles involved and to enable a person skilled in the relevant art(s) to make and use the disclosed technologies.
The features and advantages of the disclosed technologies will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
The following detailed description refers to the accompanying drawings that illustrate exemplary embodiments of the present invention. However, the scope of the present invention is not limited to these embodiments, but is instead defined by the appended claims. Thus, embodiments beyond those shown in the accompanying drawings, such as modified versions of the illustrated embodiments, may nevertheless be encompassed by the present invention.
References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” or the like, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
Numerous exemplary embodiments are now described. Any section/subsection headings provided herein are not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section/subsection. Furthermore, it is contemplated that the disclosed embodiments may be combined with each other in any manner.
Malicious code (e.g., malware), including injected shellcode, relies on some system functions provided by an operating system to perform its exploits. In general, malicious code call such functions explicitly, rather than using wrappers provided by system libraries, such as libc, in order conserve space.
Various approaches are described herein for, among other things, neutralizing and/or detecting attacks by such malicious code. This may be achieved, for example, by modifying (or “morphing”) certain aspects of an operating system. For example, a system call table storing pointers to system functions may be duplicated to create a shadow system call table. The original system call table may be modified with traps that result in the neutralization of processes that call protected system functions via the original system call table, whereas processes that call protected system functions via the shadow system call table are enabled to execute properly. In order for valid applications to operate with the shadow system call table, index numbers corresponding to the different system function calls may be randomized in a system library that maintains function calls to such system functions. Valid applications may be patched in order to reference such randomized index numbers. During execution of such applications, a hooking function located at the system call entry point, determines whether a system function call utilizes the randomized index number. If so, the flow of execution is routed to the shadow system call table. If not, the flow of execution is routed to the original system call table containing the traps. Thus, valid application processes correctly reference the requested system calls. In contrast, malicious processes, such as shellcode, will not be patched and will continue to reference the original, non-randomized index numbers, thereby resulting in their neutralization.
In particular, a method in a computing device is described herein. The method includes generating a random seed; modifying an index number corresponding to a system function provided by an operating system, and maintained by a system library of the operating system, based on the random seed; duplicating an original system call table provided by the operating system to generate a shadow system call table, the original system call table and the shadow system call table each associating an unmodified version of the index number with a function pointer that references the system function; modifying the original system call table to associate the unmodified version of the index number with a function pointer that references a trap function instead of the function pointer that references the system function; and generating a hooking function that: causes code issuing a system function call with the modified index number to utilize the shadow system call table, thereby causing the system function to execute; and causes code issuing a system function call with the unmodified version of the index number to utilize the original system call table, thereby causing the trap function to execute, the trap function being configured to neutralize the code that issues the system function call with the unmodified version of the index number.
In one embodiment of the foregoing method, the hooking function is generated at a system call entry point at which a context of a processor of the computing device, that executes the operating system, switches from user mode to kernel mode.
In one embodiment of the foregoing method, the method further comprises parsing code of an application stored on the computing device to detect a first instruction configured to initiate a request for the system function; determining a location in the code of the application to be patched to reference the modified index number; suspending the application; patching the application to reference the modified index number; and resuming the application after said patching is completed.
In one embodiment of the foregoing method, said determining comprises: analyzing a portion of the code that precedes the first instruction to determine a second instruction that specifies the unmodified version of the index number; and determining a location of the second instruction.
In one embodiment of the foregoing method, said patching comprises: replacing the unmodified version of the index number specified by the second instruction with the modified index number.
In one embodiment of the foregoing method, the method further comprises: generating a second random seed after a predetermined period of time expires; and modifying the index number corresponding to the system function based on the second random seed.
In one embodiment of the foregoing method, the unmodified version of the index number of the shadow system call table is further associated with a logging function that is configured to collect information associated with an application that is caused to reference the shadow system call table by the hooking function.
In one embodiment of the foregoing method, the operating system is a Linux-based operating system.
A system is also described herein. The system includes one or more processing units and a memory coupled to the one or more processing units, the memory storing program code for execution by the one or more processing units. The program code comprising a random seed generator configured to: a random seed generator configured to: generate a random seed; and a system morpher configured to: duplicate an original system call table provided by the operating system to generate a shadow system call table, the original system call table and the shadow system call table each associating an unmodified version of the index number with a function pointer that references the system function; modify the original system call table to associate the unmodified version of the index number with a function pointer that references a trap function instead of the function pointer that references the system function; and generate a hooking function that: causes code issuing a system function call with the modified index number to utilize the shadow system call table, thereby causing the system function to execute; and causes code issuing a system function call with the unmodified version of the index number to utilize the original system call table, thereby causing the trap function to execute, the trap function being configured to neutralize the code that issues the system function call with the unmodified version of the index number.
In one embodiment of the foregoing system, the hooking function is generated at a system call entry point at which a context of the one or more processing units of the computing device, that executes the operating system, switches from user mode to kernel mode.
In one embodiment of the foregoing system, the program code further comprising: a code parser configured to: parse code of an application stored on the computing device to detect a first instruction configured to initiate a request for the system function; and determine a location in the code of the application to be patched to reference the modified index number; an application execution controller configured to: suspend the application; and a patcher configured to: patch the application to reference the modified index number, the application execution controller further configured to resume the application after said patching is completed.
In one embodiment of the foregoing system, said code parser is further configured to: analyze a portion of the code that precedes the first instruction to determine a second instruction that specifies the unmodified version of the index number; and determine a location of the second instruction.
In one embodiment of the foregoing system, said patcher is further configured to: replace the unmodified version of the index number specified by the second instruction with the modified index number.
In one embodiment of the foregoing system, the random seed generator is further configured to: generate a second random seed after a predetermined period of time expires; and the system morpher is further configured to: modify the index number corresponding to the system function based on the second random seed.
In one embodiment of the foregoing system, the unmodified version of the index number of the shadow system call table is further associated with a logging function that is configured to collect information associated with an application that is caused to reference the shadow system call table by the hooking function.
In one embodiment of the foregoing system, the operating system is a Linux-based operating system.
A computer-readable storage medium having program instructions recorded thereon that, when executed by a processing device, perform a method for modifying a computing process is further described herein. The method includes generating a random seed; modifying an index number corresponding to a system function provided by an operating system, and maintained by a system library of the operating system, based on the random seed; duplicating an original system call table provided by the operating system to generate a shadow system call table, the original system call table and the shadow system call table each associating an unmodified version of the index number with a function pointer that references the system function; modifying the original system call table to associate the unmodified version of the index number with a function pointer that references a trap function instead of the function pointer that references the system function; and generating a hooking function that: causes code issuing a system function call with the modified index number to utilize the shadow system call table, thereby causing the system function to execute; and causes code issuing a system function call with the unmodified version of the index number to utilize the original system call table, thereby causing the trap function to execute, the trap function being configured to neutralize the code that issues the system function call with the unmodified version of the index number.
In one embodiment of the foregoing computer-readable storage medium, the hooking function is generated at a system call entry point at which a context of a processor of the computing device, that executes the operating system, switches from user mode to kernel mode.
In one embodiment of the foregoing computer-readable storage medium, the method further comprising: parsing code of an application stored on the computing device to detect a first instruction configured to initiate a request for the system function; determining a location in the code of the application to be patched to reference the modified index number; suspending the application; patching the application to reference the modified index number; and resuming the application after said patching is completed.
In one embodiment of the foregoing computer-readable storage medium, said determining comprises: analyzing a portion of the code that precedes the first instruction to determine a second instruction that specifies the unmodified version of the index number; and determining a location of the second instruction.
As shown in
Accordingly, operating system 110 is shown as being stored in kernel space 128. Operating system 110 may manage one or more hardware components (e.g., processor(s) 102, main memory 104, secondary storage device(s) 106, etc.) and software executing on computer system 100. Example hardware components of computer system 100 are described in detail below in reference to
Operating system 110 may have one or more components that perform certain tasks relating to the execution of software on computer system 100. One such component is process loader 112. Process loader 112 is configured to initiate creation of a computing process (or “process”) 114 in main memory 104 and store process 114 in user space 126 of main memory 104. Process 114 is an instance of a computer program being executed by processor(s) 102. The computer program may comprise an application program (or “application”), a system program, or other computer program being executed by processor(s) 102. The computer program is embodied in instructions and/or data included in a binary image (e.g., binary image 116). In accordance with an embodiment, binary image 116 is formatted in accordance with an executable and linkable format (also known as the ELF format), although the embodiments described herein are not so limited.
To initiate creation of process 114, process loader 112 loads (or “maps”) binary image 116, which is stored in secondary storage device(s) 106, into an address space allocated for process 114 in main memory 104 based on information included in binary image 116. The binary image mapped into main memory 104 is represented in
As the program execution evolves, other component(s) of operating system 110 allocate various resources to process 114. The execution context of process 114 may comprise information about such resource allocation, a current state of the program execution, an instruction that is to be executed next, and other information related to the program execution. The computer program execution continues until processor(s) 102 execute a termination or halt instruction.
Operating system 110 may also load one or more libraries in user space 126, which are accessible by processes (e.g., process 114) loaded into user space 126 of main memory 104. An example of a library is a system library 120. System library 120 may be an implementation of the C standard library, such as, but not limited to libc, glibc, etc. System library 120 may comprise wrapper functions corresponding to system calls for system functions provided by the kernel of operating system 110. Applications may invoke a system call using the wrapper functions of system library 120 to access a system function. Generally, system functions are configured to create processes, perform network and/or file I/O, etc. However, system functions may be configured to perform many other functions. Examples of system functions include, but are not limited to, open( ), fork( ), read( ), write( ), printf( ), etc.
When a user application invokes a wrapper function, the wrapper function specifies a system call index value (stored via standard library 120 (e.g., hardcoded therein)) corresponding to the system call, initiates a request for the system call, and causes processor(s) 102 to switch its context from user mode to kernel mode, thereby moving its execution to kernel space 128. Wrapper functions may initiate a request for the system call and cause processor(s) 102 to switch its context via a particular assembly instruction (e.g., “syscall”, “sysenter” and/or the like), via invoking an interrupt (“int 0x80”) etc. Once processor(s) 102 are switched to kernel mode, execution reaches the system call entry point. At the system call entry point, the kernel of operating system 110 may validate the system call request and/or may locate the corresponding system function based on an index number corresponding to the system call, although it is noted that the operations that occur at a system call entry point may vary depending on the architecture of computer system 100 and/or the version of the kernel of operating system 110. Wrapper functions may specify the system call index number by storing the number in a register of processor(s) 102 (e.g., RAX, EAX, etc.). The register in which the index number is stored may vary depending on the architecture of processor(s) 102.
The kernel maintains a system call table 122. System call table 122 comprises a plurality of pointers that point to the system functions to be executed. Each of the pointers are indexed in accordance with a system call index number. For example,
Returning now to
To prevent the shellcode from executing properly, embodiments described herein modify (or “morph”) certain aspects of operating system 110 during run time. For example, operating system 110 may comprise an operating system protector 124. Operating system protector 124 may be configured to randomize the index numbers corresponding to the system functions maintained by system library 120 and duplicate system call table 122 to create a shadow system call table. The shadow system call table may comprise the function pointers to the various system calls. However, the original system call table is modified by operating system protector 124 such that the pointers (e.g., as shown in column 206 of
The trap functions may be configured to notify a user of a potential attack and/or suspend and/or terminate the process accessing such functions. Operating system protector 124 may be configured to execute upon computer system 100 booting up or on-demand, for example, may be launched by the user.
Subsection A describes techniques for morphing system call table 122 and creating a shadow system call table. Subsection B describes techniques for patching loaded applications to reference the pointers in the shadow system call table.
Random seed generator 304 may be configured to generate one or more random seeds 310 that are utilized to randomize index numbers for system functions maintained by system library 320. In accordance with an embodiment, random seed generator 304 may generate a single random seed that is utilized to randomize each of the index numbers. In accordance with another embodiment, random seed generator 304 may generate a particular random seed for each of a plurality of subsets (e.g., one or more) of the index numbers. It is noted that a higher level of complexity will be encountered by an attacker if index numbers are randomized using different random seeds rather than using a single random seed for each of the index numbers. It is further noted that random seed generator 304 may utilize any number of techniques to generate random seed(s) 310. It is noted that only the main instance of system library 320 is modified to include randomized index numbers and that a plurality of different applications and/or processes utilizes the main instance of the modified system library 320 during execution. Thus, it is not required to create multiple copies of system library 320.
After random seed(s) 310 are generated, system morpher 322 may issue a write command 325 that causes each of the index numbers maintained by system library 320 to be modified based on random seed(s) 310 to overwrite the function pointers stored in system call table 322. For instance, each of the original index numbers are combined with (e.g., added to) a particular random seed of random seed(s) 310. It is noted that the original index numbers may be modified by random seed(s) 310 in any manner and the modification techniques described herein are purely exemplary.
System morpher 306 may be configured to generate and/or add a hooking function 328 at system call entry point 326. For example, system morpher 306 may generate hooking function 328 and/or issue a write command 330 that inserts hooking function 328 at system call entry point 326. Hooking function 328 may be configured to determine whether a system call utilizes a randomized index number. For instance, hooking function 328 may determine whether the received index number is greater than random seed(s) 310. If hooking function 328 determines that the received index number is less than or equal to random seed(s) 310, hooking function 328 directs the flow of execution such that original system call table 328 is utilized. If hooking function 328 determines that the received index number is greater than random seed(s) 310, hooking function 328 directs the flow of execution such that shadow system call table 302 is utilized.
System morpher 306 may be configured to locate system call table 322 in memory (e.g., kernel space 128 of main memory 104, as shown in
After system call table 322 is located in memory, system morpher 306 duplicates it to generate a shadow system call table 302. For example, system morpher 306 may issue a write command 312 to allocate memory in main memory 104 for shadow system call table 302 and/or to copy the values (e.g., index numbers, symbol names, function pointers, etc.) from system call table 322 to shadow system call table 302.
System morpher 306 may then modify original system call table 322 to include traps that cause malicious processes utilizing the original, unmodified index numbers to be suspended and/or terminated. For instance,
It is noted that in certain embodiments, operating system protector 324 may operate in audit mode. When in audit mode, processes that reference non-randomized index numbers are resumed and not terminated. When resuming the process, operating system protector 324 causes the process to reference the corresponding randomized index number, thereby enabling the requested system call function to execute. The log may be subsequently analyzed to study the behavior of the process. If a determination is made that the process is malicious, the process will be blacklisted during subsequent executions, thereby causing the process to access trap functions and resulting in its termination. However, if a determination is made that the process is non-malicious, the process may be whitelisted. As explained in subsection B, whitelisted processes may be patched such that they reference the randomized index numbers of system library 320 during execution, rather than the non-randomized index numbers.
Referring again to
Shadow system call table 302 is a duplicate of system call table 322 before it was modified. Thus, shadow system call table 302 may comprise the original, unmodified index numbers. When hooking function 328 determines that an index number is greater than random seed(s) 310, hooking function 328 may subtract the value of random seed(s) 310 from the received index number and causes the flow of execution to provide the resulting index number (which corresponds to the unmodified version of the index number) to shadow system call table 302, rather than original system call table 322.
For example,
In accordance with an embodiment, a logging function may also be executed when a system function is accessed via a randomized index number. The logging function may collect information associated with an application or process that references the randomized index number. Such information may include, but is not limited to an identifier of the process (e.g., process ID), a timestamp at which the system function is called and/or executed, other processes that are related to the process (e.g., a father process, a sibling process, etc.), etc.
As will be described below in Subsection B, after system call table 322 is modified to point to trap functions, system library 320 is modified with the randomized index numbers, and system calls that utilize randomized index numbers are caused to reference shadow system call table 300, application(s) (e.g., mapped binary image 118, as shown in
In accordance with an embodiment, system morpher 306 may be configured to randomize index numbers maintained by system library 320 each time a particular event occurs. For instance, event determiner 308 may determine whether such an event occurs. The event may include an expiration of a predetermined time period. For instance, each time a predetermined time period expires (e.g., 10 minutes, 1 hour, 1 day), event determiner 308 may provide an indication 316 to system morpher 306 that indicates that the time period has expired. In response, system morpher 306 may request random seed generator 304 to generate new random seed(s) 310 and generate new randomized index numbers for system library 320. Alternatively, the event may also include detection of access to a trap function. In this case, hooking function 328 may provide an indication to event determiner 308 that indicates that a process has attempted to call a system function using a non-randomized index value and conclude that such a process is malicious. Event determiner 308 may determine that an attack is under way and, in response, may provide indication 310 to system morpher 306, which causes system morpher 306 to request new random seed(s) 310 and generate new randomized index numbers for system library 320, as described above. It is noted that event determiner 308 may cause system morpher 306 to generate new randomized index numbers upon detecting other types of events and that the events described herein are purely exemplary.
Accordingly, a computer system may be protected from malicious processes in many ways. For example,
Flowchart 600 begins with step 602. At step 602, a random seed is generated. For example, with reference to
At step 604, an index number corresponding to a system function provided by an operating system, and maintained by a system library of the operating system, is modified based on the random seed. For example, with reference to
In accordance with one or more embodiments, the operating system is a Linux-based operating system.
At step 606, an original system call table provided by the operating system is duplicated to generate a shadow system call table, the original system call table and the shadow system call table each associating an unmodified version of the index number with a function pointer that references the system function. For example, with reference to
At step 608, the original system call table is modified to associate the unmodified version of the index number with a function pointer that references a trap function instead of the function that references the system function. For example, with reference to
At step 610, a hooking function is generated that causes code issuing a system function call with the modified index number to utilize the shadow system call table, thereby causing the system function to execute and causes code issuing a system function call with the unmodified version of the index number to utilize the original system call table, thereby causing the trap function to execute, the trap function being configured to neutralize the code that issues the system function call with the unmodified version of the index number. For example, with reference to
In accordance with one or more embodiments, the hooking function is generated at a system call entry point at which a context of a processor of the computing device, that executes the operating system, switches from user mode to kernel mode. For example, with reference to
In accordance with one or more embodiments, a second random seed is generated after a predetermined period of time expires and the index number corresponding to the system function is modified based on the second random seed. For example, with reference to
In accordance with one or more embodiments, the unmodified version of the index number of the shadow system call table is further associated with a logging function that is configured to collect information associated with an application that is caused to reference the shadow system call table by the hooking function. For example, with reference to
After original system call table 322 is duplicated to generate shadow system call table 302, original system call table 322 has been modified to include traps, system library 320 has been modified to include randomized index numbers, operating system protector 324 may be configured to analyze binaries loaded in computer system 100 (e.g., binary image 116) to determine locations in which the binaries are to be patched in order to utilize the randomized index numbers, and therefore, shadow system call table 302.
For example,
Disassembler 714 may be configured to disassemble binary image 716 to generate disassembled code 708. Disassembled code 708 may comprise assembly-level instructions corresponding to source code of binary image 716. Disassembled code 708 may be stored in main memory 704 or on secondary storage device(s) 706.
Code parser 720 may be configured to parse disassembled code 708 to locate instructions that are used to initiate a request for a system function. For instance, in an embodiment in which binary image 716 is in a .ELF format, code parser 720 may parse the header (e.g., an .ELF header) of binary image 716 to retrieve the text section (e.g., .txt section) offset and/or size thereof of the text section of binary image 716. The text section comprises the assembly instructions. Based on the offset and/or size, code parser 720 may locate the assembly instructions and parses the text section for instructions configured to initiate a request for the system function. For each such instruction located, code parser 720 may analyze one or more instructions before the instruction to determine which system function is being called. For example, in an embodiment in which computer system 100 is based on an x86 architecture, the index corresponding to the desired system function call is stored in a register of processor(s) 120 (e.g., the RAX or EAX registers). Accordingly, code parser 720 may search for the last instruction preceding the requesting instruction that assigns a value to the register. For instance, consider the following example set of instructions:
mov RAX, 123
syscall
In this example, code parser 720 detects the ‘syscall’ instruction and traces the code back until an instruction manipulating the RAX register is found. In the foregoing example, code parser 720 finds an instruction that moves an immediate value ‘123’ to the RAX register. The value ‘123 corresponds to the index value of the desired system function to be called. Thus, code parser 720 determines that the code is calling the system function corresponding to index ‘123’.
In another example, consider the following instruction sequence:
mov RDI, 50
mov RAX, RDI
syscall
In this example, code parser 720 detects the ‘syscall’ instruction and traces the code back until an instruction manipulating the RAX register is found. In the foregoing example, code parser 720 finds an instruction that moves the value stored in the RDI register into the RAX register. At this point, code parser 720 still has not determined the system function that is to be called. Thus, code parser 720 continues to trace the instruction sequence backwards. The next instruction detected is the ‘mov RDI, 50’ instruction. This instruction stores the value ‘50’ into the RDI instruction. When analyzing this sequence of instructions collectively, code parser 720 determines that an index value of ‘50’ is stored in the RAX register, which corresponds to the index value of the desired system function to be called. Thus, code parser 720 determines that the code is calling the system function corresponding to index ‘50.’
In yet another example, consider the following instruction sequence:
mov RAX, 50
add RAX, 6
syscall
In this example, code parser 720 detects the ‘syscall’ instruction and traces the code back until an instruction manipulating the RAX register is found. In the foregoing example, code parser 720 find an instruction that adds the value ‘6’ with the value already stored in the RAX register. At this point, code parser 720 still has not determined the system function that is to be called, as it has not determined what value was already stored in the RAX register. Thus, code parser 720 continues to trace the instruction sequence backwards. The next instruction detected is the ‘mov RAX, 50’ instruction. This instruction stores the value ‘50’ into the RAX instruction. When analyzing this sequence of instructions collectively, code parser 720 determines that an index value of ‘56 is stored in the RAX register, which corresponds to the index value of the desired system function to be called. Thus, code parser 720 determines that the code is calling the system function corresponding to index ‘56.’
For each system function call determined via the foregoing code parsing process, information associated with the function call is stored in cache 702. The information stored in cache 702 may include, but is not limited to, the offset of the instruction that assigns the index to the register designated for storing system function index numbers (e.g., RAX) and/or the file(s) of binary image 716 in which the instructions are located. Cache 702 may be a portion of secondary storage devices(s) 706 and/or main memory 704 allocated therefor.
In the event that code parser 720 is unable to ascertain which index number is being referenced based on its analysis, code injector 722 may be configured to mark the offset of the instruction that initiates a request of a system function and/or associates a hooking function between the requesting instruction (e.g., a “syscall” instruction, a “sysenter” instruction, an “int 0x80” instruction, etc.) and the last instruction before the requesting instruction that modifies the register that is configured to store the index number (e.g., RAX). During runtime of the application, when that last instruction is executed, the hooking function may analyze the value stored in the register and modify the value based on the random seed. For instance, the hooking function may subtract the value of the random seed from the value stored in the register.
For system calls for which offsets have been determined, such system calls may be patched during runtime of the application to reference the randomized index values. For example, when process loader 712 loads binary image 716 into main memory 704 at run time (shown as mapped binary image 718), process loader 712 provides a command 730 to application execution controller 726, which causes the application or process corresponding to mapped binary image 718 to be suspended. Process loader 712 may also provide patcher 728 with the name of the application, the names of the files of the application, and/or an identifier of the process to patcher 728 via an indicator 732. Patcher 728 may be configured to retrieve patch information 734 (e.g., offsets of the instructions to be patched) from cache 702 based on the information provided via indicator 732.
Using patch information 734, patcher 728 locates each instruction that writes an index number for a system call to a register. For each instruction, patcher 728 modifies the instruction such that the randomized index number is stored in the register. Once all the instructions have been patched for each file of the application, patcher 728 provides a command 736 to application execution controller 726 that causes the application to resume execution.
In accordance with an embodiment, operating system 710 may maintain a whitelist 738 of applications that are to be patched in an event that an application is trapped. For instance, suppose patch information was not collected for an application, but the application has been indicated as a valid process in whitelist 738. In such a situation, the application will encounter the hooking function described above (i.e., hooking function 328). During execution of the application, the hooking function will compare the index number specified for desired system function and determine that the value is less than or equal to the random seed, and therefore the application will get trapped. However, if the application is whitelisted, the application may be suspended and/or the patch information determination techniques described above will be implemented to determine where the application is needed to be patched. Once the application is patched, the application will resume with the patched information so that the randomized index numbers of the system library (i.e., system library 320), will be referenced (along with shadow system call table 302) when the application resumes execution.
In accordance with another embodiment, the original index numbers are backed up before they are overwritten with the randomized index numbers. In the event that operating system protector 724 is disabled and/or uninstalled, the randomized index numbers are replaced with the original, backed up index numbers (i.e., the application is unpatched). Thus, the application executes as originally intended, without protection from operating system protector 724.
Accordingly, an application may be patched in many ways to operate with a shadow system call table in many ways. For example,
Flowchart 800 begins with step 802. At step 802, code of an application stored on the computing device is parsed to detect a first instruction configured to initiate a request for the system function. For example, with reference to
At step 804, a location in the code of the application to be patched to reference the modified index number is determined. For example, with reference to
At step 806, the application is suspended. For example, with reference to FIG.
7, application execution controller 726 causes operation of the application (e.g., mapped binary image 718) to be suspended responsive to receiving command 730 from process loader.
At step 808, the application is patched to reference the modified index number. For example, with reference to
At step 810, the application is resumed after patching is completed. For example, with reference to
In embodiments, one or more of the steps or operations of flowchart 800 herein may not be performed. For example, in accordance with an embodiment, steps 806 and 810 may not be performed and an application may be patched on-the-fly as an atomic operation, while the application is executing.
Flowchart 900 begins with step 902. At step 902, a portion of the code that precedes the first instruction is analyzed to determine a second instruction that specifies the unmodified version of the index number. For example, with reference to
At step 906, a location of the second instruction is determined. For example, with reference to
In accordance with one or more embodiments, patcher 728 performs the patching (i.e., step 808) by replacing the index number specified by the second instruction with a corresponding modified index number of the second plurality of index numbers. For example, with reference to
In accordance with one or more embodiments, the patching (step 808) is performed by replacing the unmodified version of the index number specified by the second instruction with the modified index number. For example, with reference to
It is noted that while the embodiments described herein disclose that the original system call table (e.g., original system call table 322) and the shadow system call table (e.g., shadow system call table 302) maintain the same, non-randomized index numbers, in certain embodiments, the shadow system call table may maintain the randomized index numbers. That is, the index numbers utilized to access function pointers to corresponding system functions are randomized in accordance with random seed(s). In such an embodiment, it may not be required to randomize the index numbers maintained by the system library (e.g., system library 320). When a system call references a randomized index number, the shadow system call table is utilized to determine the corresponding function pointer, and the system function executes successfully. However, when a system call references a non-randomized index number, the original system call table is utilized, and a trap function is executed that neutralizes the process making the system call.
The embodiments described herein, including systems, methods/processes, and/or apparatuses, may be implemented using well known processing devices, servers, smart phones, tablets, personal data assistants (PDAs), Internet-of-Things (IoT) devices, computers, etc. such as a computer 1000 shown in
Computer 1000 can be any commercially available and well known communication device, processing device, and/or computer capable of performing the functions described herein, such as devices/computers available from International Business Machines®, Apple®, Sun®, HP®, Dell®, Cray®, Samsung®, Nokia®, etc. Computer 1000 may be any type of computer, including a desktop computer, a server, a mobile device (e.g., a tablet, a personal data assistant (PDA), a smart phone, a laptop, etc.), an IoT device, etc.
Computer 1000 includes one or more processors (also called central processing units, or CPUs), such as a processor 1006. Processor 1006 is connected to a communication infrastructure 1002, such as a communication bus. In some embodiments, processor 1006 can simultaneously operate multiple computing threads, and in some embodiments, processor 1006 may comprise one or more processors.
Computer 1000 also includes a primary or main memory 1008, such as random access memory (RAM). Main memory 1008 has stored therein control logic 1024 (computer software), and data.
Computer 1000 also includes one or more secondary storage devices 1010. Secondary storage devices 1010 include, for example, a hard disk drive 1012 and/or a removable storage device or drive 1014, as well as other types of storage devices, such as memory cards and memory sticks. For instance, computer 1000 may include an industry standard interface, such a universal serial bus (USB) interface for interfacing with devices such as a memory stick. Removable storage drive 1014 represents a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup, etc.
Removable storage drive 1014 interacts with a removable storage unit 1016. Removable storage unit 1016 includes a computer useable or readable storage medium 1018 having stored therein computer software 1026 (control logic) and/or data. Removable storage unit 1016 represents a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, or any other computer data storage device. Removable storage drive 1014 reads from and/or writes to removable storage unit 1016 in a well-known manner.
Computer 1000 also includes input/output/display devices 1004, such as touchscreens, LED and LCD displays, monitors, keyboards, pointing devices, etc.
Computer 1000 further includes a communication or network interface 1020. Communication interface 1020 enables computer 1000 to communicate with remote devices. For example, communication interface 1020 allows computer 1000 to communicate over communication networks or mediums 1022 (representing a form of a computer useable or readable medium), such as LANs, WANs, the Internet, etc. Network interface 1020 may interface with remote sites or networks via wired or wireless connections.
Control logic 1028 may be transmitted to and from computer 1000 via the communication medium 1022.
Any apparatus or manufacture comprising a computer useable or readable medium having control logic (software) stored therein is referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer 1000, main memory 1008, secondary storage devices 1010, and removable storage unit 1016. Such computer program products, having control logic stored therein that, when executed by one or more data processing devices, cause such data processing devices to operate as described herein, represent embodiments.
Techniques, including methods, and embodiments described herein may be implemented by hardware (digital and/or analog) or a combination of hardware with one or both of software and/or firmware. Techniques described herein may be implemented by one or more components. Embodiments may comprise computer program products comprising logic (e.g., in the form of program code or software as well as firmware) stored on any computer useable medium, which may be integrated in or separate from other components. Such program code, when executed by one or more processor circuits, causes a device to operate as described herein. Devices in which embodiments may be implemented may include storage, such as storage drives, memory devices, and further types of physical hardware computer-readable storage media. Examples of such computer-readable storage media include, a hard disk, a removable magnetic disk, a removable optical disk, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and other types of physical hardware storage media. In greater detail, examples of such computer-readable storage media include, but are not limited to, a hard disk associated with a hard disk drive, a removable magnetic disk, a removable optical disk (e.g., CDROMs, DVDs, etc.), zip disks, tapes, magnetic storage devices, MEMS (micro-electromechanical systems) storage, nanotechnology-based storage devices, flash memory cards, digital video discs, RAM devices, ROM devices, and further types of physical hardware storage media. Such computer-readable storage media may, for example, store computer program logic, e.g., program modules, comprising computer executable instructions that, when executed by one or more processor circuits, provide and/or maintain one or more aspects of functionality described herein with reference to the figures, as well as any and all components, capabilities, and functions therein and/or further embodiments described herein.
Such computer-readable storage media are distinguished from and non-overlapping with communication media (do not include communication media). Communication media embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared, and other wireless media, as well as wired media and signals transmitted over wired media. Embodiments are also directed to such communication media.
The techniques and embodiments described herein may be implemented as, or in, various types of devices. For instance, embodiments may be included in mobile devices such as laptop computers, handheld devices such as mobile phones (e.g., cellular and smart phones), handheld computers, and further types of mobile devices, desktop and/or server computers. A device, as defined herein, is a machine or manufacture as defined by 35 U.S.C. § 101. Devices may include digital circuits, analog circuits, or a combination thereof. Devices may include one or more processor circuits (e.g., central processing units (CPUs) (e.g., processor 1006 of
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art(s) that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Accordingly, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
This application is a U.S. national phase application of PCT/IB2019/060262, filed on Nov. 27, 2019, which claims priority to U.S. Provisional Application Ser. No. 62/773,706, filed Nov. 30, 2018, and entitled “SYSTEM AND METHOD FOR PROTECTING AN OPERATING SYSTEM KERNEL AGAINST MALICIOUS CODE BY RUNTIME MORPHING,” the entireties of which are incorporated by reference herein.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2019/060262 | 11/27/2019 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62773706 | Nov 2018 | US |
