AND METHOD

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] The current application claims priority from U.S. provisional patent application S/N US 62/695,202, filed July 9, 2018, the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

[0002] The invention relates generally to the field of security devices, and more specifically a system and method for protecting against return-oriented programming (ROP) attacks and controlling flow integrity.

BACKGROUND

[0003] ROP is a computer security exploit technique which allows an attacker to execute malicious code even in the presence of security defenses such as executable space protection and code signing. With ROP, the attacker gains control of the call stack and hijacks the program control flow. The attacker can then execute carefully chosen machine instruction sequences which are already present in the device's memory. These sequences are called 'gadgets'. Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or in a shared library code. Chained together, these gadgets allow an attacker to perform arbitrary operations even in a device employing defenses which can thwart simpler attacks.

[0004] Utilizing shadow stacks provides an effective defense against ROP attacks. Particularly, when a function is called, the new return address is pushed onto the shadow stack. When the function returns, it uses the return address stored on the shadow stack to verify the integrity of the executed return address by either checking that the return address on the main stack matches the return address on the shadow stack or by jumping to the address stored on the shadow stack. Unfortunately, using shadow stacks add a non-trivial performance overhead.

[0005] One method of protecting against stack buffer overflow is by utilizing stack canaries. Stack canaries are special values which are stored in stack frames between the return address and local variables. A contiguous stack buffer overflow would overwrite the stack canary, which is checked for intactness before the executing returns. Unfortunately, stack canaries also add a non-trivial performance overhead.

SUMMARY OF THE INVENTION

[0006] Accordingly, it is a principal object of the present invention to overcome at least some of the disadvantages of prior art ROP attack protection. This is provided in one embodiment by a method for ROP attack protection, the method comprising: replacing each of at least one predetermined operation code (opcode) in a program with a respective predetermined instruction such that the program enters a predefined protection functionality; responsive to entering the predefined protection functionality in response to the respective predetermined instruction, comparing a predetermined parameter of the respective replaced opcode to a predefined protection model; in the event that an outcome of the comparison is acceptable, executing a predetermined opcode associated with the respective replaced opcode; and in the event that an outcome of the comparison is not acceptable, not executing the predetermined opcode associated with the respective replaced opcode, or generating an alert.

[0007] In one embodiment, the replaced at least one predetermined opcode comprises: a return opcode; or a call to a predetermined type of function. In another embodiment, the replaced at least one predetermined opcode comprises all return opcodes associated with a predetermined input handler.

[0008] In one embodiment, the replaced at least one predetermined opcode comprises a return opcode, the predetermined parameter comprising: a call stack used by the respective return opcode; a return address of the respective return opcode; or identification of registers used by the respective return opcode. In another embodiment, the replaced at least one predetermined opcode comprises a call to a predetermined type of function, the predetermined parameter comprising a size of a message sent by the call. In one further embodiment, the method further comprises, responsive to an output of the comparison indicating that the size of the message exceeds a predetermined maximum size, truncating the message.

[0009] In one embodiment, the predetermined parameter comprises a current call stack flow. In another embodiment, the predetermined opcode associated with the respective replaced opcode is the same as the respective replaced opcode. [00010] In one embodiment, the method further comprises: scanning a binary image of the program to determine a call tree for a system entry point from a predetermined input handler; and identifying the at least one predetermined opcode, which is associated with the determined call tree, the replacing responsive to the identification. In one further embodiment, the method further comprises adding a predetermined portion of the program content of the protection functionality to an executable and linkable format (ELF) file, wherein the replacing is performed responsive to the adding.

[00011] In one independent embodiment, a method for ROP return-oriented programming attack protection, the method comprising: responsive to entering a predefined protection functionality from a location in a program, comparing a predetermined parameter associated with the location in the program to a predefined protection model; in the event that an outcome of the comparison is acceptable, executing a predetermined opcode associated with the location in the program; and in the event that an outcome of the comparison is not acceptable, not executing the predetermined opcode associated with the location in the program, or generating an alert.

[00012] In one embodiment, the predetermined opcode comprises: a return opcode; or a call to a predetermined type of function. In another embodiment, the predetermined opcode comprises a return opcode, the predetermined parameter comprising: a call stack used by the return opcode; a return address of the return opcode; or identification of registers used by the return opcode.

[00013] In one embodiment, the predetermined opcode comprises a call to a predetermined type of function, the predetermined parameter comprising a size of a message sent by the call. In one further embodiment, the method further comprises, responsive to an output of the comparison indicating that the size of the message exceeds a predetermined maximum size, truncating the message. In another embodiment, the predetermined parameter comprises a current call stack flow.

[00014] In another independent embodiment, a system arranged to provide protection against ROP attacks is provided, the system comprising: a server, the server comprising a processor and a communication module; and a run time unit, the run time unit comprising a processor and a communication module, wherein the communication module of the server is arranged to receive a program, wherein the processor of the server is arranged to adjust the received program so as to replace each of at least one predetermined operation code (opcode) in the received program with a respective predetermined instruction such that the program enters a predefined protection functionality, wherein the communication module of the server is further arranged to output the adjusted program and the predefined protection functionality, the communication module of the run time unit arranged to receive the adjusted program and the predefined protection functionality, wherein the processor of the run time unit is arranged to: enter the predefined protection functionality responsive to a respective one of the at least one predetermined instruction; responsive to the entering the predefined protection functionality, compare, by the protection functionality, a predetermined parameter of the respective replaced opcode to a predefined protection model; in the event that an outcome of the comparison is acceptable, execute, by the protection functionality, a predetermined opcode associated with the respective replaced opcode; and in the event that an outcome of the comparison is not acceptable, not execute the predetermined opcode associated with the respective replaced opcode, or generate, by the protection functionality, an alert.

[00015] In one embodiment, the received program is received as a binary program image, and wherein the output adjusted program and predefined protection functionality are combined in a single file. In one further embodiment, the combination into a single file is performed by the processor of the server adding a predetermined portion of the program content of the protection functionality to an executable and linkable format (ELF) file of the received program, the adjustment performed responsive to the combination.

[00016] In another embodiment, the communication module of the run time unit is in communication with an input handler, wherein the processor of the server is further arranged to: scan the received program to determine a call tree for a system entry point to the run time unit from the input handler; and identify the at least one predetermined opcode, which is associated with the determined call tree, the replacing responsive to the identification.

[00017] In one embodiment, the replaced at least one predetermined opcode comprises: a return opcode; or a call to a predetermined type of function. In another embodiment, the replaced at least one predetermined opcode comprises all return opcodes associated with a predetermined input handler. [00018] In one embodiment, the replaced at least one predetermined opcode comprises a return opcode, the predetermined parameter comprising: a call stack used by the respective return opcode; a return address of the respective return opcode; or identification of registers used by the respective return opcode. In another embodiment, the replaced at least one predetermined opcode comprises a call to a predetermined type of function, the predetermined parameter comprising a size of a message sent by the call.

[00019] In one further embodiment, the processor of the run time unit is further arranged, by the protection functionality, responsive to an output of the comparison indicating that the size of the message exceeds a predetermined maximum size, to truncate the message.

[00020] In one embodiment, the predetermined parameter comprises a current call stack flow. In another embodiment, the predetermined opcode associated with the respective replaced opcode is the same as the respective replaced opcode.

[00021] In another independent embodiment, a system arranged to provide protection against ROP attacks is provided, the system comprising: a processor; and a memory, the memory having stored thereon a protection functionality, wherein the processor is arranged to: responsive to entering the predefined protection functionality from a location in a program, compare a predetermined parameter associated with the location in the program to a predefined protection model; in the event that an outcome of the comparison is acceptable, execute a predetermined operation code (opcode) associated with the location in the program; and in the event that an outcome of the comparison is not acceptable, not execute the predetermined opcode associated with the location in the program, or generate an alert.

[00022] In one embodiment, the predetermined opcode comprises: a return opcode; or a call to a predetermined type of function. In another embodiment, the predetermined opcode comprises a return opcode, the predetermined parameter comprising: a call stack used by the return opcode; a return address of the return opcode; or identification of registers used by the return opcode.

[00023] In one embodiment, the predetermined opcode comprises a call to a predetermined type of function, the predetermined parameter comprising a size of a message sent by the call. In one further embodiment, the processor is further arranged, responsive to an output of the comparison indicating that the size of the message exceeds a predetermined maximum size, to truncate the message.

[00024] In one embodiment, the predetermined parameter comprises a current call stack flow.

[00025] Additional features and advantages of the invention will become apparent from the following drawings and description.

BRIEF DESCRIPTION OF THE DRAWINGS

[00026] For a better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings in which like numerals designate corresponding sections or elements throughout.

[00027] With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how several forms of the invention may be embodied in practice. In the accompanying drawings:

[00028] FIG. 1A illustrates a high level block diagram of a first embodiment of a system arranged to provide protection against ROP attacks;

[00029] FIG. 1B illustrates a high level flow chart of a first ROP attack protection method, in accordance with certain embodiments;

[00030] FIG. 1C illustrates a high level flow chart of a method for replacing opcodes within a program, in accordance with certain embodiments;

[00031] FIG. 2A illustrates a high level block diagram of a second embodiment of a system arranged to provide protection against ROP attacks;

[00032] FIG. 2B illustrates a high level flow chart of a second ROP attack protection method, in accordance with certain embodiments; [00033] FIG. 3 illustrates a high level flow chart of a method of adding a protection functionality to a binary program image, in accordance with certain embodiments; and

[00034] FIG. 4 illustrates a high level flow chart of a method of preparing a program against ROP attacks when the source code is unavailable, in accordance with certain embodiments.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[00021] Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The invention is applicable to other embodiments or of being practiced or carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.

[00022] FIG. 1A illustrates a high level block diagram of a system 10. System 10 comprises: a server 20; and a run time unit 30. Run time unit 30 is any system which runs using a call stack, such as, but not limited to, an electronic control unit of a vehicle. Server 20 comprises: a processor 40; a memory 50; and a communication module 60. Run time unit 30 comprises: a processor 70; a memory 80; and a communication module 90 comprising one or more entry point and input handler pairs 95. Particularly, each entry point 95 is a hardware module which can be connected to an external device, such as an Ethernet interface, a controller area network (CAN) controller/transceiver or a bluetooth device, without limitation. For each entry point 95, an input handler is provided, i.e. a software module which handles communication for the respective hardware entry point, such as a CAN driver or an Ethernet driver, without limitation.

[00023] FIG. 1B illustrates a high level flow chart of an ROP attack protection method, in accordance with certain embodiments. The ROP attack protection method is described in relation to system 10 of FIG. 1A, however this is not meant to be limiting in any way and the method can be performed by a different appropriate system, without exceeding the scope.

[00024] In stage 1000, a program is adjusted by replacing at least one predetermined opcode within the program with a respective predetermined instruction such that the program enters a predefined protection functionality. Particularly, when the adjusted program is later run, optionally in processor 70 of run time unit 30, each predetermined instruction which replaces a respective opcode causes the program to enter a protection module, as will be described below. In one embodiment, the adjustment of the program is performed in processor 40 of server 20. Additionally, in another embodiment, the protection module is generated by processor 40 of server 20. In one embodiment, the replaced at least one predetermined opcode comprises a return opcode or a call to a predetermined type of function. In one further embodiment, all the return opcodes associated with a predetermined input handler are replaced, as will be described below. One embodiment of the method of stage 1000 is detailed in a high level flow chart illustrated by FIG. 1C.

[00025] Particularly, in stage 1100 of FIG. 1C, a program is received by communication module 60 of server 20. In stage 1105, a first preparation script scans the program to determine: legitimate call stacks which are allowed to jump to each address; legitimate return addresses; and legitimate registers to be used. A protection model is thus defined which indicates legitimate values of the parameters. In one embodiment, the program is provided as a binary program image. In another embodiment, the first preparation script further searches the program to determine the allowed buffer sizes for each function call. Additionally, in one embodiment, the first preparation script searches program to determine legitimate flows for calling each function.

[00026] In one embodiment, a call tree is defined for each input handler 95 of communication module 90 of run time unit 30. As will be described below, during runtime the flow will be compared with this call tree to determine whether the flow is acceptable. In one embodiment, all of these predetermined parameters are stored in a protector library on memory 50, and the library is linked with the program source code.

[00027] In stage 1110, the input entry point/s 95 which need protection are defined. For example, an input entry point which needs protection may be an Ethernet interface. Additionally, the respective input handler 95 invocation routine is defined. In stage 1120, the program is scanned to determine entry points to the system from the different input handlers 95.

[00028] In stage 1130, at least one return opcode in the call tree branch which are associated with the defined input handler which needs protection is marked by the first preparation script. In one embodiment, all the return opcodes associated with the defined input handler which needs protection are marked.

[00029] In stage 1140, the marked return opcodes are replaced by the first preparation script with a predetermined instruction which will enter a predefined protection functionality. The predetermined instruction can be a call to the protection functionality, a branch to the protection functionality, or a jump to the protection functionality, in accordance with the relevant architecture. For example, in an ARM instruction set, opcode POP is replaced with BL xxxxx, where xxxxx is the relative offset from the current frame pointer to the address of the protection functionality. For cases where there is a complex instruction set, where the return opcodes can have different sizes, e.g. 16 or 32 bits, the return opcode is replaced with an invocation of a dedicated software interrupt which jumps to the predefined protection functionality. In one embodiment, the protection functionality comprises a single routine, however this is not meant to be limiting in any way.

[00030] Information regarding the replaced opcodes are stored in the protection functionality. Particularly, the position of the replaced opcode within the program is saved, thereby allowing the protection functionality to know which opcode to perform if the call stack is valid, as will be described below. Additionally, saving the position of the replaced opcode will allow the protection functionality to know which parameters to analyze. Furthermore, in one embodiment, the replaced opcode is copied into the protection functionality, such that once authorized by the protection functionality, the respective opcode can be executed.

[00031] In optional stage 1150, calls to potentially unsafe functions are replaced by the first preparation script with calls to predefined protection functions in the protection functionality. For example, a call to 'strcpy' is replaced with a call to 'safe_strcpy'. The protection functionality comprises one or more parameters for verifying the integrity of the call stack, as described above in relation to stage 1100. In one embodiment, for each replaced return opcode, the protection functionality comprises information regarding: legitimate call stacks allowed to jump to that address; legitimate return addresses; and legitimate registers to be used. In another embodiment, for replaced function calls, the protection functionality further comprises information regarding a legitimate buffer size. Particularly, the protection functionality determines whether the message length of the function is less than the legitimate buffer size. In the event of an attack, or other overflow error, the message will be longer.

[00032] In stage 1160, communication module 60 of server 20 outputs the adjusted program, optionally the adjusted binary program image, and the predefined protection functionality. As will be described below in relation to FIGs. 3 - 4, in one embodiment the adjusted program and protection functionality are output as a single file. The output adjusted program and predefined protection functionality are received at communication module 90 of run time unit 30 and stored on memory 50.

[00033] In stage 1010 of FIG. 1B, responsive to entering the predefined protection functionality in response to a respective predetermined instruction, a predetermined parameter of the respective replaced opcode is compared to a predefined protection model. Particularly, at runtime, when an input handler routine is executed, at the end of routine the execution context enters the protection functionality since the return opcodes were replaced, as described above. As described above in relation to stage 1150, the protection functionality comprises a plurality of parameters for verifying the integrity of the call stack. In one embodiment, it is not necessary to look at the actual replaced opcode, rather the protection functionality has stored therein information regarding the parameters which need to be analyzed for each position in the program which the protection function is entered therefrom.

[00034] The protection functionality compares one or more parameters of the return commands, or the called functions, i.e. those opcodes which were replaced in stage 1000, to the predefined protection model to determine whether the call is within the legitimate parameters and the call stack is valid. As described above, in one embodiment, the predetermined parameters comprise one or more of: a call stack used by the respective replaced return opcode; a return address of the respective replaced return opcode; identification of the registers used by the respective return opcode; the current call stack flow, i.e. the flow in the call stack at the present moment; or the size of a message sent by a call to a function.

[00035] In the event that the outcome of the comparison of stage 1010 is acceptable, for example it has been determined that the call stack is valid, in stage 1020 the protection functionality executes a predetermined opcode associated with the respective replaced opcode. Particularly, as described above, in one embodiment the replaced opcode is copied into the protection functionality. In such an embodiment, the copied opcode is executed, i.e. the return command, or the appropriate function, and the control flow continues. In another embodiment, a modified opcode is stored in the protection functionality and the modified opcode is executed.

[00036] In the event that the outcome of the comparison of stage 1010 is not acceptable, for example it has been determined that the call stack is not valid and the return command or function call is outside the legitimate protection model, in stage 1030 the protection functionality does not executed the respective opcode. Alternatively, or additionally, the protection functionality outputs an anomaly alert and/or stops the execution of the particular task. In one embodiment, in the event of a message whose length exceeds the buffer size, the message is truncated and an anomaly notification is sent.

[00037] Advantageously, only specific functions may be modified and it is not necessary to modify the entire file or to provide a shadow stack. Thus, flexible protection is provided with a smaller footprint and simple integration, since the preparation script makes only small changes to the original code. Additionally, no statistical anomaly detection is necessary.

[00038] FIG. 2A illustrates a high level block diagram of a system 200. System 200 comprises: a processor 210; and a memory 220, memory 220 having stored thereon a protection functionality arranged to be executed by processor 210. FIG. 2B illustrates a high level flow chart of a second embodiment of an ROP attack protection method. The ROP attack protection method of FIG. 2B is described in relation to system 200 of FIG. 2A, however this is not meant to be limiting in any way. Particularly, the method of FIG. 2B can be run by system 10 of FIG. 1 A described above.

[00039] In stage 1200, responsive to entering a predefined protection functionality from a location in a program, a predetermined parameter associated with the location in the program is compared to a predefined protection model, as described above in relation to stage 1010. Particularly, as described above, the predefined protection functionality has stored therein information regarding an opcode which was previously in the respective location in the program but was replaced. Thus, the predetermined parameter of such an opcode, or information stored regarding the respective location in the program, is compared to the protection model, as described above. [00040] In one embodiment, the predetermined parameter comprises one or more of: the particular call stack used by the replaced opcode; the return address of the replaced opcode; identification of registers used by the replaced opcode; current call stack flow; or size of message sent by a call to predetermined type of function.

[00041] In stage 1210, in the event that an outcome of the comparison of stage 1200 is acceptable, a predetermined opcode associated with the respective location in the program is executed, as described above in relation to stage 1020. In one embodiment, the predetermined opcode is a return opcode or a call to a predetermined type of function, as described above. In stage 1220, in the event that an outcome of the comparison of stage 1200 is not acceptable, the predetermined opcode associated with the location in the program is not executed, as described above in relation to stage 1030. Alternatively, or additionally, an alert is generated. In one embodiment, in the event the an output of the comparison indicates that the size of the message of a function call exceeds a predetermined maximum sized the message is truncated to the maximum size, as described above.

[00042] FIG. 3 illustrates a high level flow chart of a method of adding a protection functionality to a binary program image, in accordance with certain embodiments. The below is described in relation to an executable and linkable format (ELF) file. In stage 2000, the file is analyzed by a second preparation script to find available space which the protection functionality can fit into. In stage 2010, in the event that there is sufficient space within the existing segments, a portion of the PROGBITS, i.e. a portion of the program content, of the protection functionality are copied into the binary program image within the space of stage 2000 by the second preparation script. In one embodiment, only the PROGBITS sections necessary to run the protection functionality are copied in order to save space. While copying the PROGBITS of the protection functionality into the binary program image, preferably the relative distance between different sections within the protection functionality is maintained. Particularly, sections of the ELF file which contain various types of data and are loaded on runtime need to be mapped to addresses in the CPU memory. The mapping is performed by segments, as known to those skilled in the art at the time of the invention. Each segment contains a sequence of consecutive PROGBITS sections which are loaded together to the address specified by the segment. Thus, the added segments for the protection functionality will load the added PROGBITS sections to the process address space on runtime.

[00043] In stage 2020, in the event that there isn’t sufficient space within the existing segments, two new segments are added to the ELF file by the second preparation script. The first segment is for read-only executable text and the second segment is for read- write access. Sections of the protection functionality are then added to the added segments. Specifically, the read-write access PROGBITS sections comprise data and the global offset table (GOT).

[00044] All of the segments of the ELF file are listed in a program header table. After adding the two new segments of stage 2020, the program header table no longer fits in its original offset. Therefore, in stage 2030, the program header table is moved by the second preparation script to the end of the ELF file. In stage 2040, a third segment is added to the program header table by the second preparation script, the third segment arranged to load the program header table from its new location to the process address space on runtime to allow the process to be loaded and executed. Code is position independent, therefore relocation within the address space does not require any modifications as long as the relative distance between different sections is maintained. However, sometimes there are global offsets in the code. These offsets are stored in the GOT and in stage 2050 are modified by the second preparation script to reflect the relocation of the addresses.

[00045] FIG. 4 illustrates a high level flow chart of a method of preparing a program against ROP attacks when the source code is not available, in accordance with certain embodiments. In stage 3000, the second preparation script, described above in relation to stages 2000 - 2050 is performed on the ELF file of the program and the protection functionality, thereby linking them together to a single ELF file. In stage 3010, the first preparation script, described above in relation to stages 1100 - 1150, is performed on the new ELF file of stage 3000. The ROP protection is thus provided during run time, as described above. Advantageously, the above described method provides ROP protection event when the source code is unavailable.

[00046] It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination. In particular, the invention has been described with an identification of each powered device by a class, however this is not meant to be limiting in any way. In an alternative embodiment, all powered device are treated equally, and thus the identification of class with its associated power requirements is not required.

[00047] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as are commonly understood by one of ordinary skill in the art to which this invention belongs. Although methods similar or equivalent to those described herein can be used in the practice or testing of the present invention, suitable methods are described herein.

[00048] All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety. In case of conflict, the patent specification, including definitions, will prevail. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.

[00049] It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather the scope of the present invention is defined by the appended claims and includes both combinations and subcombinations of the various features described hereinabove as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description.