US20170364679A1

US20170364679A1 - Instrumented versions of executable files

Info

Publication number: US20170364679A1
Application number: US15/185,499
Authority: US
Inventors: David John Babcock
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2016-06-17
Filing date: 2016-06-17
Publication date: 2017-12-21
Also published as: US10922408B2; US20180032730A1

Abstract

Examples described herein include receiving a loading request of an executable file from a requester. The executable file may include original content. Examples described herein also include determining an instrumented version of the executable file to provide to the requester based on a security policy, determining an existence of the instrumented version of the executable file on a storage, and providing the instrumented version of the executable file to the requester. The instrumented version may include protective content in addition to the original content of the executable file.

Description

BACKGROUND

An application may be vulnerable to security attacks during the application's runtime. An enterprise may try to mitigate these attacks by monitoring the application's behavior during its runtime and responding to unexpected behavior.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description references the drawings, wherein:

FIG. 1 is a block diagram of a computing device to provide an instrumented version of an executable file, according to some examples.

FIG. 2 is a block diagram of a computing device to determine and load an instrumented version of an executable file, according to some examples.

FIG. 3 is a flowchart of a method of providing an instrumented version of an executable file, according to some examples.

FIG. 4 is a block diagram of a computing device of a loading engine including a runtime engine to generate an instrumented version of an executable file, according to some examples.

FIG. 5A is a diagram of retrieving an instrumented version of an executable file from a storage, according to some examples.

FIG. 5B is a diagram of generating an instrumented version of an executable file, according to some examples.

FIG. 6 is a flowchart of a method of determining an existence of an instrumented version of an executable file, according to some examples.

DETAILED DESCRIPTION

One way to protect and monitor an application during its runtime is to add protective code (machine-readable instructions) to the application code (machine-readable instructions). The protective code allows for monitoring of the application during application runtime and may be configured for a particular portion of the application code. Thus, the protective code recognizes the types of security issues that may be encountered in that particular portion of the application code.
During the execution of the application, the protective code monitors the application (more specifically, that particular portion of the application code for which it is designed) and determines if any of the noted security issues occur. The protective code may create a security event to alert the application user when a noted security issue occurs. Additionally, the protective code may take measures to protect the application from the security threat (e.g., by intercepting an unexpected command, etc.).
In some situations, the protective code is not inserted directly into the application code. Rather, a call-out instruction is inserted into the application code. The call-out instruction directs to the protective code. In some situations, the call-out instruction may force-load the protective code during the application runtime. In some situations, the call-out instruction may direct to protective code that is already loaded. In some situations, the mechanism of inserting the call-out instruction is called instrumenting of the application code.
Information technology environments are evolving at a fast pace with new security threats emerging daily. Additionally, the operation of a particular application may vary depending on the enterprise that utilizes an application. For example, the environment of a first enterprise may mean that the first enterprise cares about a particular type of security issue while the environment of a second enterprise may mean that the second enterprise is not concerned about the same security issue.
Thus, to allow for effective application protection through call-out instructions to protective code, an enterprise may constantly update its security policy (i.e., a policy that defines what security issues are of concern). The security policy thus may dictate where the call-out instructions are inserted into the application code. However, in some situations, the addition of the call-out instruction to the application code (i.e., instrumenting the application code) is time-consuming and delays the loading of the application. Additionally, even if the security policy of the enterprise has not changed, the application code is re-instrumented each time the application is run in order to allow for the possibility of a security policy change.
Examples discussed herein addresses these technological challenges by allowing for a system to determine whether an instrumented version of an executable file (e.g., an application module, etc.) should be used according to a security policy. Responsive to a determination being made to use an instrumented version, examples discussed herein allow for the generation of the instrumented version, and the storage of the instrumented version for future use. Thus, examples disclosed herein may decrease the time it takes to load an application protected with call-out instructions by allowing the re-use of the stored instrumented version. Examples disclosed herein may also limit the generation of the instrumentation of an executable file to situations where there is an update in the security policy.
In some examples, a computing device is provided with a non-transitory machine-readable storage medium. The non-transitory machine-readable storage medium comprises instructions that, when executed, cause a processing resource to receive a loading request of an executable file from a requestor, determine an instrumented version of the executable file to provide to the requestor based on a security policy, determine an existence of the instrumented version on a storage, and provide the instrumented version to the requestor. The executable file comprises original content and the instrumented version of the executable file comprises protective content in addition to the original content.
In some examples, a method is provided, including receiving a loading request of an executable file, determining an instrumented version of the executable file based on a security policy, querying a reference dataset for an existence of the instrumented version, and providing the instrumented version of the executable file to be loaded. The executable file comprises original content and the instrumented version comprises protective content in addition to original content of the executable file.
In some examples, a computing device comprises a policy engine, a runtime engine, and a loading engine. The policy engine is to set a security policy. The runtime engine is to receive a loading request of an executable file, determine an instrumented version of the executable file based on the security policy, and determine an existence of the instrumented version of the executable file. The executable file comprises original content and the instrumented version of the executable file includes protective content in addition to original content of the executable file.
Referring now to the figures, FIG. 1 is a block diagram of a computing device 100 to provide an instrumented version of an executable file. As used herein, a “computing device” may be a server, computer networking device, chip set, desktop computer, workstation, personal device, point of sale (PoS) device, etc., or any other processing device or equipment. In some examples, computing device 100 is a server,
Computing device 100 includes a processing resource 101 and a machine-readable storage medium 110. Machine-readable storage medium 110 may be in the form of non-transitory machine-readable storage medium, such as suitable electronic, magnetic, optical, or other physical storage apparatus to contain or store information such as instructions 111, 112, 113, 114, related data, and the like.
As used herein, “machine-readable storage medium” may include a storage drive (e.g., a hard drive), flash memory, Random Access Memory (RAM), any type of storage disc (e.g., a Compact Disc Read Only Memory (CD-ROM), any other type of compact disc, a DVD, etc.) and the like, or a combination thereof. In some examples, a storage medium may correspond to memory including a main memory, such as a Random Access Memory, where software may reside during runtime, and/or a secondary memory. The secondary memory can, for example, include a nonvolatile memory where a copy of software or other data is stored.
Computing device 100 also includes instrumented storage 120. Instrumented storage 120 may be separate from machine-readable storage medium 110 or may be implemented by machine-readable storage medium 110. In some examples, instrumented storage 120 comprises a secondary memory portion as described above. Processing resource 101 is in communication with instrumented storage 120. In some examples, instrumented storage 120 may store instrumented versions of executable files. While instrumented storage 120 is shown in the example of FIG. 1 as being housed in computing device 100, in other examples, instrumented storage 120 may be separate from computing device 100 but accessible to processing resource 101 of computing device 100.
In the example of FIG. 1, instructions 111, 112, 113, and 114 are stored (e.g., encoded) on storage medium 110 and are executable by processing resource 101 to implement functionalities described herein in relation to FIG. 1. In some examples, storage medium 110 may include additional instructions, like, for example, the instructions to implement some of the functionalities described in relation to computing device 400 of FIG. 4. In some examples, the functionalities of any of the instructions of storage medium 110 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on machine-readable storage medium, or a combination thereof.
Processing resource 101 may, for example, be in the form of a central processing unit (CPU), a semiconductor-based microprocessor, a digital signal processor (DSP) such as a digital image processing unit, or other hardware devices or processing elements suitable to retrieve and execute instructions stored in a storage medium, or suitable combinations thereof. The processing resource can, for example, include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or suitable combinations thereof. The processing resource can be functional to fetch, decode, and execute instructions 111, 112, 113, and 114 as described herein.
In some examples, and as shown in FIG. 1, computing device 100 is communicatively coupled to a requestor 102. In some examples, requestor 102 may be another computing device. In some examples, the connection between requestor 102 may be a communication network, including but not limited to a wireless network, a wired network, or a combination thereof (e.g., local area network, wide area network, etc.). In other examples, requestor 102 may be directly connected to computing device 100.
In yet other examples, requestor 102 may be housed within the same computing device 100 and implemented by instructions on machine readable storage medium 110 that are executable by processing resource 101. For example, requestor 102 may be implemented by instructions to load an executable file.
Instructions 111 may be executable by processing resource 101 such that computing device 100 receives a loading request of an executable file from requestor 102. As used herein, a “loading request” may include an input that signals to computing device 100 that an executable file is going to be loaded (e.g., loaded into main memory and executed by a processing resource). For example, requestor 102 may want to execute a specific application program. Requestor 102 may signal to computing device 100 with a loading request that requestor 102 wants to load an executable file associated with the specific program into its random access memory (RAM). Instructions 111 receives this signal as a loading request of an executable file associated with the specific program. In some examples, a specific application program may include multiple executable files. Thus, a loading of an application program may involve the loading of multiple executable files. As used herein, an “executable file” may include instructions that are understood and executable by a processing resource. This may include intermediate code and binary code (e.g., machine code, bytecode, etc.). In some examples, an “executable file” includes source code. In some examples, the source code included in an executable file may be compiled before being executable by a processing resource. In other examples, the source code included in an executable file may be interpretively executed without being compiled (e.g., Forth programming language, etc) In some examples, an executable file may include instructions, that when executed by a processing resource, run part of a program application.
Instructions 112 may be executable by processing resource 101 such that computing device 100 determines an instrumented version of the executable file based on a security policy. The executable file comprises original content. As used herein, “content” refers to a certain function or set of functions that a computing device performs when a processing resource of the computing device executes the instructions in the executable file. Thus, while the exact language (or code) of two sets of instructions may be different from each other, the functionality of those two sets of instructions may be the same. Accordingly, as used herein, “original content” may include an original function that a processing resource performs when it executes the instructions in the executable file and “protective content” may include a function or specific set of functions addressing security vulnerabilities of the original content that the processing resource performs when it executes the instructions in the instrumented version of the executable file.
In some examples, the protective content may include a call-out to a protective instruction. As used herein, a “protective instruction” includes instructions that recognize, track, respond to, and/or report security issues that occur during the execution of the executable file. This includes instructions to modify data. As used herein, a “call-out” may include instructions that force-loads the protective instruction or instructions that directs to the protective instruction that is already loaded. Thus, in some examples, an instrumented version of the executable file does not include the protective instruction itself, but rather a call-out to the protective instruction. The protective instruction may be stored elsewhere in a secondary memory of computing device 100 (or requestor 102).
In some examples, a security policy may dictate what security issues are of concern and thus drive what protective content to add to the executable file, and where the protective content should be placed in the executable file. Thus, in examples where the protective content is a call-out to protective instructions, a security policy may include a list of applicable protective instructions and rules associated with each protective instruction. For example, a security policy that includes protecting against command injections in an application may include a command protective instruction. The command protective instruction may be directed to areas of code in the executable file of the application that are related to the processing of commands. When the command protective instruction is executed by a processing resource, the command protective instruction may allow a computing device to intercept commands received and review those commands before processing the commands. A rule associated with the command protective instruction may indicate that a particular portion of code in an executable file of the application is vulnerable to a command injection attack.
Based on the security policy, instructions 112 may determine an instrumented version of the executable file. In some examples, instructions 112 may include instructions to read the original content of the executable file from an executable file storage (not shown in FIG. 1) and analyze the original content of the executable file according to the rules associated with the applicable protective instructions. For example, in the command injection attack example as described above, instructions 112 may use the rule associated with the command protective instruction and determine that an executable file includes the particular portion of code that is marked by the associated rule as being vulnerable to a command injection attack. Thus, instructions 112 determines that an instrumented version of the executable file should be used and that instrumented version should include a call-out to the command protective instruction based on the security policy.
In some examples, instead of reading the original content of the executable file from the executable file storage, instructions 112 may query a reference dataset that indicates whether an executable file should be instrumented based on the security policy. In some examples, the reference dataset may be in a table format and operate as an index. In some examples, both the reference dataset and the analyzing of the original content may be used. For example, instructions 112 may determine an instrumented version of an executable file based on a security policy and store that determination in the reference dataset. The next time the same executable file is to be loaded under the same security policy, instructions 112 may then refer to the reference dataset to determine the instrumented version of the executable file.
As discussed above, instrumented storage 120 may store instrumented versions of executable files. Instructions 113 may be executable by processing resource 101 such that computing device 100 determines an existence of the instrumented version of a particular executable file on instrumented storage 120.
In some examples, the reference dataset discussed above in relation to instructions 112 may also reflect the instrumented versions of executable files that are stored in instrumented storage 120. Instructions 113 may include instructions to query the reference dataset to determine an existence of the instrumented version. For example, the reference dataset may be in the format of a table that operates as an index. The dataset may list specific executable files and associate it to an existing instrumented version, if an instrumented version exists in instrumented storage 120. The dataset may also indicate that an instrumented version of the executable file does not exist in instrumented storage 120. This is also discussed in relation to reference dataset storage 410 in FIG. 4. In some examples, instructions 113 may also include instructions to query instrumented storage 120 for the instrumented version of the executable file.
Instructions 114 may be executable by processing resource 101 such that computing device 100 provides the instrumented version of the executable file to requestor 102. In some examples, instructions 113 may determine that the instrumented version exists in the instrumented storage 120. In these examples, instructions 114 may supply the instrumented version of the executable file that is stored in the instrumented storage 120 to requestor 102.
In other examples, instructions 113 may determine that the instrumented version of the executable file does not exist in instrumented storage 120. In these examples, instructions 114 may include instructions to generate an instrumented version. In some examples, as discussed above, the protective content may be a call-out to a protective instruction. In these examples, the instructions to generate an instrumented version of the executable file may include instructions to select a relevant protective instruction and instructions to augment (e.g., by writing additional instructions) the original content of the executable file with the protective content. The selection of the protective instruction may be based on the security policy. Additionally, the location of the call-out in the executable file may be based on the rules associated with the protective instruction. For example, a rule may indicate that a particular portion of code may be vulnerable to a certain security attack. The call-out may be inserted at that particular portion of code in the executable file.
Instructions 114 may also include instructions to write the instrumented version to the instrumented storage 120, thus storing the instrumented version to the instrumented storage 120 for future use (e.g., a subsequent time in which the same executable file is loaded). Thus, in some examples, instrumented storage 120 may include a non-volatile type of memory (e.g., flash memory, etc.) that is persistent. In some examples, instrumented storage 120 may include a cache that is persistent. Instructions 114 may also include instructions to update the reference dataset to reflect that there is an instrumented version of an executable file in storage 120.
In some examples, machine-readable storage medium 110 may also include instructions to receive an update to the security policy. Because an update to the security policy may change what protective instructions are applicable, it may also change the instrumented versions of the executable files previously used under the old security policy.
Thus, instructions 112 may also include instructions to determine a second version of the executable file based on the updated security policy. In some examples, the second instrumented version of the executable file may be the same as an already instrumented version. For example, the update to the security policy may change an overall security policy but may not affect a particular executable file (e.g., the particular executable file does not have instructions that involve the security concern included in the security policy update). Thus, the update to the security policy may not affect the instrumented version and the second instrumented version may be the same as the first instrumented version.
In other examples, the second instrumented version of the executable file may be different from the instrumented version that was previously determined. In those examples, instructions 114 may include instructions to generate the second instrumented version of the executable file. The determination of the second instrumented version may be similar to the determination of the instrumented version that was already determined (i.e., the first instrumented version), except based on the updated security policy. The generation of the second instrumented version may be similar to the generation of the first instrumented version, except based on the updated security policy.
In some examples, the determination of the second instrumented version of the executable file is not linked to a loading request to load the executable file. For example, the instructions to determine a second instrumented version of the executable file may be processed by processing resource 101 responsive to the instructions to receive an updated security policy receiving the updated security policy. Thus, in some examples, computing device 100 does not wait to receive a loading request for an executable file to determine a second instrumented version of the executable file with reference to an updated security policy. Additionally, computing device 100 does not wait until instructions 111 receives a loading request for processing resource 101 to execute the instructions to generate the second instrumented version.
In some examples, instructions 114 may also include instructions to store the second instrumented version on instrumented storage 120. Thus, in some examples, computing device 100 may instrument executable files based on an updated security policy “in the background” even though computing device does not receive a request to load the executable file.
Thus, in some examples, instrumented storage 120 may be flushed when there is an update in the security policy. Flushing occurs, in some examples, when the data stored in the portion of the instrumented storage 120 that is persistent is removed. For example, the first instrumented version may be flushed when an update in the security policy changes the instrumented version of the executable file that should be used.
In some examples, machine-readable storage medium may also include instructions to provide the second instrumented version of the executable file to the requestor 102. In some examples, the second instrumented version is provided responsive to computing device 100 receiving a new request to load the same executable file. For example, a security policy change may occur in the middle of the loading of an application program that includes multiple executable files. Even though the security policy has changed and a second instrumented version of an executable file associated with the application program is generated and stored, the first instrumented version of the executable file (consistent with the old security policy) is provided to the requestor 103. This is so that all of the executable files of the application being loaded are under the same security policy. In these examples, instrumented storage 120 may be flushed responsive to an update in the security policy and responsive to a new request to load an executable file that has already been loaded that is affected by the update in security policy.
Computing device 100 of FIG. 1, which is described in terms of processors and machine readable storage mediums, may include one or more structural or functional aspects of computing device 200 of FIG. 3 or computing device 400 of FIG. 4, which are described in terms of engines containing hardware and software.
FIG. 2 is a block diagram of a computing device 200 to determine and load an instrumented version of an executable file. Computing device 200, like computing device 100, may be a server, computer networking device, chip set, desktop computer, workstation, personal device, point of sale (PoS) device, etc., or any other processing device or equipment. In some examples, computing device 200 is a server. Computing device 200 includes a policy engine 201, a runtime engine 202, a loading engine 203, and an instrumented storage 220. Each of these aspects of computing device 200 will be described below. Other engines may be added to computing device 200 for additional or alternative functionality. Instrumented storage 220 may be a machine-readable storage medium of computing device 200 that is similar to instrumented storage 120 of computing device 100.
Each of engines 201, 202, 203, and any other engines, may be any combination of hardware (e.g., a processor such as an integrated circuit or other circuitry) and software (e.g., machine or processor-executable instructions, commands, or code such as firmware, programming, or object code) to implement the functionalities of the respective engine. Such combinations of hardware and programming may be implemented in a number of different ways. A combination of hardware and software can include hardware (i.e., a hardware element with no software elements), software hosted on hardware (e.g., software that is stored in a memory and executed or interpreted by a processor), or by hardware and software hosted on hardware. Additionally, as used herein, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, the term “engine” is intended to mean at least one engine or a combination of engines. In some examples, computing device 200 may include additional engines, like some of the engines discussed in relation to computing device 400 and 500.
Each engine of computing device 200 can include at least one machine-readable storage mediums (for example, more than one) and at least one processing resource (for example, more than one). For example, software that provides the functionality of engines on computing device 200 can be stored on a memory of a computer to be executed by a processing resource of the computer. In some examples, each engines of computing device 200 may include hardware in the form of a microprocessor on a single integrated circuit, related firmware, or other software for allowing microprocessor to operatively communicate with other hardware of computing device 200.
Policy engine 201 is an engine of computing device 200 that includes a combination of hardware and software that allows computing device 200 to set a security policy. In some examples, policy engine 201 communicates with an input device (e.g., keyboard, etc.) that a user may use to input a security policy or change a security policy. In some examples, policy engine 201 may interface with a remote computing device (e.g., a server, etc.) to receive a security policy from the remote computing device which is set by a remote user. Policy engine 201 allows computing device 200 to receive the input and implement the security policy. In some examples, policy engine 201 may interface with security data (not shown) on computing device 200. Security data may be stored in a machine-readable storage medium of computing device 200 and may include information detailing the protective content associated with the security policy. In examples where the protective content includes a call-out to a protective instruction, the security data may store the protective instructions associated with the security policy and the rules that are associated with each protective instruction.
Policy engine 201 may also allow computing device 100 to receive an updated security policy and update the security data when the security policy is updated. Thus, for example, a security policy may include protecting against command injections. An updated security policy may indicate that the user no longer cares about command injections. Policy engine 201 may receive that change, and remove the protective content that is related to command injections (e.g., a command protective instruction and associated rule).
In some examples, security data may be housed off computing device 200 at a computing device that interfaces with the engines of computing device 200.
Runtime engine 202 is an engine of computing device 200 that includes a combination of hardware and software that allows computing device 200 to receive a loading request of an executable file that includes original content. The loading request in relation to FIG. 2 is for the computing device 200 to load the executable file. This is unlike in FIG. 1, where the loading request is for requestor 102 to load the executable file.
In some examples, this loading request may come from a user of computing device 200 interacting with a user input. Thus, in some examples, runtime engine 202 may include a user input. In some examples, the loading request may come from another computing device (not shown) that communicates with computing device 200.
Runtime engine 202 may also allow computing device 200 to determine an instrumented version of the executable file based on the security policy that is set by policy engine 201. As discussed above, the instrumented version of the executable file may include protective content in addition to the original content of the executable file. In some examples, runtime engine 202 may determine an instrumented version of the executable file in a similar manner that instructions 112 determines an instrumented version of an executable file, as discussed above. For example, runtime engine 202 may read an original content of the executable file from an executable file storage and analyze the original content based on the rules associated with the applicable protective content. As another example, runtime engine 202 may interface with a reference dataset that associates a particular executable file with an instrumented version of the executable file according to the security policy.
Runtime engine 202 may also allow computing device 200 to determine an existence of the instrumented version of the executable file on instrumented storage 220. In some examples, runtime engine 202 may query the reference dataset. The reference dataset may store information pertaining to a specific executable file and associate the specific executable file to an instrumented version of the executable file. The reference dataset may also store information pertaining to whether or not the instrumented version is stored on the instrumented storage 220, Runtime engine 202 may also query instrumented storage 220 for the instrumented version of the executable file. The discussion above in relation to instructions 114 is also applicable here.
In some examples, runtime engine 202 may also allow computing device 200 to determine a second instrumented version of the executable file based on a new or updated security policy set by policy engine 201. Runtime engine 202 may also allow computing device 200 to determine an existence of the second instrumented version of the executable file.
Loading engine 203 is an engine of computing device 200 that includes a combination of hardware and software that allows computing device 200 to load the instrumented version of the executable file. For example, loading engine 203 may load the instrumented version of the executable file provided by runtime engine 202 into a main memory to execute the instrumented version.
Computing device 200 of FIG. 2, which is described in terms of engines containing hardware and software, may include one or more structural or functional aspects of computing device 100 of FIG. 1, which is described in terms of processors and machine-readable storage medium.
FIG. 3 illustrates a flowchart for a method 300 to determine an instrumented version of an executable file and provide the instrumented version. Although execution of method 300 is described below with reference to computing device 100 of FIG. 1, other suitable systems for execution of method 300 may be utilized (e.g., computing device 200). Additionally, implementation of method 300 is not limited to such examples and it is appreciated that method 300 may be used for any suitable device or system described herein or otherwise.
At 310 of method 300, processing resource 101 may execute instructions 111 to receive a loading request from requestor 102 regarding an executable file. The executable file comprises original content. At 320 of method 300, processing resource 101 may execute instructions 112 to determine an instrumented version of the executable file that was requested to be loaded at 310. The instrumented version determined at 320 includes protective content in addition to the original content of the executable file. At 330 of method 300, processing resource 101 may execute instructions 113 to query a reference dataset stored on computing device 100 for an existence of the instrumented version of the executable file. As discussed above, the reference dataset may include information that associates whether or not an instrumented version of the requested executable file is stored on the instrumented storage 120.
At 340 of method 300, processing resource 101 may execute instructions 114 to provide the instrumented version of the executable file to the requestor 102 to be loaded.
Although the flowchart of FIG. 3 shows a specific order of performance of certain functionalities, method 300 is not limited to that order. For example, some of the functionalities shown in succession may be performed in a different order, may be executed concurrently or with partial concurrence, or a combination thereof. For example, 330 may be completed before 320 is started.
FIG. 4 is a block diagram of an example computing device 400 to determine and to load an instrumented version of an executable file. Computing device 400, like computing device 100 or computing device 200 may be a server, computer networking device, chip set, desktop computer, workstation, personal device, point of sale (PoS) device, etc., or any other processing device or equipment.
Computing device 400 includes a policy engine 401, a runtime engine 402, a loading engine 403, an instrumentation engine 404, a reference dataset storage 410, an instrumented storage 420, and an executable file storage 430. Other engines may be added to computing device 400 for additional or alternative functionality. Instrumented storage 420, executable file storage 430, and reference dataset storage 410 may be machine-readable storage media of computing device 400. Each storage may be implemented by separate medium or similar medium. In some examples, each of the executable file storage 430, instrumented storage 430, and reference dataset storage 410 is implemented by secondary memory as discussed above.
Each of engines 401, 402, 403, 404 and any other engines, may be any combination of hardware (e.g., a processor such as an integrated circuit or other circuitry) and software (e.g., machine or processor-executable instructions, commands, or code such as firmware, programming, or object code) to implement the functionalities of the respective engine. Such combinations of hardware and programming may be implemented in a number of different ways. A combination of hardware and software can include hardware (i.e., a hardware element with no software elements), software hosted on hardware (e.g., software that is stored in a memory and executed or interpreted by a processor), or by hardware and software hosted on hardware. Additionally, as used herein, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, the term “engine” is intended to mean at least one engine or a combination of engines. In some examples, computing device 400 may include additional engines.
Each engine of computing device 400 can include at least one machine-readable storage mediums (for example, more than one) and at least one processing resource (for example, more than one). For example, software that provides the functionality of engines on computing device 400 can be stored in a memory of a computer to be executed by a processing resource of the computer. In some examples, each engines of computing device 400 may include hardware in the form of a microprocessor on a single integrated circuit, related firmware, or other software for allowing microprocessor to operatively communicate with other hardware of computing device 400.
Policy engine 401 is an engine of computing device 400 that includes a combination of hardware and software that allows computing device 400 to set a security policy. Policy engine 401 is similar to policy engine 201 and thus, the discussion above to policy engine 201 is applicable to policy engine 401.
Runtime engine 402 is an engine of computing device 400 that includes a combination of hardware and software that allows computing device 400 to receive a loading request of an executable file that includes original content. In the example of FIG. 4, the loading request is for the computing device 400 to load the executable file.
Runtime engine 402 may also allow computing device 400 to determine an instrumented version of the executable file based on the security policy that is set by policy engine 401. Thus, runtime engine 402 may interface with policy engine 401. This is represented by line A in FIG. 4. As discussed above, the instrumented version of the executable file may include protective content in addition to the original content of the executable file.
In some examples, runtime engine 402 may determine an instrumented version of the executable file by reading an original content of the executable file from executable file storage 430 and analyze the original content based on the rules associated with the applicable protective content set by policy engine 401. The interfacing of runtime engine 402 with executable file storage 430 is represented by line D.
In some examples, runtime engine 402 may interface with reference dataset storage 410 to determine an instrumented version of the executable file. Reference dataset storage 410 may store information that associates a particular executable file with an instrumented version of the executable file according to the security policy. In some examples, a new reference dataset is generated and stored in reference dataset storage 410 responsive to the security policy being updated. In some examples, a new reference dataset is generated responsive to a new executable file that has not been loaded before being requested to be loaded (e.g., a new application including new executable files is requested to be loaded). The interfacing of runtime engine 402 with reference dataset storage 410 is represented by line B. In some examples, runtime engine 402 may analyze the original content of an executable file, determine an instrumented version of the executable file, and update the reference dataset storage 410 with the determination.
Runtime engine 402 may also allow computing device 400 to determine an existence of the instrumented version of the executable file on instrumented storage 420. In some examples, runtime engine 402 may query the reference dataset storage 410, as discussed above. In these examples, the reference dataset storage 410 may also store information pertaining to whether or not an instrumented version associated with an executable file is stored on the instrumented storage 420. In some examples, runtime engine 402 may also query instrumented storage 420 for the instrumented version of the executable file. The discussion above in relation to instructions 114 may also be applicable here.
Instrumentation engine 404 is an engine of computing device 400 that includes a combination of hardware and software that allows computing device 400 to generate an instrumented version of the executable file. For example, runtime engine 402 may determine that an instrumented version of the executable file should be used but the instrumented version does not exist on instrumented storage 420. Runtime engine 402 may trigger instrumentation engine 404 to generate an instrumented version of the executable file.
In some examples, instrumentation engine 404 may interface with executable file storage 430 (represented by line E in FIG. 4) to read the original content of the executable file. Instrumentation engine 404 may also interface with policy engine 401 (represented by line G in FIG. 4) and security data associated with policy engine 401 to determine the applicable protective content to add to the original content of the executable file. As discussed above, in some examples, the protective content includes a call-out to a protective instruction. Instrumentation engine 404 may augment the original content of the executable file with the protective content. In some examples, this may be inserting the protective content into the instructions of the executable file (e.g., inserting additional bytecode of the protective content into the original bytecode of the executable file). The location of the insertion in the executable file may be determined by rules associated with each protective content, as discussed above.
Instrumentation engine 404 may also allow computing device 400 to store the instrumented version in the instrumented storage 420 by interfacing with instrumented storage 420 (represented by line H in FIG. 4). In some examples, instrumentation engine 404 may interface with reference dataset storage 410 to update the reference dataset storage 410 to reflect that an instrumented version for the executable file 420 now exists in instrumented storage 420 (represented by line F in FIG. 4).
Loading engine 403 is an engine of computing device 400 that includes a combination of hardware and software that allows computing device 400 to load the instrumented version of the executable file. The instrumented version of the executable file may be provided to loading engine 403 by runtime engine 402. This is represented by line J in FIG. 4.
For example, loading engine 403 may load the instrumented version of the executable file provided by runtime engine 402 into a main memory to execute the instrumented version. Thus, in some examples, loading engine 403 does not interface directly with executable file storage 430 or instrumented storage 420 to load the instrumented version of the executable file. Rather, the instrumented version that the loading engine 403 loads is provided by runtime engine 402. For example, runtime engine 402 may appear as a file system to loading engine 403 and loading engine 403 may be provided a file path to the file system implemented by runtime engine 402 instead of the file path to the executable file in the executable file storage 430 or the file path of the instrumented version of the executable file in the instrumented storage 420. In other words, runtime engine 402 decides which file will be provided to the loading engine 403. Thus, in these examples, runtime engine 402 acts as a dynamic file system, in which the content of a file path provided to the loading engine 403 may be different although the file path to the runtime engine 402 may be the same. In other examples, and not shown in FIG. 4, runtime engine 402 may be part of loading engine 403 (e.g., a plug-in, attachment, etc.) that performs the same functionalities as discussed herein. In those examples, runtime engine 402 may not appear as a file system to loading engine 403.
As discussed above, in some examples, the security policy originally set by policy engine 401 may change or be altered (e.g., by a user input, etc.). Policy engine 401 allows computing device 400 to receive the change and implement the new security policy. Accordingly, in these examples, runtime engine 402 may allow computing device 400 to determine a second instrumented version of the executable file based on a new or updated security policy. Runtime engine 402 may also allow computing device 400 to determine an existence of the second instrumented version of the executable file on instrumented storage 420. Runtime engine 402 may also allow computing device 400 to generate the second instrumented version of the executable file and store it on instrumented storage 420. As discussed above in relation to computing device 100, the determination and the generation of the second instrumented version may be done without runtime engine 402 receiving a request to load the executable file. For example, runtime engine 402 may be triggered by policy engine 401 after it receives a change to the security policy to determine the second instrumented version of an executable file. Thus, this may be done “in the background.”
As discussed above, in some examples, instrumented storage 420 may be flushed responsive to there being a change to the security policy. In some examples, instrumented storage 420 may be flushed responsive to a new executable file being requested to be loaded that has not been loaded before (e.g., a new application including new executable files is requested to be loaded). Additionally, reference dataset storage 410 may also change responsive to there being a change to the security policy. For example, a new reference dataset may be generated responsive to there being a change to the security policy. Runtime engine 402 may also provide the second instrumented version to loading engine 403. In some examples, this may be done responsive to runtime engine 402 receiving a loading request for the executable device after the security policy is changed.
Computing device 400 of FIG. 4, which is described in terms of engines containing hardware and software, may include one or more structural or functional aspects of computing device 100 of FIG. 1, which is described in terms of processors and machine-readable storage medium. Additionally, while FIG. 4 shows certain lines representing communication between certain engines and storages, these lines are for explanation purposes and not meant to be exhaustive.
FIGS. 5A and 5B illustrate diagrams of various ways that the instrumented version of the executable file may be provided to the loading engine 403. FIG. 5A illustrates an example where runtime engine 402 determines that an instrumented version of the executable file exists in instrumented storage 420. Runtime engine 402 thus reads the instrumented version of the executable file from instrumented storage 420 and provides it to loading engine 403 to load.
FIG. 5B illustrates an example where runtime engine 402 determines the instrumented version of the executable file does not exist in instrumented storage 420. Runtime engine 402 may trigger instrumentation engine 404 to generate an instrumented version. Instrumentation engine 404 may read the original content of the executable file from executable file storage 430. Instrumentation engine 404 may augment the original content with the protective content and write it to instrumented storage 420. Runtime engine 402 may read the instrumented version from instrumented storage 420 and provide the instrumented version to loading engine 403 to be loaded.
FIG. 6 illustrates a flowchart for a method 600 to determine a version of the executable file to load. Although execution of method 600 is described below with reference to computing device 400 of FIG. 4, other suitable systems for execution of method 400 may be utilized (e.g., computing device 100 or computing device 200). Additionally, implementation of method 600 is not limited to such examples and it is appreciated that method 600 may be used for any suitable device or system described herein or otherwise.
At 610 of method 600, runtime engine 402 may receive a loading request for an executable file. As discussed above, in some examples, this request may come from a user input from a user of computing device 400. In some examples, this request may come from a server that relays an executable file should be loaded and executed. At 621, runtime engine 402 determines if instrumentation information about the executable file with regard to the applicable security policy set by policy engine 401 is available. Runtime engine 402 may do this by interfacing with reference dataset storage 410, as discussed above.
Responsive to there being no instrumentation information regarding the executable file in relation to the applicable security policy, method 600 proceeds to 622. For example, a new security policy may have been set by policy engine 401 and there may be no information that exists in reference dataset storage 410 regarding the executable file and the new security policy. As another example, this may be the first time that a particular executable file has been requested to be loaded in view of the security policy in effect. At 622, runtime engine 402 analyzes the original content of the executable file in relation to the security policy set to determine if an instrumented version should be provided.
Responsive to there being existing information in reference dataset storage 410 regarding the requested executable file, method proceeds from 621 to 623.
At 623, runtime engine 402 determines if an instrumented version should be provided. In examples where there was no information at 621, the determination at 623 may be based on the analysis of the original content in 622. In examples where there was information at 621, the determination at 623 may be based on reference dataset storage 410. For example, at 623, runtime engine 402 may interface with reference dataset storage 410. The information in reference dataset storage 410 may indicate that the original content of the executable file should be provided, not an instrumented version, or that an instrumented version should be provided, and not the original content. The reference dataset storage 410 may store this information based on a previous determination from runtime engine 402 involving the same executable file.
Responsive to runtime engine 402 determining that an instrumented version of the executable file should not be provided, method 600 proceeds from 623 to 630. At 630, runtime engine 402 provides loading engine 403 with the original content of the executable file stored in the executable file storage 430.
Responsive to runtime engine 402 determining that an instrumented version of the executable file should be provided, method 600 proceeds from 623 to 624. At 624, runtime engine 402 determines if an instrumented version already exists. As discussed above, runtime engine 402 may do this by interfacing with reference dataset storage 410 and/or by querying instrumented storage 420.
Responsive to runtime engine 402 determining that the instrumented version already exists in instrumented storage 420, method 600 proceeds from 624 to 625. At 625, runtime engine 402 provides the instrumented version from the instrumented storage 420 to loading engine 403.
Responsive to runtime engine 403 determining that the instrumented version does not exist in instrumented storage 420, method 600 proceeds from 624 to 626. At 626, runtime engine 402 triggers instrumentation engine 404 to generate an instrumented version of the executable file, as discussed above. At 627, instrumentation engine 404 stores the instrumented version of the executable file in the instrumented storage 420. At 628 instrumentation engine 404 interfaces with reference dataset storage 410 to update the reference dataset storage to reflect the existence of the instrumented version of executable file. At 629 runtime engine 402 provides the instrumented version of the executable file to loading engine 403 from the instrumented storage 420.
Thus, FIG. 6 shows an example where runtime engine 403 acts as a dynamic file system, as discussed above in relation to FIG. 4. For example, runtime engine 403 may decide to provide the original content of the executable file to loading engine 403 (at 630), or an old instrumented version of the executable file from instrumented storage 420 to loading engine 403 (at 625). Additionally, runtime engine 403 may decide to trigger instrumentation engine 404 to generate a new instrumented version and provide the new instrumented version to loading engine 403 (at 629).
Although the flowchart of FIG. 6 shows a specific order of performance of certain functionalities, method 600 is not limited to that order. For example, some of the functionalities shown in succession may be performed in a different order, may be executed concurrently or with partial concurrence, or a combination thereof. For example, 621 and 623 may be performed concurrently. In some examples, functionalities described herein in relation to FIG. 6 may be provided in combination with functionalities described herein in relation to any of FIGS. 1-5.
All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the elements of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or elements are mutually exclusive.

Claims

What is claimed is:

1. A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a processing resource to:

receive a loading request of an executable file from a requestor, the executable file comprising original content;

determine an instrumented version of the executable file to provide to the requestor based on a security policy, wherein the instrumented version of the executable file comprises protective content in addition to the original content of the executable file;

determine an existence of the instrumented version of the executable file on a storage; and

provide the instrumented version of the executable file to the requestor.

2. The non-transitory machine-readable storage medium of claim 1, wherein the protective content comprises a call-out to a protective instruction.

3. The non-transitory machine-readable storage medium of claim 2, wherein the instructions to provide the instrumented version of the executable file comprises:

instructions to generate the instrumented version of the executable file.

4. The non-transitory machine-readable storage medium of claim 3, wherein the instructions to generate the instrumented version of executable file comprises:

instructions to select the protective instruction; and

instructions to augment the original content of the executable file with the call-out to the protective instruction.

5. The non-transitory machine-readable storage medium of claim 4, wherein the instructions to generate the instrumented version of the executable file comprises:

instructions to store the instrumented version of the executable file in the storage.

6. The non-transitory machine-readable storage medium of claim 5, comprises:

instructions to update a reference dataset regarding the generation of the instrumented version of the executable file,

7. The non-transitory machine-readable storage medium of claim 1, comprising:

instructions to receive an updated security policy;

instructions to determine a second instrumented version of the executable file based on the updated security policy;

instructions to generate the second instrumented version of the executable file; and

instructions to store the second instrumented version of the executable file in the storage.

8. The non-transitory machine-readable storage medium of claim 1, wherein the instructions to determine an existence of the instrumented version of the executable file comprises instructions to query a reference dataset.

9. A method comprising:

receiving a loading request of an executable file, the executable file comprising original content;

determining an instrumented version of the executable file based on a security policy, wherein the instrumented version comprises protective content in addition to the original content of the executable file;

querying a reference dataset for an existence of the instrumented version of the executable file; and

providing the instrumented version of the executable file to be loaded.

10. The method of claim 9, wherein the reference dataset reflects instrumented files stored on a first storage.

11. The method of claim 10, wherein the providing of the instrumented version of the executable file to be loaded comprises reading the instrumented version of the executable file from the first storage.

12. The method of claim 10, comprising:

generating the instrumented version of the executable file; and

storing the instrumented version of the executable file on the first storage.

13. The method of claim 12, wherein the generating of the instrumented version of the executable file comprises:

reading the original content of the executable file from a second storage; and

augmenting the original content of the executable file with the protective content,

14. The method of claim 13, wherein the protective content comprises a call-out to protective instructions.

15. The method of claim 10, comprising:

updating the security policy;

determining a second instrumented version of the executable file based on the updated security policy;

generating the second instrumented version of the executable file;

storing the second instrumented version of the executable file on the first storage; and

providing the second instrumented version of the executable file to be loaded.

16. A computing device comprising:

a policy engine to set a security policy;

a runtime engine to

receive a loading request of an executable file, the executable file comprising original content;

determine an instrumented version of the executable file based on the security policy, wherein the instrumented version of the executable file comprises protective content in addition to the original content of the executable file;

determine an existence of the instrumented version of the executable file; and

a loading engine to load the instrumented version of the executable file.

17. The computing device of claim 15, comprising an instrumentation engine to generate the instrumented version of the executable file.

18. The computing device of claim 17,

wherein the policy engine is to set a new security policy;

wherein the runtime engine is to determine a second instrumented version of the executable file based on the new security policy; and

wherein the instrumentation engine is to generate the second instrumented version of the executable file and store the second instrumented version.

19. The computing device of claim 16, wherein the runtime engine is to query a reference dataset to determine an existence of the instrumented version of the executable file.

20. The computing device of claim 16, wherein the runtime engine is to query a reference dataset to determine the instrumented version of the executable file.