Security enforcement in the presence of dynamic code loading

• US 10,296,737 B2
• Filed: 12/09/2015
• Issued: 05/21/2019
• Est. Priority Date: 12/09/2015
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Bello, Luciano, Ferrara, Pietro, Pistoia, Marco, Tripp, Omer
• Primary Examiner(s): Shepperd, Eric W
• Assistant Examiner(s): Pan, Peiliang
• Application Number:
  US14/964,162
• Publication Number:
  US 20170169212A1
• Time in Patent Office: 1,259 Days
• Field of Search: 726 1, 726 23- 25
• 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/562 Static detection
• CPC Class Codes: G06F 21/566 Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities

Abstract

A method (and structure) for enforcing a security policy includes retrieving from a memory a program to be verified against a security policy and a security specification defining the security policy. A static program analysis is performed on the program, using a processor on a computer, to determine whether the program is compatible with the security specification. The program is rejected if the program is determined by the static program analysis as being incompatible with the security specification. If the program is determined during the static program analysis as compatible with the security specification under static analysis criteria, then building a call-graph representation of the program for use to evaluate any dynamically-loaded code during an execution of the program. Any paths, if any, of the call-graph representation that reach at least one policy-relevant operation is marked.

Claims

1. A method for verifying a software program for security, the method comprising:

retrieving from a memory a program to be verified against a security policy and a security specification defining said security policy, the retrieved program comprising only static code available for evaluation before additional code is added during a dynamic linking of an execution of said program;

applying a static program analysis on said static code of said program, using a processor on a computer, to determine whether said static code of said program is compatible with said security specification; and

if a determination is made by said static program analysis that said static code of said program is incompatible with said security specification, rejecting said program as non-compliant; and

else, the determination is made by said static program analysis that said static code of said program is compatible with said security specification, then building a call-graph representation of said program for use to evaluate any dynamically-loaded code during an execution of said program, and indicating paths of said call-graph representation that reach at least one policy-relevant operation during the execution,

wherein the static analysis first statically determines whether the static code of said program complies with all security policies in the security specification prior to any dynamic code loading, the program to be then dynamically checked only for aspects that were not verified during said static analysis.

2. The method of claim 1, further comprising:

during any of a dynamic loading of code during execution of said program, determining whether any said paths of said call-graph representation indicated as reaching at least one policy-relevant operation have been dynamically loaded;

if it is determined that no paths indicated as reaching at least one policy-relevant operation have been dynamically loaded, determining that said dynamic loading is verified for said security policy; and

if it is determined that any paths indicated as reaching at least one policy-relevant operation have been dynamically loaded in a call chain, then determining whether each said dynamically-loaded path in said call chain is compatible with said security policy.

3. The method of claim 2, further comprising:

if it is determined that all paths in the call chain indicated as reaching at least one policy-relevant operation and have been dynamically loaded are compatible with said security specification, determining that said dynamic loading is verified for said security policy; and

rejecting said program if it is determined that any of said paths indicated as reaching at least one policy-relevant operation and has been dynamically loaded is incompatible with said security specification.

4. The method of claim 1, wherein said static analysis comprises a taint tracking in which the static analysis starts at an application program interface (API) service that reads private fields, checks whether such APIs reach any internet APIs, and flags a violation if any internet API addresses a domain that is not statically known or not compatible with a whitelist.

5. The method of claim 1, wherein said static analysis issues an objection if the static analysis determines that any security-critical operation would be executed from dynamically-loaded code.

6. A non-transitory storage medium having tangibly embodied thereon a set of computer-readable claims that cause a computer to execute the method of claim 1.

7. The non-transitory storage medium of claim 6, wherein said method further comprises:

during any of a dynamic loading of code during an execution of said program, determining whether any said paths of said call-graph representation indicated as reaching at least one policy-relevant operation have been dynamically loaded;

if it is determined that no paths indicated as reaching at least one policy-relevant operation have been dynamically loaded, determining that said dynamic loading is verified for said security policy; and

if it is determined that any paths indicated as reaching at least one policy-relevant operation have been dynamically loaded, then determining whether each said dynamically-loaded path is compatible with said security policy.

8. The non-transitory storage medium of claim 7, wherein said method further comprises:

if it is determined that all paths indicated as reaching at least one policy-relevant operation and have been dynamically loaded are compatible with said security specification, determining that said dynamic loading is verified for said security policy; and

rejecting said program if it is determined that any of said paths indicated as reaching at least one policy-relevant operation and have been dynamically loaded are incompatible with said security specification.

9. The non-transitory storage medium of claim 8, as comprising one of:

a memory in a processor-based device that stores programs that can selectively-executed by a processor in said processor-based device or that can be selectively transmitted to another processor-based device via a network;

a memory of said processor-based device that stores programs currently being executed by said processor-based device; and

a standalone memory device that can be selectively inserted into an input port of said processor-based device.

10. The non-transitory storage medium of claim 6, wherein said static analysis comprises a taint tracking in which the static analysis starts at an application program interface (API) service that read private fields and checks whether such APIs reach any internet APIs and flags a violation if any internet API addresses a domain that is not statically known or not compatible with a whitelist.

11. The non-transitory storage medium of claim 6, wherein said static analysis issues an objection if the static analysis determines that any security-critical operation would be invoked during execution of dynamically-loaded code.

12. An apparatus, comprising:

a processor; and

a memory system accessible to said processor,

wherein said memory system has stored therein a set of computer-readable instructions that instruct said processor to execute a method for verifying a program for compliance with a security policy and a security specification, the program comprising static code that is statically declared but having no code that is to be dynamically-loaded during an execution of said program, said method comprising;

retrieving from a memory a program to be verified against a security policy and a security specification defining said security policy;

applying a static program analysis on static code of said program, using a processor on a computer, to determine whether said program is compatible with said security specification, the static program analysis verifying security compliance on the static code that is statically declared; and

if a determination is made by said static program analysis that said static code of said program is incompatible with said security specification, rejecting said program as non-compliant; and

else, the determination is made by said static program analysis that said static code of said program is compatible with said security specification, then building a call-graph representation of said program for use to evaluate any dynamically-loaded code during an execution of said program, and indicating paths of said call-graph representation that reach at least one policy-relevant operation during the execution,

wherein the static analysis first statically determines whether the static code of said program complies with all security policies in the security specification prior to any dynamic code loading, the program to be then dynamically checked only for aspects that were not verified during said static analysis.

13. The apparatus of claim 12, wherein said method further comprises:

during any of a dynamic loading of code during execution of said program, determining whether any said paths of said call-graph representation indicated as reaching at least one policy-relevant operation have been dynamically loaded;

if it is determined that no paths indicated as reaching at least one policy-relevant operation have been dynamically loaded, determining that said dynamic loading is verified for said security policy; and

if it is determined that any paths indicated as reaching at least one policy-relevant operation have been dynamically loaded, then determining whether each said dynamically-loaded path is compatible with said security policy.

14. The apparatus of claim 13, wherein said method further comprises:

if it is determined that all paths indicated as reaching at least one policy-relevant operation and have been dynamically loaded are compatible with said security specification, determining that said dynamic loading is verified for said security policy; and

rejecting said program if it is determined that any of said paths indicated as reaching at least one policy-relevant operation and has been dynamically loaded is incompatible with said security specification.

15. The apparatus of claim 14, as comprising one of a mobile device, a desktop computer, a server on a network, and a computer providing a cloud service.

16. A method for verifying a software program for security, the method comprising:

retrieving from a memory a program to be verified against a security policy and a security specification defining said security policy;

applying a static program analysis on a static portion of said program, using a processor on a computer, to determine whether said static portion is compatible with said security specification; and

if a determination is made by said static program analysis that said static code of said program is incompatible with said security specification, rejecting said program as non-compliant; and

else, the determination is made by said static program analysis that said static code of said program is compatible with said security specification, then building a call-graph representation of said program for use to evaluate any dynamically-loaded code during an execution of said program, and indicating paths of said call-graph representation that reach at least one policy-relevant operation during the execution,

wherein the static analysis first statically determines whether the static code of said program complies with all security policies in the security specification prior to any dynamic code loading, the program to be then dynamically checked only for aspects that were not verified during said static analysis.

17. The method of claim 16, wherein the static analysis initially statically determines whether all security policies in the security policy hold over the static portion of said program prior to any dynamic code loading and wherein the indications of paths of the program that reach at least one policy-relevant operation permit the program to be checked at execution only for aspects that were not verified during said static analysis.

18. The method of claim 17, further comprising:

retrieving the program from the memory for execution, along with the associated call-graph representation of the program;

adding dynamic code necessary for execution of the program, the added dynamic code not having been present in the static portion of said program during the static program analysis;

determining, from the indications of the associated call-graph representation of the program, which paths of the program to verify prior to execution of the program as compatible with said security specification;

dynamically analyzing the program to determine whether said program is compatible with said security specification by checking only those paths of the program that will be executed and that are indicated on the associated call-graph representation as reaching at least one policy-relevant operation when dynamically-coded is added to the program; and

rejecting said program as non-compliant when it is determined by said dynamic analyzing that at least one path indicated on the call-graph that will be executed is incompatible with said security specification; and

executing the program when it is determined by said dynamic analyzing that all paths including dynamically-added code that will be executed in the execution of said program are compatible with said security specification.