Patent Description:
The invention relates generally to the field of control flow integrity security devices, and more specifically to a control flow integrity system and method for control flow integrity in one or more processes.

In computing, a linker or link editor is a computer utility program that takes one or more object files generated by a compiler or an assembler and combines them into a single executable file, library file, or another 'object' file. Common linking methods are static and dynamic linking. Static linking is the result of the linker copying all library routines used in the program into the executable file. This may require more disk space and memory than dynamic linking, but is more portable, since it does not require the presence of the library on the system where it runs.

Many operating system environments allow dynamic linking, thereby deferring the resolution of some undefined symbols until a program is run. This means that the executable code still contains undefined symbols, plus a list of objects or libraries that will provide definitions for these undefined symbols. Loading the program will load these objects/libraries as well, and perform a final linking. Executable Linkable Format (ELF) files are files which consist of a symbol look-up and relocatable table, i.e. it can be loaded at any memory address by the kernel and automatically all symbols used are adjusted to the offset from that memory address where it was loaded into. One of the ways to protect an ELF file from runtime vulnerability exploitation, is to add a control-flow integrity (CFI) check. CFI is a general term for computer security techniques which prevent a wide variety of malware attacks from redirecting the flow of execution of a program. There are different methods to add CFI checks to a binary file.

For a statically linked executable file, all the code is added to the executable file before execution. Therefore, in this case the CFI is added to the executable file. The final linking is done before running the ELF file, therefore the CFI can be added to the ELF file before run time. For a dynamically linked executable file, the final linking happens on runtime by the loader. Therefore, the CFI check can be added after the shared object is added to the process's memory.

In the automotive market there is a demand to add CFI checks to electrical control units (ECUs), domain controller units (DCUs) and other end points, such as telematics control units (TCUs). There are <NUM> main unique area for CFI in the automotive market:.

Most CFI solutions that exist in the market today are designed to protect industrial/organization computers, internet of things (IOT) devices, etc. Therefore, they don't meet the zero false positive standard.

In addition, it is common to find in the market CFI solutions that are based on cryptography, writing cookies / magic values, etc. These methods are not performed in real time. Additionally, in methods based on writing a cookie to the memory, the memory of this cookie must be writable, thereby allowing an attacker to write to this area and manipulate the cookie.

In a paper by Niu et al. , titled "Modular Control-Flow Integrity", a Modular Control-Flow Integrity (MCFI) technique is introduced that supports separate compilation. MCFI allows modules to be independently instrumented and linked statically or dynamically. The combined module enforces a CFG that is a combination of the individual modules' CFGs.

In a paper by Davi et al. , titled " MoCFI: A Framework to Mitigate Control-Flow Attacks on Smartphones", a Mobile CFI framework is provided, that provides a general countermeasure against control-flow attacks on smartphone platforms by enforcing CFI.

<CIT>, titled " Method and apparatus for ensuring control flow integrity", a control flow enforcement solution for ensuring that a program or portion thereof behaves as expected during execution upon a processor. A reference control flow is pre-determined for the program using, for example, a control flow graph (CFG). The CFG is then analysed to provide a set of rules which describe how the program should behave under normal execution. As the program executes it is monitored and the rules are evaluated to enable detection of any unexpected control flow.

<CIT>, titled " Software security via control flow integrity checking", provides various technologies related to control flow integrity checking. During static analysis, a canonical control flow graph can be built. Execution of a program can be interrupted at runtime, and the call stack can be observed to verify control flow integrity of the program using the canonical control flow graph. Attacks using stack tampering can be avoided, regardless of how the stack tampering is achieved. Non-invasive techniques can be used, making the technologies applicable in situations where source code is not available. Real-time operating system protection can be supported.

Accordingly, it is a principal object of the present invention to overcome at least some of the disadvantages of prior art CFI methods and arrangements. This is provided in one embodiment by a CFI system comprising: at least one protection module, each of the at least one protection module comprising a respective allowable flow model associated with at least one of a plurality of portions of a process; and at least one process protection manager, a respective one of the at least one process protection manager arranged, responsive to a control flow instruction in one of the plurality of portions of the process, to: compare one or more parameters of the control flow instruction to the allowable flow model of the associated protection module; and responsive to an outcome of the comparison indicating that the compared one or more parameters does not meet a respective parameter of the respective allowable flow model, generate a predetermined signal, wherein each of the at least one protection module is implemented as a shared object, wherein each of the at least one process protection manager is implemented as a shared object, and wherein the at least one protection module and the process protection manager are loaded into the process.

In one embodiment, the parameter comparison and signal generation of the respective process protection manager is responsive to a control flow instruction associated with the respective protection module. In one further embodiment, the control flow instruction associated with the respective protection module comprises a predetermined branch instruction to the process protection manager. In another further embodiment, the parameter comparison and signal generation of the at least one process protection manager is further responsive to information sent to the respective process protection manager responsive to the control flow instruction associated with the respective protection module.

In one embodiment, a control flow instruction in a first of the plurality of portions of the process comprises a branch or call to an address associated with a second of the plurality of portions of the process, the comparison being with the allowable flow model of the protection module associated with the second portion of the process. In another embodiment, the at least one protection module comprises a plurality of protection modules, wherein, responsive to the associated flow model not containing the respective parameter, the respective process protection manager is further arranged to: compare one or more parameters of the control flow instruction to an allowable flow model of another of the plurality of protection modules; and responsive to an outcome of the comparison indicating that the compared one or more parameters does not meet a respective parameter of the respective allowable flow model, generate a predetermined signal.

In one embodiment, each of the plurality portions of the process is associated with a respective one of a plurality of files, wherein responsive to a first of the plurality of files exhibiting a predetermined indication, the respective process protection manager loads the respective protection model shared object associated with the first file, and wherein responsive to a second of the plurality of files not exhibiting the predetermined indication, the respective process protection manager does not load the respective protection model shared object associated with the second file. In another embodiment, the at least one process protection manager comprises a plurality of process protection managers, each exhibiting a respective predetermined rule, the comparison responsive to the respective predetermined rule of the respective process protection manager, and wherein the respective one of the plurality of process protection managers is selected responsive to a predetermined feature of the process.

In one embodiment, the at least one process protection manager comprises a plurality of process protection managers, wherein the generated signal of a first of the plurality of process protection managers is arranged to prevent the operation of the respective control flow instruction and the generated signal of a second of the plurality of process protection managers is not arranged to prevent the operation of the respective control flow instruction, and wherein the respective one of the plurality of process protection managers is selected responsive to a predetermined feature of the process. In another embodiment, a first of the plurality of portions of the process is associated with an executable file and a second of the plurality of portions of the process is associated with a shared object file.

In one embodiment, the respective process protection manager is loaded into a plurality of processes. In another embodiment, each of the at least protection module exhibits an indication of which of the parameters are used in the respective comparison.

In one independent embodiment, a control flow integrity system comprising a processor and a memory, the processor arranged, responsive to instructions stored in the memory, to load into a process: at least one protection module; and a process protection manager, wherein the loaded process protection manager is arranged to: compare one or more parameters of the control flow instruction to the allowable flow model of the associated protection module; and responsive to an outcome of the comparison indicating that the compared one or more parameters does not meet a respective parameter of the respective allowable flow model, generate a predetermined signal, wherein each of the at least one protection module is implemented as a shared object, and wherein each of the at least one process protection manager is implemented as a shared object.

In one embodiment, the parameter comparison and signal generation of the loaded process protection manager is responsive to a control flow instruction associated with the respective protection module. In one further embodiment, the control flow instruction associated with the respective protection module comprises a predetermined branch instruction to the process protection manager. In another further embodiment, the parameter comparison and signal generation of the loaded process protection manager is further responsive to information sent to the loaded process protection manager responsive to the control flow instruction associated with the respective protection module.

In one embodiment, a control flow instruction in a first of the plurality of portions of the process comprises a branch or call to an address associated with a second of the plurality of portions of the process, the comparison being with the allowable flow model of the protection module associated with the second portion of the process. In another embodiment, the at least one protection module comprises a plurality of protection modules, wherein, responsive to the associated flow model not containing the respective parameter, the process protection manager is further arranged to: compare one or more parameters of the control flow instruction to an allowable flow model of another of the plurality of protection modules; and responsive to an outcome of the comparison indicating that the compared one or more parameters does not meet a respective parameter of the respective allowable flow model, generate a predetermined signal.

In one embodiment, each of the plurality portions of the process is associated with a respective one of a plurality of files, wherein responsive to a first of the plurality of files exhibiting a predetermined indication, the process protection manager loads the respective protection model shared object associated with the first file, and wherein responsive to a second of the plurality of files not exhibiting the predetermined indication, the process protection manager does not load the respective protection model shared object associated with the second file. In another embodiment, the process protection manager is one of a plurality of process protection managers, each exhibiting a respective predetermined rule, the comparison responsive to the respective predetermined rule of the respective process protection manager, and wherein the respective one of the plurality of process protection managers is selected responsive to a predetermined feature of the process.

In one embodiment, the process protection manager is one of a plurality of process protection managers, wherein the generated signal of a first of the plurality of process protection managers is arranged to prevent the operation of the respective control flow instruction and the generated signal of a second of the plurality of process protection managers is not arranged to prevent the operation of the respective control flow instruction, and wherein the respective one of the plurality of process protection managers is selected responsive to a predetermined feature of the process. In another embodiment, a first of the plurality of portions of the process is associated with an executable file and a second of the plurality of portions of the process is associated with a shared object file.

In one embodiment, the process protection manager is loaded into a plurality of processes. In another embodiment, each of the at least protection module exhibits an indication of which of the parameters are used in the respective comparison.

In another independent embodiment, a control flow integrity method is provided, the method comprising: loading at least one protection module into a process; and loading a process protection manager into the process, wherein the loaded process protection manager is arranged to: compare one or more parameters of the control flow instruction to the allowable flow model of the associated protection module; and responsive to an outcome of the comparison indicating that the compared one or more parameters does not meet a respective parameter of the respective allowable flow model, generate a predetermined signal, wherein each of the at least one protection module is implemented as a shared object, and wherein each of the at least one process protection manager is implemented as a shared object.

In one embodiment, a control flow instruction in a first of the plurality of portions of the process comprises a branch or call to an address associated with a second of the plurality of portions of the process, the comparison being with the allowable flow model of the protection module associated with the second portion of the process. In another embodiment, the at least one protection module comprises a plurality of protection modules, and wherein, responsive to the associated flow model not containing the respective parameter, the process protection manager is further arranged to: compare one or more parameters of the control flow instruction to an allowable flow model of another of the plurality of protection modules; and responsive to an outcome of the comparison indicating that the compared one or more parameters does not meet a respective parameter of the respective allowable flow model, generate a predetermined signal.

In one embodiment, each of the plurality portions of the process is associated with a respective one of a plurality of files, wherein responsive to a first of the plurality of files exhibiting a predetermined indication, the process protection manager loads the respective protection model shared object associated with the first file, and wherein responsive to a second of the plurality of files not exhibiting the predetermined indication, the process protection manager does not load the respective protection model shared object associated with the second file. In another embodiment, wherein the process protection manager is one of a plurality of process protection managers, each exhibiting a respective predetermined rule, the comparison responsive to the respective predetermined rule of the respective process protection manager, and wherein the respective one of the plurality of process protection managers is selected responsive to a predetermined feature of the process.

In one embodiment, the method further comprises loading the process protection manager into a plurality of processes. In another embodiment, each of the at least protection module exhibits an indication of which of the parameters are used in the respective comparison.

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

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.

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:.

<FIG> illustrates a high level block diagram of a CFI protection shared object generation system <NUM>. CFI protection shared object generation system <NUM> comprises: a server <NUM>; and a run time unit <NUM>. Run time unit <NUM> is any system which runs using a call stack, such as, but not limited to, an electronic control unit of a vehicle. Server <NUM> comprises: a processor <NUM>; a memory <NUM>; and a communication node <NUM>. In one embodiment, communication node <NUM> comprises an internet input/output port, as known to those skilled in the art. Run time unit <NUM> comprises: a processor <NUM>; a memory <NUM>; and a communication node <NUM> comprising one or more entry point and input handler pairs <NUM>. Each entry point <NUM> 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 <NUM>, 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.

<FIG> illustrates a high level flow chart of a CFI protection shared object generation method, in accordance with certain embodiments. The CFI protection shared object generation method is described in relation to CFI protection shared object generation system <NUM> of <FIG>, 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.

In stage <NUM>, as illustrated in <FIG>, one or more files are transmitted to server <NUM> from a user terminal <NUM>. In one embodiment, user terminal <NUM> comprises run time unit <NUM>. In another embodiment, user terminal <NUM> is in communication with run time unit <NUM>. In another embodiment, user terminal <NUM> is in communication with a separate server (not shown) that is in communication with a plurality of run time units <NUM>, the communication with the plurality of run time units <NUM> optionally being temporary connections for purposes of updating software. In one embodiment, as illustrated in <FIG>, an ELF file is transmitted to server <NUM>. In another embodiment, as illustrated in <FIG>, a shared object file is transmitted to server <NUM>. In another embodiment, both an ELF file and a shared object file are transmitted to server <NUM>. Although <FIG> are illustrated responsive to embodiments incorporating a single ELF and/or shared object file, this is not meant to be limiting in any way. In another embodiment, a plurality of ELF files and/or a plurality of shared object files are transmitted to server <NUM>. In one embodiment, each of the received ELF files is a binary program image.

In stage <NUM>, processor <NUM> of server <NUM> generates, responsive to instructions stored on memory <NUM>, a protection module for each of the received files. Each protection module is implemented as a shared object, i.e. a library that is compiled such that it can be shared by a plurality of applications, as known to those skilled in the art. In one exemplary embodiment, the source code of each protection module is compiled using a GNU Compiler Collection (GCC) compiler with the -share flag. As will be described below, each protection module is loaded into a process in run time. In one embodiment, a respective protection module is generated for each received ELF file. In another embodiment, a respective protection module is generated for a plurality of received ELF files. In one embodiment, a respective protection module is generated for each received shared object file. In another embodiment, a respective protection module is generated for a plurality of received shared object files. Each generated protection module comprises an allowable flow model for the respective associated ELF or shared object file. In one embodiment, the allowable flow model is a model of deterministic allowed flows. The term "deterministic allowed flow" is meant as a flow with <NUM>% certainty of allowed parameters in the flow. For example, if there isn't <NUM>% certainty of an allowed return address from a particular function, the function is marked as non-deterministic.

In one embodiment, the allowable flow models are generated as described in <CIT>, the entire contents of which are incorporated herein by reference. Particularly, the respective allowable flow model comprises one or more parameters for verifying the flow of the process. For example, the flow of a process can be jumping to a procedure and returning from a procedure. Thus, the flow will be verified when jumping to the procedure and when returning from the procedure. In one embodiment, the respective allowable flow model comprises information regarding: legitimate call stacks allowed to jump to each of a plurality of addresses; legitimate return addresses; and legitimate registers to be used in association with respective opcodes in the associated received file. In one further embodiment, the respective allowable flow model further comprises information regarding legitimate buffer sizes for respective calls in the associated received file. In another further embodiment, the respective allowable flow model further comprises legitimate flows for calling each of a plurality of functions. Specifically, a legitimate flow for calling a function is an allowable sequential chain of functions, where each function is allowed to call the next function in the chain.

In stage <NUM>, in one embodiment each allowable flow model is generated by a first preparation script that scans the code of the respective file to determine: legitimate call stacks which are allowed to jump to each address; legitimate return addresses; and legitimate registers to be used. As described above, in one embodiment the first preparation script further scans the code of the respective file to determine the allowed buffer sizes for each function call. In another embodiment, the first preparation script further scans the code of the respective file to determine legitimate flows for calling each of a plurality of functions. The respective allowable flow protection model thus indicates legitimate values of the respective parameters. In one embodiment, the scanned code used for generating the allowable flow model is only code that is associated with system entry points of one or more input handlers <NUM> of communication module <NUM> of run time unit <NUM>.

In stage <NUM>, processor <NUM> replaces at least one opcode of the respective received file with a predetermined instruction which will enter the respective generated protection module. In one embodiment, the first preparation script described above determines a call tree for the one or more input handlers <NUM> and each opcode within the respective determined call tree is replaced with a respective predetermined instruction. 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. <NUM> or <NUM> bits, the return opcode is replaced with an invocation of a dedicated software interrupt which jumps to the predefined protection functionality. In one embodiment, each respective predetermined instruction comprises a respective trampoline to the associated protection module.

Information regarding the replaced opcodes is stored in the associated protection module. Particularly, the position of the replaced opcode within the code is saved, thereby allowing the protection module 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 module to know which parameters should be analyzed. Furthermore, in one embodiment, the replaced opcode is copied into the protection module, such that once authorized, the respective opcode can be executed, as will be described below.

In optional stage <NUM>, processor <NUM> further inserts an indication within the header of the adjusted file indicating that the file was adjusted. In stage <NUM>, processor <NUM> of server <NUM> further generates at least one process protection manager, each generated process protection manager associated with a respective one of the received files of stage <NUM>. Each generated process protection manager is implemented as a shared object, as described above in relation to the generated protection modules of stage <NUM>. In one embodiment, as illustrated in <FIG>, a respective process protection manager is generated for a set of received files that are to be loaded into the same process. In another embodiment, a plurality of process protection managers are generated, each associated with a respective set of files that are to be loaded into a respective process. In another embodiment, a generated process protection manager is associated with files that are to be loaded into a plurality of processes, as will be described below. In one embodiment, each generated protection module of stage <NUM> comprises one or more instructions to branch to a process protection manager within the respective process, as will be described below. As will further be described below, each generated process protection manager is arranged to compare flows originating from associated ELF files and shared objects to the allowable flow models in the respective protection modules.

In optional stage <NUM>, processor <NUM> adds to each adjusted ELF file a dependency for the respective process protection manager. In stage <NUM>, communication module <NUM> of server <NUM> outputs to user terminal <NUM>: the adjusted file, or files; and the generated one or more protection modules and process protection managers. In one example, illustrated in <FIG>, a single ELF file, denoted TEST. ELF, is received by server <NUM>. Server <NUM> replaces certain opcodes within TEST. ELF, as described above, the adjusted file denoted TEST_PATCHED. As further described above, server <NUM> generates a respective protection module associated with TEST_PATCHED. ELF, implemented as a shared object, the generated protection module denoted TEST_PROTECTOR. Additionally, as further described above, server <NUM> generates a respective process protection manager, implemented as a shared object, the generated process protection manager denoted PROTECTOR_PW. Server <NUM> transmits TEST_PATCHED. ELF, TEST_PROTECTOR. SO and PROTECTOR_PW. SO to user terminal <NUM>.

In another example, illustrated in <FIG>, a single shared object file, denoted HELPER. SO, is received by server <NUM>. Server <NUM> replaces certain opcodes within HELPER. SO, as described above, the adjusted file denoted HELPER_PATCHED. As further described above, server <NUM> generates a respective protection module associated with HELPER_PATCHED. ELF, implemented as a shared object, the generated protection module denoted HELPER_PROTECTOR. Additionally, as further described above, server <NUM> generates a respective process protection manager, implemented as a shared object, the generated process protection manager denoted PROTECTOR_PW. Server <NUM> transmits HELPER_PATCHED. ELF, HELPER_PROTECTOR. SO and PROTECTOR_PW. SO to user terminal <NUM>.

In another example, illustrated in <FIG>, server <NUM> receives both TEST. ELF and HELPER. Server <NUM> then generates and outputs: TEST_PATCHED. ELF; TEST_PROTECTOR. SO; HELPER_PATCHED. ELF; HELPER_PROTECTOR. SO; and PROTECTOR_PW. As illustrated, a single process protection manager is generated for use in a respective process where TEST_PATCHED. ELF, HELPER_PATCHED. ELF, TEST_PROTECTOR. SO and HELPER_PROTECTOR. SO are loaded therein. Thus, the user can decide which files are to be protected and it is not necessary to generate a process protection manager which protects all the files in a process.

<FIG> illustrates a high level block diagram of a CFI system <NUM>, in accordance with certain embodiments. CFI system <NUM> comprises: a plurality of protection modules <NUM>; and a process protection manager <NUM>. Each of the plurality of protection modules <NUM> and process protection manager <NUM> is implemented as a shared object, as described above. Additionally, each of the plurality of protection modules <NUM> and process protection manager <NUM> is loaded into a process. Each protection module <NUM> comprises a respective allowable flow model associated with at least one of a plurality of portions of the process. In one embodiment, the allowable flow model of each protection module <NUM> is stored as read only data, and can therefore not be modified by an attacker. In one further embodiment, the entirety of the code of each protection module <NUM> is stored as read only data.

<FIG> illustrates a high level block diagram of the originating files for the code of the process, including: a dynamically linked ELF file <NUM>; a plurality of shared objects <NUM>; protection modules <NUM> and process protection manager <NUM>. <FIG> are described together. ELF file <NUM> is executed and shared objects <NUM>, protection modules <NUM> and process protection manager <NUM> are loaded into the process. Thus, each protection module <NUM> is associated with a respective portion of the process which originated from ELF file <NUM> or a shared object <NUM>, as described above. ELF file <NUM>, shared objects <NUM>, protection modules <NUM> and process protection manager <NUM> are each stored in a respective area of a memory <NUM>. Additionally, the process is run by a processor <NUM>, processor <NUM> associated with memory <NUM>, i.e. CFI system <NUM> is run by processor <NUM>.

<FIG> illustrates a high level flow chart of a method of operation of CFI system <NUM>, in accordance with certain embodiments. In stage <NUM>, during execution of ELF file <NUM>, process protection manager <NUM> is loaded into the process. In one preferred embodiment, process protection manager <NUM> is loaded into the process before any other shared objects, such as protection modules <NUM>. In an embodiment where ELF file <NUM> contains a dependency for process protection manager <NUM>, process protection manager <NUM> is loaded automatically. In an embodiment where ELF file <NUM> does not contain a dependency for process protection manager <NUM>, process protection manager <NUM> will not be loaded automatically. In one embodiment, the LD_PRELOAD command is set with the path of process protection manager <NUM> as part of a dynamic-link library (DLL) injection.

In one embodiment, a plurality of process protection managers <NUM> are provided, each process protection manager <NUM> exhibiting a respective predetermined comparison rule. Particularly, as will be described below, process protection manager <NUM> compares respective parameters of certain control flow instructions with respective allowable flow models. In one embodiment, the comparison is performed in accordance with the respective predetermined comparison rule. For example, each predetermined comparison rule can in one embodiment indicate the level of determinism of the comparison. Particularly, in one embodiment, certain allowable flow models are not <NUM>% deterministic, and there may be cases where parameters of the control flow instruction does not meet the respective parameters of the allowable flow model, however it is not necessarily an anomaly, because the allowable flow model is true for most cases, but not all. Additionally, certain allowable flow models are <NUM>% deterministic and any control flow instruction that does not meet the respective parameters of the allowable flow model is considered an anomaly. Furthermore, there is in one embodiment a plurality of types of allowable flow models, each with a different level of determinism. The predetermined comparison rule of the respective process protection manager <NUM> is indicative of what level of determinism is used for the current process, i.e. which allowable flow models are used.

In one embodiment, the respective process protection manager <NUM> is loaded responsive to a predetermined feature of the process. In one further embodiment, the predetermined feature of the process is the criticality of the process. For example, for a critical process, such as a braking system in an automobile, the process protection manager <NUM> loaded is one that exhibits a predetermined comparison rule that utilizes only <NUM>% deterministic allowable flow models, because false positive anomaly detection is not acceptable in such a critical process. For a less critical process, the process protection manager <NUM> loaded is one that exhibits a predetermined comparison rule that utilizes less than <NUM>% deterministic allowable flow models, thereby allowing false positives but reducing the number of false negatives.

In one example, ISO <NUM>, "Road vehicles - Functional safety", is an international standard for functional safety of electrical and/or electronic systems in production automobiles defined by the International Organization for Standardization (ISO) in <NUM>. According to this standard there are different safety levels:.

Thus, as described above, for different safety levels, different process protection managers <NUM> are used.

In one embodiment, a plurality of process protection managers <NUM> are provided, each process protection manager <NUM> generating a different predetermined signal. Particularly, as will be described below, responsive to the detection of an anomaly, i.e. when the respective parameters of a control flow instruction does not meet the respective parameters of the associated allowable flow model, the respective process protection manager <NUM> loaded into the process generates a predetermined signal. As will be further described below, in one embodiment the generated predetermined signal comprises an anomaly notification. In another embodiment, the generated predetermined signal comprises, alternatively or additionally, an indication whether the respective control flow instruction can be performed. In one further embodiment, as described above, the respective process protection manager <NUM> is loaded responsive to a predetermined feature of the process, optionally the criticality of the process. For example, for a critical process, the process protection manager <NUM> loaded is one that the generated signal does not exhibit an indication whether the control flow instruction can be performed. Since it is a critical process, anomaly reports are generated, but not acted upon by CFI system <NUM>, so as not to inadvertently cause a failure in the critical process. For a less critical process, the process protection manager <NUM> loaded is one that the generated signal does exhibit and indication whether the control flow instruction can be performed.

In stage <NUM>, protection modules <NUM> are loaded into the process. In one embodiment, process protection manager <NUM> determines which protection modules <NUM> need to be loaded into the process. Particularly, as described above, each protection module <NUM> is a shared object. Therefore, it isn't necessary to provide each file with a unique protection module <NUM>, and a single protection module <NUM> can be associated with a plurality of ELF files <NUM> or shared object files <NUM>. Protection module <NUM> analyzes the executed ELF file <NUM> and shared object files <NUM> that are loaded into the process to identify whether the respective file exhibits a predetermined indication. As described above, in one embodiment, any file which is patched, i.e. where opcodes are replaced, exhibits an indication of such in the header of the respective file. For each file that exhibits a respective predetermined indication, process protection manager <NUM> loads the respective protection module <NUM> associated with the respective file. In one embodiment, the respective protection modules <NUM> are loaded using the DLOPEN command. For each file that doesn't exhibit a respective predetermined indication, process protection manager <NUM> does not load the respective protection module <NUM> associated with the respective file.

In stage <NUM>, responsive to a control flow instruction in one of the plurality of portions of the process, process protection manager <NUM> compares one or more parameters of the control flow instruction to the allowable flow model of the respective protection module <NUM> associated with the respective portion of the process. As described above, certain opcodes in each of ELF file <NUM> and shared objects <NUM> were replaced with predetermined instructions which enter the respective protection module <NUM>, thus in one embodiment the control flow instruction is an instruction that enters the respective protection module <NUM>, as described above. As further described above, in one further embodiment, the respective protection module <NUM> contains an instruction to enter process protection manager <NUM>. Thus, a section of code which was replaced above in stage <NUM> goes to process protection manager <NUM>, via the associated protection module <NUM>. In other words, the comparison is performed responsive to a respective control flow instruction in each of the process portion and the respective protection module <NUM>. In one further embodiment, the respective protection module <NUM> sends predetermined information to process protection manager <NUM>. In one embodiment, the predetermined information comprises a pointer that points to the memory location comprising the respective allowable flow model. In another embodiment, the predetermined information comprises the respective parameters of the allowable flow model for the comparison. In one embodiment, as described above, the one or more parameters comprises: a call stack being used; a return address; a register being used; a buffer size; and/or a function flow.

In one embodiment, the respective protection module <NUM> exhibits a predetermined indication of which parameters process protection manager <NUM> is to analyze. In one further embodiment, the respective protection module <NUM> communicates the predetermined indication to process protection manager <NUM>. In another further embodiment, process protection manager <NUM> identifies the predetermined indication within the respective protection module <NUM>. For example, if for a particular shared object file <NUM> it is preferred to speed up the CFI analysis, the respective protection module <NUM> exhibits an indication of a reduced number of parameters to be analyzed, in comparison with other protection modules <NUM>. Thus, the control flow in different shared object files <NUM>, and/or ELF file <NUM>, can be protected by different degrees, depending on the preferred level of security and the amount of time that can be spent on providing that level of security, while using a single process protection manager.

In optional stage <NUM>, in the event that a control flow instruction in a first of the plurality of portions of the process comprises a branch or call to an address associated with a second of the plurality of portions of the process, process protection manager <NUM> compares the respective parameters of the control flow instruction to the respective parameters of the allowable flow model associated with the second portion of the process. For example, if ELF file <NUM> comprises an instruction that branches to a function of a respective shared object file <NUM>, process protection manager <NUM> compares the respective parameters of the branch instruction to the respective parameter of the allowable flow model of the respective protection module <NUM> associated with the respective shared object file <NUM>, as described above.

As further described above, in one embodiment process protection manager <NUM> is accessed via the respective protection module <NUM>. Thus, in the event that the control flow instruction originating from a first file is a branch or a call to code originating from a second file, the allowable flow model being used is not in the protection module <NUM> that connects the control flow instruction to process protection manager <NUM>. As a result, process protection manager <NUM> won't know where to find the appropriate allowable flow model. Therefore, in one embodiment, in the event that process protection manager <NUM> does not find in the allowable flow model of the protection module <NUM> that branched thereto the respective parameters associated with the respective control flow instruction originating from the first file, process protection manager <NUM> searches the other protection modules <NUM> that are loaded into the process to find the appropriate allowable flow model.

Advantageously, in the case of a pointer to a function, the pointer can be verified with expected values from other shared objects. For example, in an ARM based system, where there is an instruction for "jump from register", and in the flow there is blx r3 in ELF file <NUM>, process protection manager <NUM> checks if the pointer points to a known function not only in ELF file <NUM> but also in all protected shared objects <NUM>.

In stage <NUM>, responsive to an outcome of the comparison of stage <NUM> indicating that the compared one or more parameters does not meet a respective parameter of the respective allowable flow model, process protection manager <NUM> generates a predetermined signal. The term "does not meet a respective parameter" is meant herein that the respective parameter of the control flow instruction is not one of the allowed options in the allowable flow model. In one embodiment, the predetermined signal is a report indicative of the instruction that doesn't meet the allowable flow model. In another embodiment, the predetermined signal prevents the operation of the respective flow instruction in the respective portion of the process. In one further embodiment, process protection manager <NUM> further terminates the process. Preferably, a watchdog process will then restart the terminated process, as known to those skilled in the art. In one embodiment, in the event that the comparison is indicative that the compared one or more parameters meet the respective parameter of the respective allowable flow model, the operation is performed by process protection manager <NUM>. In another embodiment, in the event that the comparison is indicative that the compared one or more parameters meet the respective parameter of the respective allowable flow model, the operation is performed by the respective protection module <NUM>, after receiving approval from process protection manager <NUM>. In one embodiment, as described above, the type of generated predetermined signal is dependent on a predetermined feature of the process.

Advantageously, as described above, protection modules <NUM> are shared objects, therefore they can be used by a plurality of shared object files. As a result, in a case where a shared object is used by more than one executable, only a single protection module <NUM> is necessary to protect the shared object. In contrast, if each executable needed to contain information regarding an allowable flow model of the shared object, this allowable flow model, and any other information and functions stored in protection module <NUM>, will be duplicated for each executable, thus consuming more disk space.

Additionally, as described above, different process protection managers <NUM> can be selected in accordance with the type of process. Furthermore, since the protection modules <NUM> and process protection managers <NUM> are shared objects, they can be updated without having to update the entire executable. This is very advantageous in the automotive industry where performing updates is very complex.

Further advantageously, by performing a comparison with an allowable flow model that is stored as read only data, an attacker cannot modify the model to overcome the protection. This is in contrast with prior art solutions using magic cookies, stack canaries, shadow stacks, etc., which can be modified.

<FIG> illustrates an example of the use of CFI system <NUM>. Particularly, <FIG> illustrates a memory <NUM> and <FIG> illustrates a processor <NUM> associated with memory <NUM>. Memory <NUM> comprises: a first ELF file <NUM>; a patched version <NUM> of ELF file <NUM>, as described above; a protection module 210A associated with patched ELF file <NUM>; a second ELF file <NUM>; a patched version <NUM> of ELF file <NUM>, as described above; a protection module 210B associated with patched ELF file <NUM>; a shared object file <NUM>; a patched version <NUM> of shared object file <NUM>, as described above; a protection module 210C associated with patched shared object file <NUM>; a first process protection manager 220A; a second process protection manager 220B; and a third process protection manager 220C.

Processor <NUM>, illustrated in <FIG>, runs <NUM> different processes: 350A; 350B; 350C; and 350D. Each process <NUM> is illustrated with the originating files of each portion of the respective process <NUM>. Specifically, a first portion of process 350A originates from patched ELF file <NUM>, a second portion of process 350A originates from patched shared object file <NUM>, a third portion of process 350A originates from protection module 210A, a fourth portion of process 350A originates from protection module 210C and a fifth portion of process 350A originates from process protection manager 220A.

A first portion of process 350B originates from patched ELF file <NUM>, a second portion of process 350B originates from patched shared object file <NUM>, a third portion of process 350B originates from protection module 210B, a fourth portion of process 350B originates from protection module 210B and a fifth portion of process 350B originates from process protection manager 220B.

A first portion of process 350C originates from ELF file <NUM>, a second portion of process 350C originates from patched shared object file <NUM>, a third portion of process 350C originates from protection module 210C and a fourth portion of process 350C originates from process protection manager 220C.

A first portion of process 350D originates from ELF file <NUM>, a second portion of process 350D originates from patched shared object file <NUM>, a third portion of process 350D originates from protection module 210C and a fourth portion of process 350D originates from process protection manager 220C.

In one example, in process 350A the user wants to apply only deterministic protection with zero level of false positive detection. Therefore, the user configures process protection manager 220A to have only deterministic security checks such as verifying that jumping in the flow is to the beginning of a function. In addition, in the case of anomaly detection, process protection manager 220A performs only reporting of the anomaly. In contrast, process 350B has a risky functionality, e.g. receives packets from a socket and parses it. In this case, the user wants to apply all security features to prevent any false negatives. Therefore, the user configures process protection manager 220B to have a plurality of security checks such as heap protection, process isolation, etc. Additionally, in the case of anomaly detection, process protection manager 220B performs reporting and mitigation, i.e. prevents the performance of the operation and/or terminates the process. In an embodiment where the process is terminated, a watchdog process will then restart the terminated process, as known to those skilled in the art.

As shown in processes 350C and 350D, the user can choose to protect only the shared library, i.e. patched shared object file <NUM>, for example if it is provided by a 3rd party. Therefore the user executes unpatched ELF files <NUM> and <NUM>, for which there will be no protection at runtime. Additionally, process protection manager 320C, which is a shared object is loaded into both processes. For each process, process protection manager 320C is loaded as LD_PRELAOD, therefore it will see that a patched shared object file <NUM> is loaded and it will add security by loading protection module 210C.

The above examples show the flexibility of CFI system <NUM> in relation to: controlling what to protect; controlling how to protect; controlling what to do in case of anomaly detection.

The above has been described in relation to an embodiment where opcodes in the ELF and shared object files are replaced with instructions to enter the respective protection modules, however this is not meant to be limiting in any way. In another embodiment, instead of replacing opcodes, code is added to each file to call the respective protection module in order to check the validity of the operation.

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.

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.

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.

Claim 1:
A control flow integrity (CFI) system (<NUM>, <NUM>) comprising:
at least one protection module (<NUM>), each of said at least one protection module associated and comprising an allowable flow model for a respective ELF or shared object file which calls said at least one protection module; and
at least one process protection manager (<NUM>),
the system configured to load (<NUM>, <NUM>), if the respective ELF or shared object is loaded into at least one of a plurality of portions of a process and exhibits a predetermined indication, said at least one protection module and a process protection manager of the at least one process protection manager respective to the protection module into the process,
the at least one of the plurality of portions of the process comprising a control flow instruction to enter said associated protection module, said associated protection module comprising an instruction to enter the respective one of said at least one process protection manager,
wherein said associated protection module is configured, responsive to the control flow instruction to send predetermined information to said respective one of said at least one process protection manager, said predetermined information comprising parameters of the allowable flow model comprised in said associated protection module,
wherein said respective one of said at least one process protection manager is arranged, responsive to said sent predetermined information, to:
compare (<NUM>) one or more parameters of the control flow instruction to the parameters of said allowable flow model comprised in said associated protection module; and
responsive to an outcome of said comparison indicating that said compared one or more parameters does not meet a respective parameter of said respective allowable flow model, generate (<NUM>) a predetermined signal,
wherein each of said at least one protection module is implemented as a shared object,
wherein each of said at least one process protection manager is implemented as a shared object.