Peer assembly inspection

• US 20030226033A1
• Filed: 05/30/2002
• Published: 12/04/2003
• Est. Priority Date: 05/30/2002
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Olson, Erik Bryce, Zinda, Eric Kenneth
• Granted Patent: US 7,634,806 B2
• Time in Patent Office: Days
• US Class Current: 713/201
• CPC Class Codes: G06F 21/52 during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
• CPC Class Codes: H04L 63/101 Access control lists [ACL]

Abstract

A method and system for preventing undesired behaviors by executable code modules in a peer-to-peer computer system are provided. When a code module is received, an assembly inspection module queries a blacklist for the received code module. When the received code module is found on the blacklist, the computer system prevents execution of the received code module. Each peer includes an assembly inspection module. When the received code module is not found on the blacklist, the assembly inspection module inspects the received executable code module, prior to execution, to determine whether the code module can perform any undesired behaviors. If so, the received code module is added to the blacklist and prevented from executing.

Claims

1. A method for preventing undesirable behavior by an executable code module received from a potentially untrusted source, comprising:

(i) querying a database for identifying information corresponding to an executable code module received at a host system;

(ii) when step (i) returns a predetermined result, scanning the code module for an indication that the code module has a potential to cause undesired behavior in the receiving host when executed; and

(iii) when step (ii) finds the indication the code module has the potential to cause undesired behavior in the receiving host when executed, preventing execution of the code module at the receiving host.

2. The method of claim 1, wherein in step (ii) the predetermined result comprises not finding the identifying information in the database.

3. The method of claim 1, further comprising the step of preventing execution of the code module when step (i) finds in the database the identifying information corresponding to the code module.

4. The method of claim 1, further comprising the step of adding the identifying information to the database when step (ii) finds the indication the code module has the potential to cause undesired behavior in the receiving host when executed.

5. The method of claim 1, wherein in step (ii) the indication comprises a predetermined computer instruction.

6. The method of claim 1, wherein in step (ii) the indication comprises an instruction that initiates use of a system resource.

7. The method of claim 6, wherein the system resource comprises a CPU.

8. The method of claim 6, wherein the system resource comprises spawning a system thread.

9. The method of claim 6, wherein the system resource comprises memory.

10. The method of claim 6, wherein the system resource comprises a user interface.

11. The method of claim 1, wherein the database comprises a blacklist database.

12. The method of claim 1, wherein the identifying information corresponding to the code module comprises a name of a file.

13. The method of claim 1, wherein the identifying information corresponding to the code module comprises a strong name.

14. The method of claim 1, wherein step (ii) comprises scanning the code module for any instruction of a plurality of instructions that have the potential to cause undesired behavior in the receiving host when executed, and further comprising:

(iv) executing the code module when step (iii) does not find any of the plurality of instructions.

15. The method of claim 1, wherein step (ii) comprises:

(a) mapping the code module to a memory;

(b) determining whether a mapped image is valid; and

(c) determining whether code module metadata is well-formed.

16. The method of claim 1, wherein step (ii) comprises:

(a) enumerating each managed type used by the code module;

(b) enumerating each member of each managed type enumerated in step (a); and

(c) comparing each enumerated value to a list of predetermined values.

17. The method of claim 16, wherein the indication comprises a predetermined managed type.

18. The method of claim 16, wherein the indication comprises a derivative of a predetermined managed type.

19. The method of claim 1, wherein the indication comprises a predetermined constructor.

20. The method of claim 1, wherein the indication comprises a type visibility.

21. A computer system that prevents an executable code module from performing an undesired behavior when executed, comprising:

a database storing identifying information corresponding to executable code modules that can perform undesired behavior when executed on the computer system;

an assembly inspection module that scans executable code modules received from peer computer systems to determine whether each executable code module has a potential to perform an undesired behavior when executed on the computer system;

memory storing computer readable instructions that, when executed by a processor of the computer system, cause the computer system to perform steps comprising;

(i) querying the database for identifying information corresponding to a received executable code module;

(ii) when step (i) returns a predetermined result, causing the assembly inspection module to scan the received executable code module; and

(iii) preventing execution of the received executable code module when the assembly inspection module determines that the received executable code module has the potential to perform an undesired behavior when executed on the computer system.

22. The system of claim 21, wherein the computer readable instructions further cuase the computer system to perform the step of preventing the received executable code module from executing when the identifying information corresponding to the received executable code module is found in the database in step (i).

23. The system of claim 21, wherein in step (ii) the predetermined result comprises not finding the identifying information in the database.

24. The system of claim 21, wherein the computer readable instructions further cause the computer system to perform the step of adding the identifying information to the database when the assembly inspection module determines that the received executable code module has the potential to perform an undesired behavior when executed on the computer system.

25. The computer system of claim 21, wherein the assembly inspection module scans the received executable code module for a predetermined computer executable instruction.

26. The computer system of claim 21, wherein the identifying information corresponding to the received executable code module comprises a name of the received executable code module.

27. The computer system of claim 21, wherein the assembly inspection module scans the received executable code module for any computer executable instruction of a plurality of instructions that have the potential to cause undesired behavior in the computer system when executed, and wherein the computer readable instructions further cause the computer system to perform the step of executing the received executable code module when the assembly inspection module does not find any of the plurality of instructions.

28. The computer system of claim 21, wherein the assembly inspection module is adapted to enumerate each managed type used by the code module, and to enumerate each member of each enumerated managed type.

29. The computer system of claim 21, wherein the assembly inspection module scans for a predetermined managed type.

30. The computer system of claim 21, wherein the assembly inspection module scans for any derivative of a predetermined managed type.

31. A computer architecture comprising a plurality of peer computer systems, each peer comprising an execution shell for running executable code modules, said each execution shell comprising:

a discovery module that detects other peer computing systems;

an interaction module for communicating with other execution shells of other detected peer computing systems;

an assembly inspection module comprising;

a database of blacklisted agent programs;

computer readable instructions that, when executed by a processor of the peer computer system, cause the peer computer system to perform steps comprising;

(i) querying the database for identifying information corresponding to a received executable code module;

(ii) preventing the received executable code module from executing when the identifying information corresponding to the received executable code module is found in the database;

(iii) scanning the received executable code module when the identifying information corresponding to the received executable code module is not found in the database; and

(iv) adding the identifying information corresponding to the received executable code module when the assembly inspection module determines that the received executable code module has the potential to perform an undesired behavior when executed on the peer computer system.

32. A method for preventing undesirable behavior by executable code modules received from a potentially untrusted source, comprising:

(i) scanning each received executable code module for an indication that the received executable code module has a potential to cause undesired behavior in a host system when executed; and

(ii) preventing execution of any received executable code module by the host system when step (i) finds said indication in the received executable code module.

33. The method of claim 32, wherein the indication comprises an instruction that initiates use of a system resource.

34. The method of claim 33, wherein the system resource comprises a CPU.

35. The method of claim 33, wherein the system resource comprises spawning a system thread.

36. The method of claim 33, wherein the system resource comprises memory.

37. The method of claim 33, wherein the system resource comprises a user interface.

38. The method of claim 32, wherein step (i) comprises scanning the code module for any instruction of a plurality of instructions that have the potential to cause undesired behavior in the receiving host when executed, and further comprising:

(iii) executing the code module when step (i) does not find any of the plurality of instructions.

39. The method of claim 32, wherein step (i) comprises:

(a) mapping the code module to a memory;

(b) determining whether a mapped image is valid; and

(c) determining whether code module metadata is well-formed.

40. The method of claim 32, wherein step (i) comprises:

(a) enumerating each managed type used by the code module;

(b) enumerating each member of each managed type enumerated in step (a); and

(c) comparing each enumerated value to a list of predetermined values.

41. The method of claim 40, wherein the indication comprises a predetermined managed type.

42. The method of claim 40, wherein the indication comprises a derivative of a predetermined managed type.

43. The method of claim 40, wherein the indication comprises a type visibility.