BACKGROUND

Network accessible applications are often vulnerable to memory corruption attacks triggered remotely by malicious attackers. Malicious attackers have strived hard to exploit such vulnerability since it gives them unprecedented access to the remote user's computer network, often with elevated privileges. Once control has been seized, arbitrary code of the attacker's choosing can be executed by the attacker, as if the remote user owns the compromised machine. Usually the objective of the malicious attacker is to extract personal and/or confidential information from the user, but the objective could also include disrupting personal or business activity of the user for the purpose of inflicting loss of productivity.

Preparatory attacks may help to set the stage by placing strategic data in buffers on the stack, the heap segments, and other jump tables, including imports, exports, virtual pointers (VPTRs), and system call/system dispatch tables in the memory address space of the application. This allows subsequently launched attacks to manipulate the flow of execution, with the ultimate objective of causing code designed by a malicious hacker to execute instead of code that is natively part of the application. The most sophisticated attackers do not even need to insert their malicious code directly into the target application's memory space, instead, the attackers can re-purpose existing code by stitching together selectively chosen (i.e., cherry picked) chunks of code from the legitimately loaded application code and thereby execute their nefarious intent. There is an urgent need to protect the application at runtime from such advanced runtime memory corruption attacks.

SUMMARY

Embodiments of the present disclosure are directed to example systems and methods for protection against malicious attacks that are facilitated through memory corruption within one or more running processes. In some embodiments, the systems include one or more instrumentation engines and one or more analysis engines for performing operations to protect against malicious attacks. The one or more instrumentation engines may be located on the same or different hardware or computer system as the one or more analysis engines. In some embodiments, the systems and methods may extract a model of a computer application as the application code first loads into memory. The model may include, but is not limited to, building pairs of legal source and destination memory addresses, transitions, basic block boundary information, code segment bounds, import and export address table bounds, jump table bounds, or any other type of computer-routine-related information known to one skilled in the art. In some embodiments, the systems and methods may store the model of the computer application.

In some embodiments, the systems and methods may insert instructions into the computer application (optionally, at run time) prior to the computer application instructions being executed in memory in order to collect data at runtime and/or the execution state of the application. In some embodiments, the systems and methods may analyze the collected data at runtime against the stored model of the computer application to perform detection of one or more security events. In some embodiments, the systems and methods may, based upon the detection of the one or more security events, modify, in a manner that preserves continued execution of the computer application, at least one computer routine associated with at least one active process associated with the computer application (i.e., insert a patch).

According to some embodiments, the computer routine may be executed in association with the at least one process. In some embodiments, the one or more detected security events may be associated with a malicious movement to a different (unusual) code path within the computer application. Such a malicious movement may include, but is not limited to, a malicious jump routine, a trampoline to malicious code, an indirect jump vector, or any other malicious movement known to one skilled in the art.

In response to receipt of one or more aggregate patches by a user, some embodiments may perform at least one operation that modifies or removes the at least one computer routine associated with the computer application, and modifying or removing one or more individual patches associated with the computer application. According to some embodiments, modifying may include verifying a patch or configuration associated with the computer application. According to some embodiments, the systems and methods may modify the stack associated with the at least one computer routine. In some embodiments, the systems and methods may modify one or more heaps associated with the at least one executing computer routine. In some other embodiments, the systems and methods may modify one or more jump tables.

Further, in some embodiments, the systems and methods may modify the at least one computer routine associated with the at least one process, while the at least one active process is executing the at least one computer routine. As such, some embodiments may employ hot patching (or live patching, or dynamic software patching/updating). According to some embodiments, a replacement function (i.e., different function) may be called as a result of a hot patch. In some embodiments, the systems and methods may, prior to modifying the at least one computer routine, pause execution of at least one active process (or computer application). In some embodiments, after modifying the at least one computer instruction, the systems and methods may resume execution of the at least one active process.

In some embodiments, the systems and methods may extract a model of a computer application during load time. According to some embodiments, the systems and methods may store the model of the computer application. In some embodiments, the systems and methods may insert instructions into the computer application (optionally, in memory) prior to the computer application being executed in memory in order to collect data at runtime. In some embodiments, the systems and methods may analyze the data collected at runtime against the stored model of the computer application to perform detection of one or more security events. In some embodiments, the systems and methods may, upon the detection of the one or more security events, temporarily remediate memory corruption associated with the computer application (i.e., restore one or more pointers) prior to executing one or more return instructions. In some embodiments, the systems and methods may report actionable information (i.e., report information to a vendor to create a patch) based upon the one or more detected security events. The actionable information may include, but is not limited to, information such as: where/how a security event occurs, where/how a trampoline takes place, and where/how the memory in the stack or heap of a vulnerable function is corrupted.

In some embodiments, the systems and methods may modify, in a manner that preserves continued execution of the computer application, at least one computer routine associated with at least one process. In some embodiments, when a lite or full patch from the vendor is received by a user, an application runtime monitoring and analysis (ARMAS) application may be disabled, and new code may be loaded into computer memory associated with the process (i.e., a different location in memory) without shutting the process down. Some embodiments may deploy such lite patches released by a vendor as a shared static or dynamic library. Further, in some embodiments, the systems and methods may modify at least one computer instruction associated with at least one process, while the at least one process is executing. In some embodiments, the systems and methods may, prior to modifying the at least one computer instruction, pause execution of at least one process associated with the computer application. In some embodiments, after modifying the at least one computer instruction, the systems and methods may resume execution of the at least one process.

Some embodiments may remediate or prevent malicious attacks in real time until a patch is deployed. Some embodiments may provide an actionable remediation path to software vendor's developers. Some embodiments may detect heap based code and/or stack based code trampolines in real time. Some embodiments may hot-deploy lite patches (i.e., perform hot patching) without process termination. In other words, some embodiments may download and verify a lite patch, stop running all threads in the process temporarily, hot-patch a binary, and finally restart all the threads in the process (and/or application). Some embodiments may tie (i.e., associate) and track state of which patch is tied to which routine in which parent binary. Such state may include, but not be limited to, a checksum associated with the lite patch, and the address in the original binary itself. Some embodiments may untie (i.e., disassociate) a state that is presently associated with the process, either before or after deploying the patch. Some embodiments may protect a state relationship from hackers. By modifying one or more states (or associating or disassociating on or more states from a patch), some embodiments may protect a state relationship from hackers. Some embodiments include protection, including, but not limited to: (a) verification of a checksum associated with (or included in) a patch, (b) obtaining another copy of an original patch that is deleted, and/or (c) encrypting contents of a patch, thereby preventing man-in-the-middle (MIM) attacks as well as deliberate/accidental deletion.

In example embodiments, the systems and methods, for one or more code vulnerabilities of a computer application, map each of the code vulnerabilities to a respective system response in a table in memory (e.g., in a security policy database). In some example embodiments, at least one code vulnerability, and mapped system response, is provided from developers of the computer application. In some example embodiments, at least one of the code vulnerabilities and mapped system response is automatically determined by a code analyzer at load time or runtime of the computer application. The systems and methods next detect an event accessing a code vulnerability of the computer application.

The systems and methods, in response to the detection of the event, determine a system response mapped to the accessed code vulnerability in the table in memory. In some embodiments, an exception is triggered in response to an inappropriate operation by the application, such as inappropriately accessing the vulnerable code. The systems and methods instrument an exception handler to overwrite the kernel mode exception handler. The systems and methods intercept the triggered exception and associate the code vulnerability by an instrumented exception handler. In these embodiments, the systems and methods include querying, by the instrumented exception handler, the associated code vulnerability in the table. The querying returns the system response, configured as a system callback routine, mapped to the code vulnerability. The systems and methods execute the determined system response to prevent the event from exploiting the accessed code vulnerability. For example, the systems and methods execute the system callback routine to initiate instructions to prevent the event from exploiting the code vulnerability.

The system response (e.g., initiated instructions by the system callback routine) may include one or more of: logging the accessing of the code vulnerability as an error in a system log, dumping an image of an application process containing the accessed code vulnerability, restoring a copy of computer application prior to the accessing of the code vulnerability, dynamically loading one or more remedial patches from memory to modify at least one computer routine containing the code vulnerability, without restarting the computer application, continuing execution of the computer application until it terminates (e.g., crashes) based on the accessed code vulnerability, and terminating proactively the computer application.

