System and method for evaluating the exposure of binaries to code reuse attacks

Abstract

System and method for evaluating the exposure of binaries to code reuse attacks. The present invention relates to a method for evaluating the exposure of binaries of an application to code reuse attacks by an attacker.The process includes steps such as classifying a set of gadgets identified in the application code by prerequisite; identifying a plurality of operand registers for the prerequisites; constructing a list of target registers from among these operand registers; calculating a value representing an attacker control level for each target register used as an operand for a prerequisite; calculating a value representing an exposure level for each prerequisite based on the attacker control level for each target register; calculating a value representing an exposure level for each attacker objective based on a weight associated with each prerequisite; and calculating an exposure score for the application binaries against code reuse attacks based on the exposure levels of the attacker objectives. Figure for the abstract: Fig. 1.

Description

Title of the invention: System and method for evaluating the exposure of binaries to code reuse attacks

[0001] The present invention relates to the technical field of software attacks and more particularly to such attacks by code reuse.

[0002] Code reuse attacks, designated by the acronym ARC, are software attacks, potentially carried out remotely, aimed at hijacking the execution flow of a target application in order to achieve an unintended effect on the target application's developers and users. This unintended effect is generally malicious and must therefore be treated as such.

[0003] To achieve a malicious effect, ARCs will cause the execution of "pieces of code," also commonly referred to as "computer gadgets" or simply "gadgets." These gadgets are taken from within the reachable code, either from the target application itself or from software libraries it uses. This execution is carried out in an order determined by the attacker, which differs from the application's nominal execution order. Thus, the attacker can bypass large portions of the target application's code, re-execute certain pieces at will, reverse execution, and more generally, manipulate the execution to suit their purposes. This altered behavior of the target application is expressed by the attacker as a "gadget chain," the sequence of gadgets to be executed by the target application.In practice, this chain of gadgets takes the form of a list of memory addresses within the process running the target application.

[0004] Although various mechanisms such as "Return Oriented Programming" (ROP) or "Jump Oriented Programming" (JOP) can be used to control the execution of a chain of gadgets, the payload of the gadgets does not depend on this mechanism, although said mechanism may limit the usability of this payload.

[0005] For a given application, the degree of exposure to code reuse attacks can be defined as the ability to construct a code reuse attack, from the point of view of a theoretical attacker, and the degree of danger of this attack, i.e. the achievable malicious effects.

[0006] ARCs are a widely covered topic in research, and it is possible to separate the corresponding literature into two major axes: an offensive axis presenting processes and operations based on ARCs, and a defensive axis presenting countermeasures and methods to protect a system against ARCs.

[0007] From an offensive standpoint, A. Homescu's article [1], "Microgadgets: Size Does Matter In Turing-complete Retum-oriented Programming," 2012, presents a ROP attack technique based solely on the use of "microgadgets," i.e., gadgets limited to two or three instructions. On an x86 architecture, a class system is constructed to identify the gadgets. It is stated that one gadget per class offers the possibility of creating a chain of gadgets that is "Turing-complete"; a tool for scanning binaries for these gadgets is introduced. Although the article clearly states that a set of Turing-complete gadgets is not necessary to achieve an effective ROP, the evaluation tool presented does not provide a concrete assessment of the risk of exposure.

[0008] Work described in article [3] “Retum-oriented rootkits: Bypassing kernel code integrity protection mechanisms”, R. Hund, 2009, explicitly presents a method for identifying modifications of a register by a gadget, with an algorithm for searching for all possible combinations of gadgets that transfer the value of one register to another.

[0009] From a defensive perspective, with the search for countermeasures against ARCs, we can cite the article [2] "Research on Defending Code Reuse Attack Based on Binary Rewriting," B. He, 2022, which presents a defense system aimed at ensuring Control-Flow Integrity (CFI). The results presented are based on SPEC CPU2006 benchmarks and show, in a raw manner, the number of gadgets initially found, then the percentage of gadgets remaining after implementation of the solution. The authors conclude that their solution is effective solely on the basis that only a very small percentage of gadgets remain exploitable by an attacker. This conclusion, based on a reduction in the number of gadgets without analysis of the remaining set, is common to several articles presenting countermeasures against ARCs.

[0010] We can cite [4] patent application CN115730303 A by H. Liang et al., 2022, “Software isomerization security assessment method and device” where the mechanisms described in the aforementioned article by B. He are used to assess the difference between two versions of the same software in the context of self-modifying code (“isomorphic software” in English).

[0011] The degree of exposure of a binary to ARCs is an integral part of this work, since it determines the ease of mounting an ARC for a given binary or of establishing a number of gadgets available to evaluate the effectiveness of a countermeasure.

[0012] However, there is currently very little work seeking to evaluate the exposure of a binary code to ARCs. The most common approach is to count the number The term "pieces of code," i.e., the number of gadgets, refers to items that are potentially usable for an ARC (Attack on Countermeasures), but without considering incompatibilities between gadgets. This approach is not relevant and leads to an overestimation of risk, particularly in the specific case of Jump Oriented Programming (JOP) ARCs, where numerous side effects render a significant number of gadgets unusable. Furthermore, defining gadget categories, even granular ones, only allows for a crude assessment (typically Turing completeness or not), a condition that is not necessary for developing malicious attacks.

[0013] Other solutions, which aim to construct a chain of gadgets based on an attack described by the attacker, can confirm or refute an attacker's ability to execute a given system call with given parameters. However, these approaches cannot answer the question of an attacker's ability to execute an attack in general, nor, a fortiori, can they assess the severity of that attack.

[0014] Thus, existing solutions based on gadget categorization approaches provide only a superficial analysis of the gadgets reachable by an attacker. Indeed, a study of the number of reachable gadgets without more detailed analysis does not allow for an assessment of the feasibility of an attack response. This is because, on the one hand, gadgets enabling system calls can be introduced by composition (in the ISA RISC-V architecture, for example), and on the other hand, making a system call requires control over its operands, a control that the classification approach cannot assess. Furthermore, the notion of Turing completeness of a gadget set does not imply that an attack is possible or that it can have a malicious effect. Drawing conclusions about the expressiveness of a gadget set based on these two criteria therefore provides only an approximate evaluation.

[0015] ARC construction tools never allow the assignment of objectives beyond the assembly of a prerequisite, more generally the assignment of a register. Therefore, they do not allow the construction of a complete attack chain without manual work. In all cases, they only allow the achievement of a given and known effect (for example, assigning a register to a given value), but they do not allow the evaluation of an attacker's ability to reach a potentially dangerous value in general. These tools cannot therefore be used to perform a vulnerability assessment of software against ARCs, due to the lack of a comprehensive and heuristic approach. Finally, even if some of these tools or methods can discover JOP-type gadgets, none of them is capable of automatically constructing JOP-type chains, even partial ones.

[0016] Thus, the real issue with a set of gadgets is the control it provides over important registers and the ability to make system calls. This metric is not covered by the evaluation methods proposed in the aforementioned articles [1] and [2], nor by similar articles that deal with countermeasures against ARCs or with automatic gadget chaining.

[0017] The object of patent application [4] is (1) to calculate the distribution of categorized and exploitable gadgets in the context of a Code Reuse Attack on an application and (2) to implement this evaluation to calculate the distance between two variants of the same application in the context of a software isomerization defense (i.e., "mutant software"). The risk model is that of an attacker seeking to discover gadgets during execution and not in the pre-attack phase. In particular, the notion of distance between two "variants" will value a different distribution of gadgets, an element that only makes sense in the context of mutations of the attacked software during execution.

[0018] Regarding the method for calculating the exploitability of a gadget, the patent applicants [4] do not assume any assumptions about the operating system (OS). Consequently, they lose the semantics of the system calls. More generally, there is no semantics associated with the gadgets found, beyond the initial classification. This approach is purely quantitative and statistical and relies on existing attack databases to assess the feasibility of an attack. In particular, the proposed statistical approach does not allow for distinguishing between two instructions belonging to the same class, one of which is critical to one or more attacking objectives, and the other is not. Nor does it allow for distinguishing negative side effects, i.e., conflicts between gadgets.

[0019] There is therefore a need to detect conflicts between gadgets in order to reduce false negatives.

[0020] Finally, the issue of register control is not addressed systematically in [4] and the proposed statistical approach does not allow us to evaluate the degree of control over the registers necessary for the execution of a prerequisite (i.e. system call, load / store).

[0021] The aim of the invention is therefore to propose a method for evaluating, for a given application, the level of exposure to code reuse attacks, and to ensure the safety of the application itself.

[0022] The risk assessment of the use of ARCs is carried out by means of an analysis of the application binaries and software libraries upstream of an attack.

[0023] Advantageously, the method of the invention is based on a thorough semantic analysis of the instructions contained in gadgets, with a view to deducing a applicability to high-level concepts, which are then associated to infer the feasibility of attacking objectives.

[0024] The general principle of the invention is to exploit both knowledge of the target system, in particular its Application Binary Interface (ABI), which specifies the rules that the compiler must follow in the use of hardware resources such as general-purpose registers, and knowledge of the attacker's high-level objectives, in terms of the effects they intend to have on the target application or system. Such effects can materialize through system calls that the attacker will attempt to make, which themselves will involve the use of certain specific registers. Advantageously, thanks to this dual knowledge (i.e., "self-knowledge and enemy knowledge"), the method of the invention is heuristic and makes it possible to assess the risk associated with code reuse attacks for a given application.

[0025] Advantageously, the proposed solution is more precise than known approaches and exhibits far fewer false positives or negatives. It allows for the detection of negative side effects, i.e., conflicts between gadgets, thus reducing false negatives. Furthermore, it allows for the evaluation of the degree of control over the registers necessary for the execution of a prerequisite (system call, "load / store").

[0026] To this end, the invention relates to a method for evaluating the exposure of application binaries to code reuse attacks by an attacker, the method being implemented by computer and comprising steps consisting of:

[0027] - to classify by prerequisite a set of gadgets identified in the application code, a prerequisites defining instructions in the application's binary code that allow an attacker to perform certain actions;

[0028] - identify a plurality of operand registers of prerequisites;

[0029] - construct a list of target registers from among said operand registers;

[0030] - calculate a value representing a level of attacker control for each target-register used as an operand of a prerequisite;

[0031] - calculate a value representing an exposure level of each prerequisite in function of the attacker's level of control for each target register;

[0032] - calculate a value representing an exposure level of the objectives for each the attacker's objective based on a weight associated with each prerequisite; and

[0033] - calculate an exposure score for the application binaries against attacks by code reuse based on the exposure levels of the attacker's objectives.

[0034] According to other advantageous aspects of the invention, the process of the invention comprises one or more of the following features, taken individually or in all technically possible combinations: - the step of constructing a list of target registers from among said operand registers includes a step of characterizing each target register according to the binary interface of the application implemented during compilation, by a triplet defining a target register identity, a target register mode and a target register weight. - The step of calculating a value representing an attacker's level of control for each target register involves taking into account the weight value of each register in the calculation. - The step of calculating a value representing an exposure level of each prerequisite consists of determining the minimum value of the attacker's control values ​​for each target register. - The step of calculating a value representing a level of exposure of the objectives consists of calculating the weighted sum of the weights associated with each prerequisite. - Attacking objectives are classified into three categories consisting of (a) targeting resources external to the application; (b) corrupting memory accessible to the application; (c) executing third-party code. - The step of calculating an exposure score for the application binaries to code reuse attacks consists of calculating the sum of the values ​​representing the level of exposure of the targets. - an additional step consisting of displaying the results of the calculation steps on a display device.

[0035] The invention also relates to a device for evaluating the exposure of binaries of an application to code reuse attacks by an attacker, the device comprising means for implementing the steps of the evaluation process of the invention.

[0036] The invention also addresses a software vulnerability detection unit comprising a device according to the invention for evaluating the exposure of binaries of an application to code reuse attacks by an attacker.

[0037] The invention also relates to a security validation and remediation unit comprising such a software vulnerability detection unit.

[0038] The invention also relates to a computer program comprising code instructions for performing the steps of the process of evaluating the exposure of binaries of an application to code reuse attacks by an attacker when the program is executed on a computer.

[0039] The invention will find advantageous applications for any software running on connected systems. It is particularly relevant for such systems running an application whose security level is uncertain, which may be the case, for example, if an application is developed by a third party.

[0040] The technical fields of application for which the present invention can be implemented cover, without being exhaustive, avionics, space, automotive, radars, I0T / II0T connected objects, command systems.

[0041] The invention will become clearer upon reading the following description, given solely by way of non-limiting example, and made with reference to the drawings in which:

[0042] [Fig-1] [Fig.1] represents in the form of a flowchart the steps of a process risk assessment of code reuse attacks, according to an embodiment of the invention;

[0043] [Fig.2] [Fig.2] illustrates the ability to reach a given value for a register- target ;

[0044] [Fig.3] [Fig.3] schematically represents the functional modules of the device of the invention, in an embodiment;

[0045] [Fig.4] [Fig.4] represents a security validation and remediation chain enabling an implementation of the device of the invention.

[0046] [Fig.1] Fig.1 represents in the form of a flowchart the steps of a process for evaluating the risk of attack by code reuse, according to an embodiment of the invention.

[0047] Preliminary steps not shown allow, for example by means of a gadget detection tool, the identification of gadgets and, if necessary, the filtering of side effects related to the gadget chaining mechanism. Such a mechanism can also be used by the method of the invention to filter other side effects. The gadget detection tool can be separate from and coupled to the device of the invention or can be part of the device of the invention as an optional module.

[0048] Once a set of gadgets has been identified, the method 100 for assessing the risk of code reuse attack consists, in a first step 102, of classifying the gadgets by prerequisite.

[0049] The invention is based on the concept of a "prerequisite." In the context of the invention, a prerequisite defines a set of instructions in the target binary code of an application that can enable an attacker to perform a certain effect on a storage asset accessible by the application. Although executing the prerequisite is not necessarily the ultimate goal of an attack, it is a necessary step toward its completion, and its individual effect is significant from a system security perspective. This is why most prerequisites are system calls, although load instructions and store instructions are not. " can also be part of it, because they have a semi-persistent effect by modifying memory.

[0050] There are three types of objectives that an attacker can target in order to achieve a malicious effect: (a) targeting resources external to the application, but accessible to it, such as files, devices or buses; (b) corrupting the memory accessible to the application (in order to achieve a semi-persistent effect); (c) executing third-party code.

[0051] The prerequisites differ depending on each objective. Thus, for objective (a) of accessing external resources, the prerequisites are: - Any system call allowing access to external resources linked to files or communication channels: "open / read / write" commands; - Any system call that allows alteration of the metadata of external resources: "chmod" (change mode) / "chown" (change owner) commands; - Any system call that makes an external resource addressable in memory: the "mmap" (memory map) command.

[0052] Similarly, the prerequisites for objective (b) of accessing memory are: - Any instruction or system call that allows writing to memory, for example "store"; - Any instruction or system call that allows reading from memory, for example "load".

[0053] The prerequisites for objective (c) of third-party code execution are: - Any system call that allows changing the status of a part of the memory: "mprotect" (memory protect); - Any system call that allows the execution of an "exec" binary; - Any system call that allows cloning the "fork" execution flow.

[0054] In one embodiment, gadget classification step 102 is performed on a subset of prerequisites, referred to as prerequisites of interest, which are sufficient to produce a malicious effect. Optionally, other prerequisites may be added to the initial, non-exhaustive list.

[0055] Advantageously, the method of the invention makes it possible to manage side effects on gadgets. Indeed, if one gadget modifies registers A and B in this order, and a second gadget modifies these registers B and A in this other order, then these two gadgets are considered incompatible if A and B are both necessary for a prerequisite. This is a conservative, but realistic, approach that leads only to a slight underestimation of the actual usability of certain gadgets. The opposite assumption would lead to a large number of false positives and would significantly overestimate the number of gadgets. exploitable. Also, in the event that this situation arises, it is necessary to explore both alternatives and choose the one most favorable to the attacker.

[0056] In one embodiment, these prerequisites of interest are expressed using the system calls and instructions of an ISA / ABI RISC-V architecture. In an alternative embodiment, a set of prerequisites of interest can be established for an ARM or x86 / 64 architecture.

[0057] The process continues with a step 104 enabling the identification of a plurality of operand registers of the prerequisites.

[0058] In the context of the invention, such registers are defined as "target register" to characterize the use of a register within the framework of a prerequisite.

[0059] The process continues with a step 106 allowing the construction of a list of target registers.

[0060] A target register is defined by a model consisting of a triplet (identity, mode, weight), made up of an identity, a mode and a weight of target register.

[0061] The identity of a target register:

[0062] Depending on the application binary interface (ABI) implemented during compilation, the prerequisite operands can use either registers whose identity is constant (as is the case for system calls in RISC-V) or variable (as is the case for load and store instructions in RISC-V). In the second case, the identity of the registers is determined by traversing the binary, whereas in the first case it can be determined simply by knowing the ABI.

[0063] The mode of a target register:

[0064] The mode indicates the expected data profile that characterizes the nature of the data with a value in {identifier, address, size, bitfield}. This allows us to deduce a range of plausible values. The data profile will determine ranges of possible values. Fundamentally, an identifier is a file descriptor, with a value starting at zero and incremented as allocations are made (therefore statistically low). Typically, a mode will have an identifier value less than 5000 on current systems, and a file size will average 1 kilobyte. In a binary representation, it is possible to determine a certain number of bits as always being zero (the most significant bits).

[0065] The mode of a target register is determined by knowledge of the ISA, the ABI, and in some cases, by knowledge of the operating system. For example, knowledge of the OS allows the determination of the mode (i.e., the plausible values) of the arguments of system calls (file descriptors, data size, etc.). The identifier depends on the operating system (e.g., file descriptors). The memory address depends on the operating system (e.g., address in user space). The size depends on the application but will generally be a small value (the size of a data item). The bitfield depends on the system call, but preferred values ​​can be deduced from the ABI (e.g., flags of a system call).

[0066] The weight of a target register:

[0067] Weighting indicates the importance of the argument from the attacker's perspective. The weight of a target register is determined by the attacker's knowledge of the ABI and their objectives. This weight can represent the relevance of an operand. The weight of a target register also indicates the degree of control required over that register.

[0068] In one embodiment, the weight of a target register can take one of three predefined values: major, minor or zero.

[0069] A typical example of a major target register is the assignment of a memory address in the context of memory control, where the attacker will typically add several successive offsets to a known address. A typical example of a minor target register is the assignment of a memory address in the context of external resource control, where the attacker will typically have to read from or write to an address that is already known, and therefore assigned somewhere in the application code.

[0070] Each prerequisite thus has a weight associated with it according to the attacker's objective.

[0071] If a target register is to be used with different modes or weights, several target registers are generated.

[0072] In a subsequent step 108, the method makes it possible to perform a calculation of an attacker control level for each target register.

[0073] As illustrated in [Fig.2], it is possible for a 'reg' register to reach a given value according to three options (A), (B) or (C).

[0074] Option (A) covers arithmetically assignable values. This corresponds to the ability to transfer a value from a set of third-party registers (typically one or two), as well as the ability to assign a target value from an arbitrary and unknown initial value (i.e., an assignment followed by a series of arithmetic operations and / or register transfers).

[0075] Option (B) covers stack control – specifically, the "stack" heap. This corresponds to the ability to load an address from a memory address potentially controlled by the attacker. The control value is assigned to 'REGLOADSTACK'.

[0076] Option (C) covers memory control. This corresponds to the ability to control memory, by (1) finding a pair of instructions to write (store) and read (load) into memory, by (2) checking the registers indicating the target addresses and by (3) checking the registers indicating the data (in the context of a write).

[0077] According to option (A), the ability to assign a register, denoted (CAR), is an estimate of the ability to assign a target register directly to a value targeted by a attacking or to a value "close" to it (i.e., attainable with few iterations with a predefined increment). This value is calculated on a scale limited by a maximum value denoted 'CAR_MAX'.

[0078] Thus, for each gadget performing the assignment of a target register to a value N, the assignment depends on the value N and consists of: - If N is included in a preferred range, a 'REGFAVSET' value is added on the first occurrence, then the value divided by two 'REGFAVSET / 2' is added for each gadget satisfying this condition again, with a different assignment value (gadgets adding the same value are eliminated); - If N is outside the preferred range, the value 'REGNFAVSET' is added at the first occurrence, then the value divided by two 'REGNFAVSET / 2' is added for each gadget satisfying this condition again, with a different assignment value (gadgets adding the same value are eliminated).

[0079] Depending on the mode defined for a target register, the values ​​targeted by the attacker can be confined within a preferred range. This range can be reached from an unknown starting value for a given target register by assigning it a value, and then the precise value desired by the attacker can be targeted by incrementing it. To represent this knowledge, a preferred range, denoted 'INTPREF', and a preferred increment, denoted 'INCRPREF', are defined for each target register mode. These two values ​​are initially estimated based on the system architecture, the ISA, the ABI, and the operating system.

[0080] [Table 1]Table 1 below illustrates an example of performing a calculation of Capacity to Assign a Register for a target register R, CAR(R) according to option (A). CAR = 0 IF NEW VALUE OF N THEN IF N BELONGS TO INTPREF THEN IF FIRST OCCURRENCE OF ASSIGNMENT THEN CAR = CAR + REGFAVSET ELSE CAR = CAR + REGFAVSET / 2 ENDIVE ELSE IF FIRST OCCURRENCE OF ASSIGNMENT THEN CAR = CAR + REGNFAVSET ELSE CAR = CAR + REGNFAVSET / 2 ENDIVE ENDIVE ENDIVE

[0081] According to option (B), value transfer operations refer to all operations transferring, directly or with the addition of an increment / decrement, a value from a set of source registers (registers read by an instruction) to a destination register (a register written by an instruction whose identity is encoded in the instruction). The measure of control obtained on a destination register is the minimum of the CAR values ​​for the source registers. It is equal to the value of the source register itself if this register is unique (which is the most frequent case).

[0082] In one embodiment, the calculation can be performed according to the following equation:

[0083] CHAR(REGD) = CHAR(REGD) + MIN (CAR(REGSi)) where REGS; are the source registers of an instruction allowing a transfer of value, and REGD is a destination register.

[0084] In one embodiment, if the value transfer is associated with an arithmetic operation or with a logic different from a transfer of an identical value, and if the set of source registers can be assigned (the value of CAR being non-zero), then the method makes it possible to add to the value of the control measure on the register, a value of Capacity to Change the value of the Register, and denoted (CCR).

[0085] Register Value Change Ability (CCR) is the ability to change the value of a register by means of an arithmetic operation until the value targeted by the attacker is reached. This value is limited by a maximum value denoted 'CCR_MAX'.

[0086] Thus, for each gadget that allows adding a relative integer value N, the addition depends on the value N and consists of: - If N is equal to the predefined increment, a value denoted 'REGFAVINC' is added to the CCR value only at the first occurrence; - If N is equal to the opposite of the predefined increment, a value denoted 'REGFAVDEC' is added to the CCR value at the first occurrence only; - In other cases, excluding an operation to transfer an identical value to N, a value noted 'REGNFAVMV' is added to the value of the CCR; - For any operation other than addition or subtraction (e.g. XOR, OR, AND, multiplication, division), a low control value noted as 'REGLOWOP'.

[0087] [Table 2] Table 2 below illustrates an example of an implementation for an operation denoted 'OPE', of the calculation of the capacity to change the value of a register for a register R, and denoted 'CCR(R)', according to option (B). CCR = 0 IF NEW VALUE OF N THEN IF OPE IS ARITHMETIC THEN IF N == INCRPREF AND FIRST OCCURRENCE OF ASSIGNMENT THEN CCR = MIN(CCR + REGFAVINC, CCR_MAX) ELSE IF N == - INCRPREF AND FIRST OCCURRENCE OF ASSIGNMENT THEN CCR = MIN(CCR + REGFAVDEC, CCR_MAX) ELSE CCR = MIN(CCR + REGNFAVMV, CCR_MAX) ENDIVE ENDIVE ELSE CCR = MIN(CCR + REGLOWOP, CCR_MAX) ENDIVE ENDIVE

[0088] A person skilled in the art understands that this example is not exhaustive and may adapt the calculation of a CCR for a register based on the nature of the operation.

[0089] The calculation of the level of control of an attacker over each target register also depends on the weight of the register concerned.

[0090] If the weight of a target register is classified as 'major', the control level on that register, denoted 'REGCON', can be calculated according to the value of the CAR: - if the CAR value is non-zero, the REGCON control level is determined by the sum of the CAR value and the CCR value, bounded at 100; - otherwise the REGCON control level is zero.

[0091] If the weight of a target register is classified as 'minor', the control level on that register 'REGCON' can be calculated by performing the multiplication: CAR * 2, bounded at 100.

[0092] If the weight of a target register is classified as 'null', the control level on that REGCON register is set to the value 100. A value of 100 indicates sufficient control over a register to implement a prerequisite.

[0093] [Table 3] Table 3 below illustrates an example of calculating a control level on a target register R as a function of the register weight. IF WEIGHT(R) IS “MAJOR” IF CAR != 0 THEN REGCON = MIN(CAR+CCR, 100) ELSE REGCON = 0 ENDIVE ELSEIF POIDS(R) IS “MINEUR” THEN REGCON = MIN(CAR*2, 100) ELSE REGCON = 100 ENDIVE

[0094] Thus, step 108 makes it possible to obtain a REGCON value defining the level of control of an attacker over each target register used as an operand of a prerequisite.

[0095] The process continues with a step 110 consisting of calculating a level of exposure of the prerequisites denoted 'FP', based on the level of control of an attacker over each target register previously calculated.

[0096] In one embodiment, the exposure level for a prerequisite P is calculated as being equal to the minimum of the REGCON control values ​​on the target registers for that prerequisite, according to a function FP defined by the following equation:

[0097] FP(P) = MIN(REGCON(R)) where R is a target register of prerequisite P.

[0098] Thus, step 110 makes it possible to obtain an FP(P) value, defining the level or degree of exposure for each prerequisite.

[0099] When the FP exposure level of the prerequisites is calculated, the process continues with a step 112 allowing the level of exposure of the attacking objectives, noted 'FO', to be calculated for each objective 'O', according to a weight associated with each prerequisite.

[0100] In one embodiment, the exposure level of an attacking objective is calculated as a weighted sum of the weight associated with each prerequisite.

[0101] This value is not bounded, since each prerequisite is a potential path for the attack.

[0102] The calculation of FO(O) for an objective O can be carried out according to a function FO defined by the following equation:

[0103] FO = SUM(POIDS(P,O) * FP(P)) where P is a prerequisite of objective O, where POIDS(P,O) is the weight of the prerequisite P for objective O.

[0104] Thus, step 112 makes it possible to obtain an FP value defining the level of exposure of each of an attacker's objectives.

[0105] The process then continues with a step 114 consisting of calculating a score representing the level of exposure of the application binaries of the application to code reuse attacks, denoted 'FA', as a function of the exposure levels to each attacking target calculated previously.

[0106] In one embodiment, for an application 'A', the calculation of FA(A) consists of summing the exposure levels to the attacking objectives, and is carried out according to a function FA defined by the following equation:

[0107] FA = SUM(FO(O)) where O is a defined objective for A.

[0108] The process thus ends by providing a FA value representative of a level of exposure of the binaries of a given application to code reuse attacks.

[0109] In one embodiment, the risk assessment can be refined by defining attacker profiles. Defining a profile is based on the preferred methods an attacker can use to perform a certain type of action, and on knowledge of the targeted system. The targeted system may contain a hidden secret or may be compromised through fraudulent writes to memory or files.

[0110] Preliminary steps to process 100 allow for the definition of attacker profiles and types of action. In this embodiment, step 112 of the calculation of the exposure level of attacking targets takes into account the parameters defined in the attacker profiles and allows for the application of different weightings depending on the attacker profiles and attacking targets.

[0111] [Fig.3] Fig.3 schematically represents the functional modules of the device evaluation of the invention, in an embodiment.

[0112] In the example of [Fig.3], the electronic evaluation device 300 includes an information processing unit 302 formed for example of a memory and a processor associated with the memory, a module 304 configured to define target prerequisites, a module 306 configured to classify gadgets by prerequisite, a module 308 configured to identify operand registers for each prerequisite, and a module 310 configured to perform calculations for the functions FP, FO, FA.

[0113] The various modules are each implemented as a software program, or a software component, comprising code instructions executable by the processor. The memory of the electronic device is then capable of storing software for defining target prerequisites, software for classifying gadgets by prerequisite, software for identifying operand registers by prerequisite, and software for calculating FP, FO, and FA functions. The processor is then capable of executing each of the software programs.

[0114] The modules can each be made in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array), or an integrated circuit, such as an ASIC (Application Specified Integrated Circuit).

[0115] As an optional complement, the evaluation device includes a display module 312 allowing the display on a display screen of the FA score which describes the exposure of an application to ARC, as well as the intermediate values ​​of the FP exposure levels of the prerequisites which describe the possible attack path(s) for an attacker, as well as the exposure levels of the attacking objectives FO.

[0116] This information enables the execution platform to trigger measures aimed at reducing the risk associated with running the application. Advantageously, all of this information helps guide software developers' efforts to remediate vulnerabilities.

[0117] Also optional, the evaluation device of the invention includes a module (not shown) for creating attacker profiles and using weightings in the calculations of risk exposure functions based on a profile selected for an attacker.

[0118] When the electronic device is implemented in the form of one or more software programs, that is, in the form of a computer program, also called a computer program product, it is further capable of being stored on a computer-readable medium, not shown. A computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. For example, a readable medium is an optical disc, a magneto-optical disc, ROM, RAM, any type of non-volatile memory (e.g., FLASH or NVRAM), or a magnetic card. A computer program comprising software instructions is then stored on the readable medium.

[0119] In a particular implementation, the parameterization of the device of the invention consists of predefining the mode parameters and control values ​​on the registers to the following preferred values: - Identifier: it is defined as a preferred interval 'INTPREF' an interval [0, 5000], with a preferred increment 'INCRPREF' of 1. - Memory (address): it is defined as preferred interval 'INTPREF' an interval [0x400000000, 0x400FFFFFF] (RISC-V 32 bits), with a preferred increment 'INCRPREF' of 4. - Size: it is defined as preferred interval 'INTPREF' an interval [0,8192], with a preferred increment 'INCRPREF' of 4. - Bitfield: a preferred increment 'INCRPREF' of 1 is defined (there is no preferred interval defined for this value). - CAR_MAX: maximum control over a register via assignment. Predefined value of 50. - CCR_MAX: maximum control over a register via arithmetic operations. Predefined value of 50. - REGLOADSTACK: control bonus obtained from the ability to load a value from the stack. Predefined value of 90. - REGFAVSET: control bonus obtained from the ability to assign a value to the register within the preferred range. Predefined value of 30. - REGNFAVSET: control bonus obtained from the ability to assign a value to the register outside the preferred range. Predefined value of 10. - REGFAVINC: control bonus obtained from the ability to add the preferred increment to the register. Preset value of 30. - REGFAVDEC: control bonus obtained from the ability to subtract the preferred increment from the register. Preset value of 20. - REGNFAVMV: control bonus obtained from the ability to add or subtract a value other than the preferred increment to the register. Preset value of 10. - REGLOWOP: bonus to the control obtained from an operation other than addition or subtraction. Predefined value of 5.

[0120] [Fig.4] The [Fig.4] represents a security validation and remediation chain enabling the implementation of the device of the invention.

[0121] The method for assessing the risk of ARC on a binary can find advantageous exploitation in an industrial process of the type "Integration / Verification / Validation / Qualification" or (IVVQ).

[0122] In such a chain, the method for evaluating the invention can be implemented in a component called a "Software Vulnerability Detection Unit" (LVDU) integrated within an electronic component that is part of a continuous integration / continuous development (CI / CD) process, and more specifically, the IVVQ. The role of the electronic component, called a "Security Validation and Remediation Unit" (SVRU), is to assess the exposure to software vulnerabilities in software artifacts, to report a decision to the IVVQ chain, and optionally, to apply appropriate hardening measures in the final software (binaries, libraries).

[0123] As illustrated in [Fig.4], the electronic component 400 (UVRS) is composed of 3 sub-components:

[0124] - An electronic 402 vulnerability detection subcomponent performing the exposure calculation technique presented above;

[0125] - An electronic decision subcomponent 404 taking into account the needs specific in terms of product safety and security via a configuration;

[0126] - A remediation electronic subcomponent 406 responsible for implementing Classic hardening measures on the software. In the context of ARC detection, measures may consist of hardening the stack (e.g., using Canaries), monitoring critical attack paths (e.g., labeling potential dispatcher gadgets - for example, with ARM BTI technology, or RISC-V landing pads).

[0127] An alternative use involves looping by executing the decision unit after the detection unit by re-injecting the hardened software into the Software Vulnerability Detection Unit.

[0128] The safety validation and remediation unit 400 is used to implement the safety validation stages within the IVVQ chain.

[0129] Note that, in order to detect vulnerabilities early, these security validations can be implemented at different levels:

[0130] - At the end of the compilation;

[0131] - At the end of the link editing;

[0132] - Following system integration.

[0133] At each of these steps, the checks and validations carried out on the artifacts of these steps must be carried out after the security validation step, because the latter may implement countermeasures which, by definition, have an impact on the software.

[0134] Decision unit 404 is an electronic component taking the following input:

[0135] - a structured list of vulnerabilities;

[0136] - a configuration.

[0137] The structured vulnerability list describes:

[0138] - the prerequisites detected;

[0139] - the level of exposure associated with each of these prerequisites.

[0140] The configuration describes:

[0141] - the acceptable vulnerability threshold (dependent on the needs of the product);

[0142] - the detection mode (direct or incremental);

[0143] - the requirements for operational safety (which may limit countermeasures) applicable).

[0144] In direct mode, the vulnerability threshold takes the value associated with the configuration. In incremental mode, the decision will prohibit the introduction of new vulnerability families, or the increase in the exploitability of families already detected in previous steps.

[0145] An alternative use of the method of the invention is during the loading of a binary by the operating system for execution. In this case, the operating system is configured with a maximum acceptable exposure threshold, depending on the criticality level of the calling process or partition. During the loading of the binary, the operating system uses the code reuse attack exposure assessment method according to the invention, and if the exposure value exceeds the maximum acceptable exposure threshold, the system explicitly refuses its execution by setting a specific error value in "errno" and displaying an explicit message.

[0146] Advantageously, any type of operating system can be concerned by this use, in particular multi-criticality systems (e.g. implementing the ARINC653 standard).

[0147] Another advantageous use of the method of the invention is to assess the feasibility of attempting a code reuse attack by a cybersecurity laboratory. Since these attacks are complex to mount and the time available for penetration testing (a penetration test is a thorough, systematic, and manual evaluation of each vulnerability in a computer system) is limited, this use allows for the optimization of the penetration test.

[0148] A method for assessing the risk of an application to code reuse attacks has been described. The method allows for an accurate, albeit heuristic, evaluation of the exposure of an application's binaries to code reuse attacks. By acquiring detailed knowledge of the application's properties and the attacker's objectives, and by breaking with known approaches, the present invention offers the following advantages:

[0149] - a prioritization of prerequisites (system calls, memory access) according to the attacker's objectives; a heuristic is proposed that is more operationally useful than determining a hypothetical set of Turing-complete gadgets;

[0150] - a definition of a model of the values ​​expected by the registers, thus offering a reasonable compromise, informed by operational arguments, between a formal calculation of attainable values ​​(generally not solvable in finite time and expensive to execute even in verifiable cases), and a commonly adopted approach equating the ability to write to a register with complete control of the register;

[0151] - taking into account the side effects between gadgets making them potentially incompatible, thus reducing the number of false positives and therefore overestimation of exposure.

[0152] Thanks to these properties, it is possible to obtain a precision and relevance far superior to the results obtained by state-of-the-art solutions because the approach described for the claimed process takes into account:

[0153] - mechanisms from several approaches (classification and calculation of dependencies between registers);

[0154] - original mechanisms (calculation of control on registers and memory);

[0155] - mechanisms for composing the exposure of prerequisites, with the aim of estimating the feasibility of achieving malicious effects by an attacker.

Claims

Demands

1. A method for evaluating the exposure of application binaries to code reuse attacks by an attacker, the method being implemented by computer and comprising steps consisting of: - classifying by prerequisite (102) a set of gadgets identified in the application code, a prerequisite defining instructions in the application binary code enabling an attacker to perform certain actions; - identifying (104) a plurality of operand registers of the prerequisites; - constructing (106) a list of target registers from among said operand registers; - calculating (108) a value representing an attacker's level of control for each target register used as an operand of a prerequisite; - calculating (110) a value representing an exposure level of each prerequisite as a function of the attacker's level of control for each target register;- calculate (112) a value representing an exposure level of the objectives for each of the attacker's objectives as a function of a weight associated with each prerequisite; and - calculate (114) an exposure score of the application binaries to code reuse attacks as a function of the exposure levels of the attacker's objectives.

2. The method according to claim 1 wherein the step (106) of constructing a list of target registers from among said operand registers comprises a step of characterizing each target register according to the binary interface of the application implemented at compilation, by a triplet defining a target register identity, a target register mode and a target register weight.

3. The method according to claim 1 or 2 wherein step (108) of calculating a value representing a level of attacker control for each target register consists of taking into account the weight value of said register in the calculation.

4. The method according to any one of claims 1 to 3 wherein the step (110) of calculating a value representing an exposure level of each prerequisite consists of determining the minimum value of the attacker's control values ​​for each target register.

5. The method according to any one of claims 1 to 4 wherein the step (112) of calculating a value representing an exposure level of the objectives consists of calculating the weighted sum of the weights associated with each prerequisite.

6. The method according to any one of claims 1 to 5 wherein the attacking objectives are classified into three categories consisting of (a) targeting resources external to the application; (b) corrupting the memory accessible to the application; (c) executing third-party code.

7. The method according to any one of claims 1 to 6 wherein the step (114) of calculating an exposure score of the application binaries to code reuse attacks consists of calculating the sum of the values ​​representing the level of exposure of the targets.

8. The method according to any one of claims 1 to 7 further comprising a step of defining attacking profiles, and wherein the step of calculating the level of exposure of the attacking targets takes into account the parameters defined in the attacking profiles.

9. The method according to any one of claims 1 to 8 further comprising a step of displaying the results of the calculation steps on a display device.

10. A computer program comprising code instructions for performing the steps in the process of evaluating the exposure of application binaries to code reuse attacks by an attacker according to any of the preceding claims when the program is executed on a computer.

11. A device for evaluating the exposure of application binaries to code reuse attacks by an attacker, the device

12.

13. including means for implementing the steps of the evaluation process for any one of claims 1 to 9. Software vulnerability detection unit comprising a device according to claim 11. Security validation and remediation unit comprising a software vulnerability detection unit according to claim 12.