Secure system for allowing the execution of authorized computer program code

• US 20060150256A1
• Filed: 12/05/2005
• Published: 07/06/2006
• Est. Priority Date: 12/03/2004
• Status: Active Grant

• Current Assignee: Fortinet Inc.
• Original Assignee: WhiteCell Software Incorporated
• Inventors: Harper, Edwin L., Godwin, Kurt E., Rozga, Anthony A., Fanton, Andrew F., Gandee, John J., Lutton, William H.
• Granted Patent: US 7,698,744 B2
• Time in Patent Office: Days
• US Class Current: 726/27
• CPC Class Codes: G06F 21/10 Protecting distributed programs or content, e.g. vending or licensing of copyrighted material protection in video systems or pay television H04N7/16 ; Digital rights management [DRM]
• CPC Class Codes: G06F 21/44 Program or device authentication
• CPC Class Codes: G06F 21/51 at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
• CPC Class Codes: G06F 21/52 during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
• CPC Class Codes: G06F 21/53 by executing in a restricted environment, e.g. sandbox or secure virtual machine
• CPC Class Codes: G06F 21/602 Providing cryptographic facilities or services
• CPC Class Codes: G06F 2221/033 Test or assess software
• CPC Class Codes: G06F 2221/2141 Access rights, e.g. capability lists, access control lists, access tables, access matrices
• CPC Class Codes: G06F 9/445 Program loading or initiating bootstrapping G06F9/4401; security arrangements for program loading or initiating G06F21/57
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0884 by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources
• CPC Class Codes: H04L 63/145 the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
• CPC Class Codes: H04L 9/0643 Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
• CPC Class Codes: H04L 9/32 including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
• CPC Class Codes: H04L 9/3239 involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
• CPC Class Codes: Y10S 707/99934 Query formulation, input preparation, or translation
• CPC Class Codes: Y10S 707/99943 Generating database or data structure, e.g. via user interface
• CPC Class Codes: Y10S 707/99944 Object-oriented database structure

Abstract

Systems and methods are described for allowing the execution of authorized computer program code and for protecting computer systems and networks from unauthorized code execution. In one embodiment, a multi-level proactive whitelist approach is employed to secure a computer system by allowing only the execution of authorized computer program code thereby protecting the computer system against the execution of malicious code such as viruses, Trojan horses, spy-ware, and/or the like. Various embodiments use a kernel-level driver, which intercepts or “hooks” certain system Application Programming Interface (API) calls in order to monitor the creation of processes prior to code execution. The kernel-level driver may also intercept and monitor the loading of code modules by running processes, and the passing of non-executable code modules, such as script files, to approved or running code modules via command line options, for example. Once intercepted, a multi-level whitelist approach may be used to authorize the code execution.

Claims

1. A method of allowing authorized code to execute on a computer system, the method comprising:

intercepting a request to create a process associated with a code module;

determining if the request is authorized by authenticating the request with reference to a multi-level whitelist; and

allowing the code module to be loaded and executed by granting the request if the request is authorized.

2. The method of claim 1, wherein the computer system is a server.

3. The method of claim 1, wherein the request is originated by a client system.

4. The method of claim 1, wherein the multi-level whitelist includes a most recently used (MRU) cache, one or more local whitelists and a global whitelist.

5. The method of claim 4, further comprising if the request cannot be authenticated with reference to the MRU cache, then generating a content authenticator associated with the code module.

6. The method of claim 5, wherein the content authenticator is a cyptographically-secure hash value.

7. The method of claim 1, wherein the code module is associated with one or more boot processes of the computer system.

8. The method of claim 1, the method further comprising determining if the code module is authorized to execute by comparing the content authenticator with entries in a global whitelist database when the request is not authorized by comparing the generated content authenticator with the one or more entries of the local whitelist database.

9. The method of claim 1, the method further comprising:

performing an inventory of a mass storage device associated with the computer system to determine installed code modules;

associating with each code module a content authenticator, and

recording each content authenticator in a local whitelist database.

10. The method of claim 1, the method further comprising recording, in a software activity database, information associated with the execution and utilization of code modules.

11. A method of allowing authorized code to execute on a computer system, the method comprising:

storing information in a most recently used (MRU) cache, the information being associated with a code module that has previously been authenticated on the computer system, wherein the information includes one or more parameters associated with the code module; and

responsive to a subsequent new process creation request corresponding to the code module, determining whether the code module is allowed to run with reference to the information in the MRU cache.

12. The method of claim 11, wherein the parameters associated with the code module include at least one of a run option, a file path, or a content authenticator.

13. The method of claim 11, wherein said determining whether the code module is allowed to run further comprises determining whether the code module has been altered since the code module was previously authenticated.

14. The method of claim 11, wherein said determining whether the code module has been altered comprises observing that a write has been performed to the code module.

15. The method of claim 11, wherein the subsequent new process creation request is allowed if an entry is found in the MRU cache corresponding to the code module and has associated therewith a run option indicating the code module was previously affirmatively authenticated.

16. The method of claim 11, wherein the subsequent new process creation request is evaluated with reference to a first of one or more local whitelists if no valid entry is found in the MRU cache corresponding to the code module.

17. The method of claim 11, wherein the subsequent new process creation request is denied if an entry is found in the MRU cache corresponding to the code module and has associated therewith a run option indicating authentication of the code module failed.

18. The method of claim 11, further comprising:

monitoring file system activity for write requests associated with code modules; and

invalidating or removing entries from the MRU cache associated with code modules for which write requests are made.

19. A method of allowing authorized code to execute on a computer system, the method comprising:

intercepting a request to load a first code module on behalf of a second code module associated with a running process;

determining if the request is authorized by authenticating the request with reference to a multi-level whitelist; and

allowing the first code module to be loaded into memory of the computer system by granting the request if the request is authorized.

20. The method of claim 19, wherein the multi-level whitelist includes a most recently used (MRU) cache, one or more local whitelists and a global whitelist.

21. The method of claim 20, further comprising if the request cannot be authenticated with reference to the MRU cache, then generating a content authenticator associated with the code module.

22. The method of claim 21, wherein the content authenticator is a cyptographically-secure hash value.

23. The method of claim 19, wherein the code module comprises a dynamically-linked library.

24. The method of claim 19, performed during boot processing of the computer system.

25. The method of claim 19, wherein the second code module is associated with one or more boot processes of the computer system.

26. The method of claim 19, wherein the running process is a boot process of the computer system.

27. The method of claim 19, the method further comprising determining if the intercepted request to load the first code module is authorized by comparing the content authenticator with entries in a global whitelist database when the request is not authorized by comparing the generated content authenticator with the one or more entries of the local whitelist database.

28. The method of claim 19, the method further comprising:

performing an inventory of a mass storage device associated with the computer system to determine installed code modules;

associating with each code module a content authenticator; and

recording each content authenticator in a local whitelist database.

29. The method of claim 19, the method further comprising recording, in a software activity database, information associated with the execution and utilization of code modules.

30. A method of allowing authorized code to execute on a computer system, the method comprising:

storing information in a memory store, the information being associated with a code module that has previous been authenticated responsive to a request to load the code module, wherein the information includes one or more parameters associated with the code module; and

responsive to a subsequent request to load the code module, determining whether the subsequent request should be granted by using at least part of the information stored in the memory store.

31. The method of claim 30, wherein the one or more parameters associated with the code module include at least one of a run option, a file path, and a content authenticator.

32. The method of claim 30, wherein said determining whether the subsequent request to load the code module should be granted further comprises determining whether the code module has been altered since the storing of information.

33. The method of claim 32, wherein said determining whether the code module has been altered comprises observing that a write has been performed to the code module.

34. The method of claim 30, wherein the subsequent request to load the code module is allowed if an entry corresponding to the code module is found in the memory store and a run option associated with the entry indicates the code module was previously affirmatively authenticated.

35. The method of claim 30, wherein the subsequent request to load the code module is evaluated with reference to a first of one or more local whitelists if no valid entry is found in the memory store corresponding to the code module.

36. The method of claim 30, wherein the subsequent request to load the code module is denied if the memory store entry is found and the run option associated with the entry indicates authentication of the code module previously failed.

37. The method of claim 30, further comprising:

monitoring file system activity for write requests associated with code modules; and

removing or invalidating entries of the memory store associated with the code modules for which a write request is made.

38. A method of allowing authorized files to execute on a computer system, the method comprising:

intercepting process creation wherein one or more of the code modules includes a known executable module configured to execute instructions contained within a separate script file;

if an intercepted process creation request is associated with the known executable module, then determining if a separate script file identified by the intercepted process creation request is authorized if the separate script file is in an approved list; and

allowing the intercepted process creation request if the separate script file was in the approved list.

39. The method of claim 38, further comprising tagging a known executable module as an authorized script interpreter by setting a run option associated with an entry in a local whitelist associated with the known executable module.

40. A method of license enforcement, the method comprising:

monitoring loading of software applications;

intercepting the loading of an instance of a software application;

determining if the number of instances of the software application is greater than a number of authorized instances;

denying execution of the software application if the number of instances already running of the software application is greater than the number of authorized instances.

41. A code execution authorization system comprising:

a plurality of whitelists stored in one or more local files; and

a kernel driver configured to intercept and authenticate code module loading requests and new process creation requests, the kernel driver further configured to;

monitor requests to modify any one of the plurality of whitelists; and

allow or disallow the modification requests.

42. The system of 41, wherein the plurality of whitelists include one or more MRU caches, one or more local whitelists, and one or more global whitelists.

43. The system of 41, wherein the kernel driver is further configured to monitor and allow or disallow requests to modify configuration files.

44. The system of 41, wherein the kernel driver is further configured to:

scan one or more of the plurality of whitelists for an entry associated with the requesting code module, wherein the entry includes a cryptographically secure hash associated with the requesting code module.

45. A code execution authorization system comprising:

a plurality of whitelists stored in one or more memory stores;

a plurality of content authenticators capable of being utilized to validate the integrity of the plurality of whitelists, wherein each of the plurality of content authenticators is assocatied with one of the plurality of whitelists; and

a remote signing server configured to;

sign each of the plurality of content authenticators to create a plurality of digital signatures; and

verify requests of the remote signing server originating from an authorized code module associated with the code execution authorization system.

46. The system of claim 45, wherein the remote signing server signs each of the plurality of content authenticators by using the hash supplied by a client and a private (PKI) key known only to the remote signing server.

47. The system of claim 45, wherein a signing request sent to the remote signing server is approved using one or more of a client machine identification, a client password, and a client'"'"'s internet protocol (IP) address.