WO2016094985A1

WO2016094985A1 - Protection driver for defense against process or thread termination

Info

Publication number: WO2016094985A1
Application number: PCT/BR2015/000184
Authority: WO
Inventors: Fabio CAVALHEIRI MARENGHI; Paulo Márcio FIGUEIREDO ALVES; Felipe NAVA
Original assignee: Gas Informatica Ltda
Priority date: 2014-12-15
Filing date: 2015-12-15
Publication date: 2016-06-23

Abstract

Computer systems Methods (implemented through instructions carried by a medium) and apparatus for protecting a process or thread (102, 202) against forced terminations are disclosed. The protection is accomplished by monitoring of commands targeting the processes or threads (102, 202) under protection. In one example embodiment (100), Operating Systems' API (108) usage is monitored by a Operating System Device Driver (104) using kernel hooks. In another example embodiment (200), that monitoring occurs using kernel callbacks.

Description

PROTECTION DRIVER FOR DEFENSE AGAINST PROCESS OR THREAD TERMINATION

Self Protecting Process

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 62/091 ,923, filed on December 15, 2014.

TECHNICAL FIELD

[0002] The present disclosure relates generally to computer systems and more particularly to protection of a process or a thread.

BACKGROUND

[0003] Modern computers are controlled by operating systems that execute computer programs as processes. Processes include a memory space as well as a set of instructions that can be executed by the processor of a computer. In addition, a process may include multiple threads which may independently executed by the computer processor.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The accompanying drawings incorporated herein and forming a part of the specification illustrate the example embodiments.

[0005] FIG. 1 is a block diagram illustrating an example of a self protection device driver employing an application programming interface for protecting a process or thread.

[0006] FIG. 2 is a block diagram illustrating an example of a self protection device driver that registers itself with an operating system for protecting a process or thread.

[0007] FIG. 3 illustrates an example of a computer system upon which an example embodiment can be implemented. [0008] FIG. 4 is a block diagram illustrating an example of a methodology employing an application programming interface to protect a process or thread.

[0009] FIG. 5 is a block diagram illustrating an example of a methodology that registers a self protection device driver with an operating system to protect a process or thread.

OVERVIEW OF EXAMPLE EMBODIMENTS

[0010] The following presents a simplified overview of the example embodiments in order to provide a basic understanding of some aspects of the example embodiments. This overview is not an extensive overview of the example embodiments. It is intended to neither identify key or critical elements of the example embodiments nor delineate the scope of the appended claims. Its sole purpose is to present some concepts of the example embodiments in a simplified form as a prelude to the more detailed description that is presented later.

[0011] In example embodiments described herein, processes can protect themselves against forced terminations. In one example embodiment, an operating system's kernel application programming interface (API) is employed. In another example embodiment, operating system kernel callbacks are employed.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[0012] This description provides examples not intended to limit the scope of the appended claims. The figures generally indicate the features of the examples, where it is understood and appreciated that like reference numerals are used to refer to like elements. Reference in the specification to "one embodiment" or "an embodiment" or "an example embodiment" means that a particular feature, structure, or characteristic described is included in at least one embodiment described herein and does not imply that the feature, structure, or characteristic is present in all embodiments described herein.

[0013] In example embodiments described herein, processes can protect themselves against forced terminations. In one example embodiment, an operating system's kernel application programming interface (API) is employed. In another example embodiment, operating system kernel callbacks are employed.

[0014] For example, for many version of WINDOWS, the kernel's application programming interface (API) hooks may be employed. A device driver performs hooks in the following kernel APIs: ZwCreateThread, ZwCreateThreadEx, ZwOpenProcess, Zw2OpenThread, ZwTerminateProcess, and ZwTerminateThread. Once the hooks are in place, if any process in the system attempts to kill, terminate, or suspend any of the protected threads or processes, for example, calling the function OpenProcess with the flag PROCESS__TERMINATE, calling function TerminateProcess or others, the device driver intercepts the command. The device driver determines if the origin of the command is form a trusted process, for example by using an internal list of trusted processes. If the command is from a trusted process, then the command is allowed to execute. However, if the command is not from a trusted process, then the driver prevents the command from executing and optionally returns an "access denied" message to the operating system.

[0015] FIG. 1 is a block diagram illustrating an example of a system 100 with a self protection device driver 104 employing an application programming interface (API) 108 for protecting a process or thread 102. For example, a process 102 with one or more threads may be created by an application (not shown). The self protection device driver 104 comprises a tangible, non-transitory computer readable medium of instructions that contain instructions for execution by a process that when executed perform the functionality described herein. In an example embodiment, the self protection device driver 104, creates a hook into via the API 108 into the kernel 1 10 of the operating system to protect one of a protected process, a protected thread, or both a protected process and a protected thread. As those skilled in the art can readily appreciate, the self protection device driver 104 is capable of protecting multiple processes and threads.

[0016] After the hook is established, the self protection device driver 104 intercepts, via the hook, any commands to suspend or terminate any protected process, protected thread, or both; For example, commands to terminate or suspend one or more threads of a protected process, to terminate or suspend the protected process, or to suspend or terminate both one or more threads of a protected process and the protected process will be intercepted by the self protection device driver 104.

[0017] The self protection device driver 104 determines whether the command to suspend or terminate a protected process, protected thread or both a protected process and thread originated from a predefined (e.g., "trusted") process. For example, the self protection device driver may employ a database 106 containing a list of trusted processes.

[0018] If the command originated from _^process that is not on the predefined (trusted) list, the self protection device driver 104 prevents the command from executing. The self protection device driver 104 may also return an access denied response to the operating system kernel 110. In particular embodiments, the operating system kernel 1 10 may return an access denied message to the process where the command originated.

[0019] If self protection device driver 104 determines that the command originated from a trusted process, the command is allowed to execute. For example, if the command originated from the application that created the process or thread, the command may be considered originating from a trusted process.

[0020] In an example embodiment, a driver registers itself to receive notifications from the Operating System, using ObRegisterCallbacks,. Whenever operation system manages or treats processes or threads, the device driver's callbacks are notified. After registration, the operating system notifies the driver whenever a process calls any process or thread's APIs, such as TerminateProcess, OpenProcess etc. The driver can then determine whether the call contains data representative of a protected process or thread. For example, the driver can extract data from notifications received by callbacks looking for the Process Id of protected processes and, if found, the driver checks if the caller (name of process) is present on an internal white list (e.g., list of trusted processes), if not, then returns access denied to operation system. If so, the driver prevents the call from the API from executing; otherwise, the call is permitted to execute.

[0021] FIG. 2 is a block diagram illustrating an example of system 200 that a self protection device driver 204 that registers itself with an operating system 206 for protecting (prevent suspending or terminating) a protected process or a protected thread (or plurality of threads associated with a protected process) 202. The self protection device driver 204 registers to receive notifications from an operating system 206 when a predetermined application programming interface is called by a process. For example, in a WINDOWS VISTA SP1 or higher environment, the self protection device driver 204 may register to receive notifications whenever a process calls APIs used to manage processes or threads.

[0022] Upon registration, the self protection device driver 204 is operable to receive a notification from the operating system kernel 206 when a process calls the predetermined application programming interface. The self protection device driver 204 determines whether the call to the predefined API contains data representative of a protected process, a protected thread, or both a protected process and a protected thread.

[0023] If the self protection device driver 204 determines that the call contains data representative of a protected process, a protected thread, or both a protected process and a protected thread, the self protection device driver 204 prevents the execution of the predetermined application programming interface by the process responsive. In particular embodiments, the self protection device driver 204 is operable to return data to the operating system indicating that access is denied to the predetermined application interface. If the self protection device driver 204 determines that the call does not contain data representative of a protected process, a protected thread, or both a protected process and a protected thread, the self protection device driver 204 allows the second process to access the predetermined application programming interface.

[0024] For example, if a first call is made to the predefined API by a first process that contains data representative of a protected process, thread or both, the self protection device driver 204 prevents execution of the call by the API. If a second process calls the predefined API, where the second call does not contain data representative of a protected process, thread, or both, the self protection device driver 204 allows the call to be executed by the API.

[0025] FIG. 3 illustrates an example of a computer 300 system upon which an example embodiment can be implemented. For example, computer system 300 may be employed for implementing components of system 100 described in FIG. 1 or components of system 200 described in FIG. 2.

[0026] Computer system 300 includes a bus 302 or other communication mechanism for communicating information and a processor 304 coupled with bus 302 for processing information. Computer system 300 also includes a main memory 306, such as random access memory (RAM) or other dynamic storage device coupled to bus 302 for storing information and instructions to be executed by processor 304. Main memory 306 also may be used for storing a temporary variable or other intermediate information during execution of instructions to be executed by processor 304. Computer system 300 further includes a read only memory (ROM) 308 or other static storage device coupled to bus 302 for storing static information and instructions for processor 304. A storage device 310, such as a magnetic disk or optical disk, is provided and coupled to bus 302 for storing information and instructions.

[0027] An aspect of the example embodiment is related to the use of computer system 300 for a self protecting process. According to an example embodiment, a self protecting process is provided by computer system 300 in response to processor 304 executing one or more sequences of one or more instructions contained in main memory 306. Such instructions may be read into main memory 306 from another computer-readable medium, such as storage device 310. Execution of the sequence of instructions contained in main memory 306 causes processor 304 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 306. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement an example embodiment. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0028] The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 304 for execution. Such a medium may take many forms, including but not limited to non-volatile media. Non-volatile media include for example optical or magnetic disks, such as storage device 310. Common forms of computer-readable media include for example floppy disk, a flexible disk, hard disk, magnetic cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASHPROM, CD, DVD or any other memory chip or cartridge, or any other medium from which a computer can read.

[0029] In view of the foregoing structural and functional features described above, methodologies in accordance with example embodiments will be better appreciated with reference to Figs 4-5. . While, for purposes of simplicity of explanation, the methodologies of Figs 4-5 are shown and described as executing serially, it is to be understood and appreciated that the example embodiments are not limited by the illustrated orders, as some aspects could occur in different orders and/or concurrently with other aspects from that shown and described herein. Moreover, not all illustrated features may be required. The methodologies described herein are suitably adapted to be implemented in logic. "Logic", as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another component. For example, based on a desired application or need, logic may include a software controlled microprocessor, discrete logic such as an application specific integrated circuit (ASIC), a programmable/programmed logic device, memory device containing instructions, or the like, or combinational logic embodied in hardware. Logic may also be fully embodied as software that performs the desired functionality when executed by a processor

[0030] FIG. 4 is a block diagram illustrating an example of a methodology 400 smploying an application programming interface to protect a process or thread. Methodology 400 may be implemented by self protecting driver 104 described in FIG. 1 or processor 304 described in FIG. 3.

[0031] At 402, a device driver (e.g., self protecting or self protection device driver) hooks into a kernel API. For example, for WINDOWS XP and VISTA without service packs, any one or combination of ZwCreateThread, ZwCreateThreadEx, ZwOpenProcess, Zw20penThread, ZwTerminate Process, and ZwTerminateThread APIs may be employed.

[0032] At 404, the driver intercepts a command from a process attempting to suspend or terminate a protected process or a protected thread. At 406, the driver determines whether the command originated from a trusted process. For example, the driver may employ a list or database of predefined, approved process that are allowed to terminate or suspend the protected process or a protected thread.

[0033] (f at 406, the process where the command originated is not considered to be a trusted process (NO), at 408, the command is prevented from executing. In particular embodiments, an access denied message may be provided to the operating system, which may forward the access denied message to the process where the command originated. If at 406, the process where the command originated is considered to be a trusted process (YES), the command is allowed to execute as indicated by 410.

[0034] FIG. 5 is a block diagram illustrating an example of a methodology 500 that registers a self protection device driver with an operating system to protect a process or thread. For example, methodology 500 can be implemented by self protection device driver 204 described in FIG. 2 or processor 304 described in FIG. 3.

[0035] At 502, a driver registers with an operating system to receive notifications if certain (predefined) APIs are called. Upon registration, the driver receives a notification whenever any process calls the predefined APIs.

[0036] At 504, the driver receives notification from the operating system that a process has called a predefined API, such as the same mentioned on Kernel API hook protection.

[0037] At 506, the driver determines whether the call contains a reference to any protected processes or threads, such as, for example, any processes or threads that are associated with a particular application.

[0038] If at 506, the call to the API does not contain a reference to any predefined (e.g., protected) processes or threads (NO), the call to the API is allowed to continue as indicated at 508. However, if at 506, the call to the predefined API contains a reference to a predefined (protected) process or thread (YES), the call is not allowed to execute the predefined API as indicated by 510. In particular embodiments, the driver may return an access denied response to the operating system if the call is not allowed to execute the predefined API.

[0039] Described above are example embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the example embodiments, but one of ordinary skill in the art will recognize that many further combinations and permutations of the example embodiments are possible. Accordingly, it is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of any claims filed in applications claiming priority hereto interpreted in accordance with the breadth to which they are fairly, legally and equitably entitled.

Claims

1. A tangible, non-transitory computer readable medium of instructions with instructions encoded thereon for execution by a processor and when executed operable to:

create a hook into a predefined kernel application programming interface of an operating system to protect one of group consisting of a protected process and a protected thread;

intercept, via the hook, a command to one of a group consisting of suspend and terminate the one of the group consisting of the protected process and the protected thread;

determine whether the command originated from a predefined process; and prevent the command to one of the group consisting of suspend and terminate the one of the group consisting of the protected process and the protected thread from executing responsive to determining the command did not originate from the predefined process.

2. The tangible, non-transitory computer readable medium of instructions of claim 1 , further operable to:

intercept a second command to one of a group consisting of suspend and terminate the one of the group consisting of the protected process and the protected thread;

determine whether the second command originated from a predefined process; and allow the process from one of the group consisting of suspend and terminate the one of the group consisting of the protected process and the protected thread responsive to determining the second command originated from the predefined process.

3. The tangible, non-transitory computer readable medium of instructions of claim 1 , wherein the one of a group consisting of the protected process and the protected thread is a process.

4. The tangible, non-transitory computer readable medium of instructions of claim 1 , wherein the one of a group consisting of the protected process and the protected thread is a thread.

5. The tangible, non-transitory computer readable medium of instructions of claim 1 , wherein the command to one of a group consisting of suspend and terminate the one of the group consisting of the protected process and the protected thread is a command to suspend a protected process.

6. The tangible, non-transitory computer readable medium of instructions of claim 1 , wherein the command to one of a group consisting of suspend and terminate the one of the group consisting of the protected process and the protected thread is a command to terminate a protected process.

7. The tangible, non-transitory computer readable medium of instructions of claim 1 , wherein the hook into a predefined kernel application programming interface is one of a group consisting of ZwCreateThread, ZwCreateThreadEx, ZwOpenProcess, ZwOpenThread, ZwTerminateProcess, and ZwTerminate thread.

8. The tangible, non-transitory computer readable medium of instructions of claim 1 , wherein the instructions are operable to use an internal list of predefined processes to determine whether the command originated from a predefined process.

9. The tangible, non-transitory computer readable medium of instructions of claim 1 , the instructions are operable to return an access denied indication to the operating system responsive to determining the command did not originate from the predefined process.

10. A tangible, non-transitory computer readable medium of instructions with instructions encoded thereon for execution by a processor and when executed operable to:

register to receive notifications from an operating system when a predetermined application programming interface is called by a process;

receive a notification from the operating system that a process has called the predetermined application programming interface;

determine whether the call contains data representative of one of a group consisting of a protected process, a protected thread, and both a protected process and a protected thread; and

prevent the execution of the predetermined application programming interface by the process responsive to determining the call to the predetermined application programming interface contains data representative of one of a group consisting of a protected process, a protected thread, and both a protected process and a protected thread.

11. The tangible, non-transitory computer readable medium of claim 10, the instructions are operable to return data to the operating system indicating access is denied to the predetermined application interface.

12. The tangible, non-transitory computer readable medium of claim 10, the instructions are further operable to:

receive a notification from the operating system that a second process has called the predetermined application programming interface;

allow the second process to access the predetermined application programming interface responsive to determining the call to the predetermined application programming interface from the second process does not contain data representative of one of a group consisting of a protected process, a protected thread, and both a protected process and a protected thread.

13. The tangible non-transitory computer readable medium of claim 10, wherein the instructions are operable to use ObRegisteCallbacks to register to receive notifications from the operating system.

14. . The tangible non-transitory computer readable medium of claim 10, the instructions to determine whether the call contains data representative of one of a group consisting of a protected process, a protected thread, and both a protected process and a protected thread are operable to:

extract data representative of a process identifier from a notification received from the operating system;

determine whether the extracted data representative of a process identifier is for a protected process; and

determine whether the process that called the predetermined application programming interface is a trusted process.

15. The tangible non-transitory computer readable medium of claim 14, wherein the instructions to determine whether the call contains data representative of one of a group consisting of a protected process, a protected thread, and both a protected process and a protected thread are operable to determine whether the process that called the predetermined application programming interface is on a list of trusted processes.

16. An apparatus, comprising:

a processor;

logic encoded on a tangible, non-transitory computer readable medium for execution by the processor and when executed operable to:

17. The apparatus of claim 16, the logic is further operable to:

18. The apparatus of claim 16, wherein the one of a group consisting of the protected process and the protected thread is a process.

19. The apparatus of claim 16, wherein the one of a group consisting of the protected process and the protected thread is a thread.

20. The apparatus of claim 16, wherein the command to one of a group consisting of suspend and terminate the one of the group consisting of the protected process and the protected thread is a command to suspend a protected process.