BACKGROUND

[0001 ] Applications often contain vulnerabilities. At least one binary is typically executed to perform the application.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG. 1A is a block diagram of an example computing device for loading custom code in binary;

[0004] FIG. 1 B is a block diagram of an example computing device for loading custom code in binary including modifying portable executable instructions and adding additional code section instructions;

[0005] FIG. 2A is a diagram of an example system for loading custom code in binary;

[0006] FIG. 2B is a schematic diagram of an example binary for loading custom code;

[0007] FIG. 3A is a flowchart of an example method for loading custom code in binary;

[0008] FIG. 3B is a flowchart of an example method for loading custom code in binary including modifying a portable executable header of a binary;

[0009] FIG. 4 is a flowchart of an example method for loading custom code in binary including determining whether there is adequate space in a code section.

DETAILED DESCRIPTION

[0010] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. While several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the following detailed description does not limit the disclosed examples. Instead, the proper scope of the disclosed examples may be defined by the appended claims.

[001 1 ] With the rapid growth in the use of computers to host business applications, websites, cloud, etc., the complexity and sensitivity of programs used to perform these functions have also rapidly evolved. These computer applications may have vulnerabilities that may be possible opportunities for exploits and attacks. As a result, applications may be periodically updated in order to address possible risks. Typically, this may be accomplished by application patches that modify the source code of applications.

[0012] However, instances may arise when an application is updated to patch vulnerabilities, but the patch is not deployed. Furthermore, in some cases, a vendor may opt to patch some versions of their application and not others. When this occurs, customers may be driven to cease usage of the affected product to ensure their critical infrastructure is not compromised. Additionally or in other situations, customers may be forced to use a specific version of an application to conform to hardware requirements. Upgrading the application to the latest version to resolve security issues may introduce new functionality that forces the underlying hardware to malfunction.

[0013] Examples disclosed herein address these technical challenges by loading custom code in a binary being executed to perform an application. An example computing device may identify a vulnerability in an application. The example computing device may then modify, possibly in real-time, a binary being executed to perform the application by loading a custom code. In some examples, the binary may be modified while the application is offline. The custom code may address a root cause of the vulnerability. The example computing device may then execute the binary with the loaded custom code. In this manner, examples herein may remediate security vulnerabilities without introducing new functionality into the application.

[0014] Referring now to the drawings, FIG. 1 A depicts an example computing device 100 for loading a custom code in a binary. Computing device 100 may be, for example, a cloud server, a local area network server, a web server, a mainframe, a mobile computing device, a notebook or desktop computer, a smart TV, a point-of-sale device, a wearable device, any other suitable electronic device, or a combination of devices, such as ones connected by a cloud or internet network, that perform the functions described herein. In the example shown in FIG. 1A, computing device 100 includes a processor 1 10 and a non-transitory machine-readable storage medium 120 encoded with instructions to load custom code in binary.

[0015] Processor 1 10 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 120. Processor 1 10 may fetch, decode, and execute instructions 121 , 122, 123, and/or other instructions to implement the procedures described herein. As an alternative or in addition to retrieving and executing instructions, processor 1 10 may include one or more electronic circuits that include electronic components for performing the functionality of one or more of instructions 121 , 122, and 123.

[0016] In one example, the program instructions 121 , 122, 123, and/or other instructions can be part of an installation package that can be executed by processor 1 10 to implement the functionality described herein. In this case, memory 120 may be a portable medium such as a CD, DVD, or flash drive or a memory maintained by a computing device from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed on computing device 100

[0017] Machine-readable storage medium 120 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable data accessible to computing device 100. Thus, machine-readable storage medium 120 may be, for example, a Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, and the like. Storage medium 120 may be a non-transitory storage medium, where the term "non-transitory" does not encompass transitory propagating signals. Storage medium 120 may be located in computing device 100 and/or in another device in communication with computing device 100. As described in detail below, machine-readable storage medium 120 may be encoded with identify vulnerability instructions 121 , modify binary instructions 122, and execute binary instructions 123.

[0018] Identify vulnerability instructions 121 , when executed by processor 1 10, may identify a vulnerability in an application. An application may be a computer program designed to permit users, such as persons or group of persons, to perform an activity, such as a group of coordinated functions and tasks. Applications may be executable by computing device 100. Non-limiting examples of applications may include office suites, media players, business programs, games, simulators, illustrating systems, and management systems.

[0019] Identify vulnerability instructions 121 , when executed by processor 1 10, may identify a vulnerability. A vulnerability may be a weakness of an asset or group of assets that can be exploited by one or more threats. Specially, a vulnerability may be a weakness which may allow an attacker to reduce a computer system's information assurance. Examples of vulnerabilities include memory safety violations (e.g., buffer overflows), input validation errors (e.g., format string attacks), race conditions, privilege-confusion bugs, privilege escalation, and/or user interface failures.

[0020] In some examples, machine-readable storage medium 120 may further include instructions to determine a root cause of the vulnerability. Examples of root causes may be code section that contain weaknesses caused by, for example, complexity of the system, password management flaws, fundamental design flaws, programming bugs, and unchecked user inputs. As discussed herein, determining the root cause of the vulnerability may allow the recognition of an appropriate response to the vulnerability.

[0021 ] Modify binary instructions 122, when executed by processor 1 10, may modify a binary being executed to perform the application by loading a custom code. A binary may be an executable program that causes a computer, such as computing device 100, to perform tasks according to encoded instructions, such as the source code for the application being performed.

[0022] Modify binary instructions 122 may modify the binary by loading a custom code. The custom code may be a section of code that may be loaded to the binary. In some examples, the custom code may be based on the root cause of the vulnerability. For example, the custom code may address the root cause. The custom code may address the vulnerability by causing execution of an appropriate response based on the root cause. In some examples, the custom code may provide remediation for the vulnerability that exists within the code, log the exploit attempt, and/or safely terminate the application. The custom code may be loaded into the binary without access to the source code of the application.

[0023] In some examples, modify binary instructions 122 may modify the binary while the application is offline. As an alternative, in some examples, modify binary instructions 122 may modify the binary in real-time, meaning the modification may be performed subject to a real-time constraint, for example operational deadlines from event to system response. For example, the modification may be performed between the time that the vulnerability was identified and the code associated with the vulnerability is executed. Accordingly, execution of the binary with the custom code may address the vulnerability before the application is placed at risk.

[0024] In some examples, the custom code may be loaded to the binary by adding the custom code to the end of a code section, such as .text section of the portable executable. When code of the binary is mapped to memory, unused space may exist in the .text section. This unused space may be used for loading the custom code. Alternatively, an additional code section may be added to the binary. In such examples, this additional code section may be used for loading the custom code.

[0025] In some examples, storage medium 120 may further include instructions to modify a portable executable header of the binary with information related to the custom code. The portable executable header may be a data structure that encapsulates information necessary for the binary to load the source code of the application. The portable executable header of the binary may be modified to facilitate replacement of a code section associated with the root cause with the custom code. For example, the portable executable may redirect the binary from the vulnerable code to the custom code at the appropriate time in order to address the vulnerability. For example, the portable executable header of the binary may be modified to facilitate replacement of a code section associated with the vulnerability with the custom code. [0026] Execute binary instructions 123, when executed by processor 1 10, may cause computing device 100 to perform the code loaded in the binary, including the custom code. The presence of the custom code may resolve potential issues that could be caused by the vulnerability.

[0027] FIG. 1 B depicts an example computing device 150 for loading custom code in binary, which may be analogous to computing device 100 and which may include additional instructions. In the example in FIG. 1 B, computing device 150 includes a processor 160 and a non-transitory machine-readable storage medium 170 encoded with instructions to load custom code in binary.

[0028] Processor 160 may fetch, decode, and execute instructions 171 , 172, 173, 174, 175, 176, and/or other instructions to implement the procedures described herein. In addition or as an alternative, the program instructions 171 , 172, 173, 174, 175, 176, and/or other instructions can be part of an installation package that can be executed by processor 160 to implement the functionality described herein. In other examples, the program instructions may be part of an application or applications already installed on computing device 150.

[0029] As described in detail below, machine-readable storage medium 170 may be encoded with identify vulnerability instructions 171 , determine root cause instructions 172, load custom code instructions 173, modify portable executable instructions 174, add additional code section instructions 175, and execute binary instructions 176.

[0030] Identify vulnerability instructions 171 may be analogous to identify vulnerability instructions 121 of computing device 100 and may, when executed by processor 160, identify a vulnerability in an application.

[0031 ] Determine root cause instructions 172 may, when executed by processor 160, determine the root cause of the vulnerability, as described above in relation to FIG. 1A. For example, determine root cause instructions 172 may triage the vulnerability to determine the root cause in order to recognize the appropriate custom code for loading into the binary for addressing the root cause. For example, if the vulnerability is caused by an unbounded memcpy, then a custom code directed toward checking buffer size is loaded. If, for another example, the issue is use-after-free of the application, a reference count may be added or the reference may be removed. Once the root cause of the vulnerability is determined, appropriate custom code may be loaded to the binary to address the vulnerability.

[0032] Load custom code instructions 173 may be analogous to modify binary instructions 122 of computing device 100 and may, when executed by processor 160, load the custom code to the binary. As described previously, the custom code may be added to the end of a .text section of the binary. In some other examples, the custom code may be loaded to a new code section, as described herein in reference to add additional code section instructions 175.

[0033] Modify portable executable instructions 174 may, when executed by processor 160, modify a portable executable header of the binary with information related to the custom code. The portable executable header of the binary may be modified to facilitate replacement of a code section associated with the root cause with the custom code. For example, the portable executable may redirect the binary from the vulnerable code to the custom code at the appropriate time in order to address the vulnerability. For example, instead of mapping the binary to the vulnerable code, the portable executable may instead cause execution of the custom code to address the vulnerability.

[0034] Add additional code section instructions 175 may, when executed by processor 160, add an additional code section to the binary. In such examples, this additional code section may be used for loading the custom code.

[0035] Execute binary instructions 176 may be analogous to instructions 123 of computing device 100, and, when executed by processor 1 10, may cause computing device 150 to perform the code loaded in the binary, including the custom code. The presence of the custom code may resolve potential issues that could be caused by the vulnerability.

[0036] FIG. 2 depicts an example system 200 for loading custom code in binary. System 200 may be a computing device, a cloud server, a local area network server, a web server, a mainframe, a mobile computing device, a notebook or desktop computer, a smart TV, a wearable device, a point-of-sale device, any other suitable electronic device, or a combination of devices, such as ones connected by a cloud or internet network, that perform the functions described herein. The dotted line shows that the components of system 200 may be located together in a single device or that the components may be separate and functionally connected.

[0037] As mentioned above and described in detail below, system 200 may include a series of engines 210-230 for loading custom code in binary. Each of the engines may generally represent any combination of hardware and programming. For example, the programming for the engines may be processor executable instructions stored on a non- transitory machine-readable storage medium and the hardware for the engines may include at least one processor of the system 200 to execute those instructions. In addition or as an alternative, each engine may include one or more hardware devices including electronic circuitry for implementing the functionality described below.

[0038] Vulnerability engine 210 identify vulnerabilities in a program. In some examples, vulnerability engine 210 may determine a root cause of the vulnerability. Determining the root cause of the vulnerability may allow the recognition of an appropriate response to the vulnerability. In some examples, vulnerability engine 210 may perform functionality the same as or similar to identify vulnerability instructions 121 , when executed by processor 1 10.

[0039] Binary modification engine 220 may modify a binary being executed to perform the application by loading a custom code based on the vulnerability. For example, the custom code may be based on the root cause of the vulnerability, and the custom code may address the root cause. In some examples, binary modification engine 220 may modify a portable executable header of the binary to facilitate replacement of a code section associated with the root cause with the custom code. The custom code may be loaded to unused space of a .text code section. This is illustrated herein in reference to FIG. 2B. Alternatively, binary modification engine 220 may add an additional code section to the binary, onto which the custom code is loaded. Binary modification engine 220 may perform functionality the same as or similar to binary modification instructions 122, when executed by processor 1 10.

[0040] Execution engine 230 may execute the binary with the custom code. The presence of the custom code may resolve potential issues that could be caused by the vulnerability. Execution engine 230 may perform functionality the same or similar to execute binary instructions 123, when executed by processor 1 10.

[0041 ] System 200 may also include other components, such as a storage which may store the information and data associated with system 200. For example, the storage may store the plurality of user types, the plurality of user interfaces, and activity histories of users. Such as storage may be any physical storage device or may be, for example, cloud-hosted storage.

[0042] FIG. 2B illustrates an examples binary 250 for loading custom code. As depicted in the illustrated example, binary 250 may contain a portable executable 260 having a portable executable header that matches a virtual address 262 with a physical address 264 of the binary code. Binary 250 may contain code sections 270 that may be loaded by the portable executable header to be executed. Code sections 270 may be labeled with a physical address, shown here as "XX", "XY", and ΎΖ ^* ". In a first example, virtual address 262 labeled "001 " may be mapped to physical address 264 labeled "XX", "002" may be mapped to "XY", and "003" may be mapped to ΎΖ ^* ". If executed in order, portable executable 260 may execute code sections "XX", "XY", and "YZ ^* ".

[0043] In some examples, a code section 270 may contain a vulnerability. In the example shown, code section 270 with physical address "YZ ^* " may contain a vulnerability, as indicated by the asterisk. System 200, or computing devices 100, 150 or other embodiments, may address the vulnerability by loading a custom code into the binary 250. As illustrated, custom code section 280 may be loaded to binary 250. Furthermore, the portable executable header of portable executable 260 may be modified so that virtual address "003" may be mapped to physical address labeled "CC" for custom code section 280.

[0044] In this manner, the virtual address of portable executable 260 may remain the same while the mapped physical address of the code may be changed. Specifically, virtual address 262 labeled "001 " may be mapped to physical address 264 labeled "XX", "002" may be mapped to "XY", and "003" may be mapped to "CC". If executed in order, portable executable 260 may execute code sections "XX", "XY", and "CC". Thus, the vulnerable code ΎΖ ^* " may be circumvented. [0045] FIG. 3A depicts an example method 300 for loading custom code in binary. Although execution of method 300 is described below with reference to computing device 100 of FIG. 1A, other suitable devices for execution of this method should be apparent, including computing device 150 of FIG. 1 B and system 200 of FIG. 2. Method 300 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 120, and/or in the form of electronic circuitry.

[0046] In an operation 310, a root cause of a vulnerability in an application may be determined. For example, computing device 100 may triage the vulnerability to determine the root cause in order to recognize the appropriate custom code for loading into the binary for addressing the root cause. Once the root cause of the vulnerability is determined, appropriate custom code may be loaded to the binary to address the vulnerability. The root cause may be determined in a manner similar or the same as that described above in relation to the execution of the identify vulnerability instructions 121 , the vulnerability engine 210, or other resource of computing device 100.

[0047] In an operation 320, a binary being executed to perform the application may be modified by loading a custom code to the binary. In some examples, the custom code may be based on the root cause. For example, a custom code for addressing the root cause may be added to unused space at the end of a code section. In other examples, an additional code section may be added to the binary, and the custom code may be loaded to the additional code section. The binary may be modified in a manner similar or the same as that described above in relation to the execution of the modify binary instructions 122, the binary modification engine 220, or other resource of computing device 100.

[0048] In an operation 330, the binary with the loaded custom code may be executed in a manner similar or the same as that described above in relation to the execution of the binary execution instructions 123, the execution engine 230, or other resource of computing device 100.

[0049] FIG. 3B depicts an example method 350 for loading custom code in binary including an operation 325 for modifying an portable executable header of the binary to replace a code section with the custom code. Although execution of method 350 is described below with reference to computing device 100 of FIG. 1A, other suitable devices for execution of this method should be apparent, including computing device 150 of FIG. 1 B and system 200 of FIG. 2. Method 350 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 120, and/or in the form of electronic circuitry.

[0050] Method 350 may include operation 310 of method 300, where the root cause of the vulnerability is determined.

[0051 ] In an operation 325, a portable executable header of the binary is modified to replace a code section associated with the root cause with the custom code. For example, the portable executable may redirect the binary from the vulnerable code to the custom code at the appropriate time in order to address the vulnerability. For example, instead of mapping the binary to the vulnerable code, the portable executable header may instead cause execution of the custom code to address the vulnerability. The portable executable header may be modified in a manner similar or the same as that described above in relation to the execution of modify portable executable instructions 174, or other resource of computing device 150, computing device 100, and/or system 200.

[0052] Method 350 may also include operation 330 of method 300, where the binary with the loaded custom code may be executed.

[0053] FIG. 4 depicts an example method 400 for loading custom code in binary. Although execution of method 400 is described below with reference to computing device 150 of FIG. 1 B, other suitable devices for execution of this method should be apparent, including computing device 100 of FIG. 1A and system 200 of FIG. 2. Method 400 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 170, and/or in the form of electronic circuitry.

[0054] In an operation 410, a root cause of a vulnerability in an application may be determined. For example, computing device 150 may triage the vulnerability to determine the root cause in order to recognize the appropriate custom code for loading into the binary for addressing the root cause. Once the root cause of the vulnerability is determined, appropriate custom code may be loaded to the binary to address the vulnerability. The root cause may be determined in a manner similar or the same as that described above in relation to the execution of the identify vulnerability instructions 171 , the vulnerability engine 210, or operation 310.

[0055] In an operation 420, custom code to address the root cause of the vulnerability may be determined. Operation 420 may recognize the appropriate custom code for loading into the binary for addressing the root cause. For example, if the root cause of the vulnerability is an unbounded memcpy, then a custom code directed toward checking buffer size is loaded. If, for another example, the issue is use-after-free of the application, a reference count may be added or the reference may be removed. Once the appropriate custom code is determined, it may be loaded to the binary in order to address the vulnerability.

[0056] In an operation 430, computing device 150 checks whether a code section has adequate unused space for loading the custom code. For example, when code of the binary is mapped to memory, unused space may exist in the .text section of the memory. This unused space may be used to load the custom code. Operation 430 checks whether the unused space is adequate for the custom code.

[0057] Responsive to determining that the unused space in the code section is adequate, method 400 proceeds to an operation 440. In operation 440, the custom code may be added to the end of the code section in a manner similar or the same as that described above in relation to the execution of the load custom code instructions 173, the binary modification engine 220, or operation 320.

[0058] Responsive to determining that the unused space in the code section is not adequate, method 400 proceeds to an operation 445. In operation 445, an additional code section may be added to the binary in a manner similar or the same as that described above in relation to the execution of the add additional code instructions 175, the binary modification engine 220, or operation 320.

[0059] In an operation 450, the custom code may be loaded into the binary. Depending on whether operation 440 or operation 445 is executed, the custom code may be loaded to the end of an existing code section or it may be added to the additional code section, respectively. The binary may be modified by loading the custom code in a manner similar or the same as that described above in relation to the execution of the load custom code instructions 173, the binary modification engine 220, or operation 320.

[0060] In an operation 460, a portable executable header of the binary may be modified to facilitate replacement of a code section associated with the root cause with the custom code. For example, the portable executable may redirect the binary from the vulnerable code to the custom code at the appropriate time in order to address the vulnerability. For example, instead of mapping the binary to the vulnerable code, the portable executable header may instead cause execution of the custom code to address the vulnerability. The portable executable header may be modified in a manner similar or the same as that described above in relation to the execution of modify portable executable instructions 174, system 200, or operation 325.

[0061 ] In an operation 470, the binary with the custom code may be executed in a manner similar or the same as that described above in relation to the execution of the execute binary instructions 176, the execution engine 230, or operation 330.

[0062] The foregoing disclosure describes a number of example embodiments for loading custom code in the binary of an application. The disclosed examples may include systems, devices, computer-readable storage media, and methods for loading custom code in binary. For purposes of explanation, certain examples are described with reference to the components illustrated in FIGS. 1 -4. The functionality of the illustrated components may overlap, however, and may be present in a fewer or greater number of elements and components. All or part of the functionality of illustrated elements may co-exist or be distributed among several geographically dispersed locations. Moreover, the disclosed examples may be implemented in various environments and are not limited to the illustrated implementations.

[0063] Further, the sequence of operations described in connection with FIGS. 1 -4 are examples and are not intended to be limiting. Additional or fewer operations or combinations of operations may be used or may vary without departing from the scope of the disclosed examples. Furthermore, implementations consistent with the disclosed examples need not perform the sequence of operations in any particular order. Thus, the present disclosure merely sets forth possible examples of implementations, and many variations and modifications may be made to the described examples. All such modifications and variations are intended to be included within the scope of this disclosure and protected by the following claims..