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

Abstract

The present invention relates to a method for evaluating the exposure of binaries of an application, to code reuse attacks by an attacker. The method comprises steps of: - classifying, by prerequisite, a set of gadgets identified in the code of the application; - identifying a plurality of operand registers of the prerequisites; - building a list of target registers from among the operand registers; - computing a value representing a control level of the attacker for each target register used as an operand of a prerequisite; - computing a value representing an exposure level of each prerequisite according to the level of control of the attacker over each target register; - computing a value representing an exposure level of the targets for each target of the attacker according to a weight associated with each prerequisite; and - computing an exposure score for the binaries of the application to code reuse attacks according to the exposure levels of the targets of the attacker.

Description

[0001] TITLE: System and method for evaluating the exposure of binaries to code reuse attacks

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

[0003] Code reuse attacks, known by the acronym ARC, are software attacks, potentially carried out remotely, that aim to hijack the execution flow of a target application in order to achieve an unintended effect on both the target application's developers and users. This unintended effect is usually malicious and should be treated as such.

[0004] To achieve malicious effects, ARCs trigger 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 performed in an order determined by the attacker, which differs from the application's normal execution order. Thus, the attacker can bypass large portions of the target application's code, re-execute certain pieces at will, reverse execution, and 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 concrete terms, this chain of gadgets takes the form of a list of memory addresses within the process running the target application.

[0005] 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 gadget payload does not depend on this mechanism, although said mechanism may limit the usability of this payload.

[0006] 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.

[0007] 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 exploitations based on ARCs, and a defensive axis presenting countermeasures and methods to protect a system against ARCs.

[0008] From an offensive perspective, A. Homescu's article [1], "Microgadgets: Size Does Matter In Turing-complete Return-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 these 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 perform an effective ROP, the evaluation tool presented does not offer a concrete assessment of the risk of exposure.

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

[0010] From a defensive perspective, particularly regarding 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 format, the number of gadgets initially found, then the percentage of gadgets remaining after implementing 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.

[0011] 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 gap between two versions of the same software in the context of self-modifying code (“isomorphic software” in English).

[0012] The degree of exposure of a binary to countermeasures is an integral part of this work, as it determines the ease of mounting a countermeasure for a given binary or establishing a number of available gadgets to assess the effectiveness of a countermeasure. However, very little research currently focuses on evaluating the exposure of binary code to countermeasures. The most common approach is to count the number of "code snippets," i.e., the number of gadgets, that are potentially usable for a countermeasure, without taking into account 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) countermeasures, where numerous side effects render a significant number of gadgets unusable.Furthermore, defining categories of gadgets, even fine ones, only allows for a crude evaluation (typically Turing completeness or not), a condition that is not necessary to develop malicious attacks.

[0013] Other solutions, which aim to build 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, let alone 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 cannot assess the feasibility of an attack response strategy (ARC). This is because, on the one hand, gadgets that enable system calls can be introduced through 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 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] Tools designed to aid in the construction of ARCs (Attack-Return Attacks) never allow for the assignment of objectives beyond the assembly of a prerequisite, most commonly the assignment of a register. Therefore, they do not allow the construction of a complete attack chain without manual intervention. In all cases, they only allow for a given and known effect (for example, assigning a register to a specific value), but they do not allow for the assessment 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 are 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 purpose of patent application [4] is (1) to calculate the distribution of categorized and exploitable gadgets in 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 a software isomerization defense (i.e., "mutant software"). The risk model is that of an attacker seeking to discover gadgets during execution, 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 in 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 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 using ARCs is performed by analyzing the application binaries and software libraries prior to an attack. Advantageously, the method of the invention relies on a thorough semantic analysis of the instructions contained in gadgets, in order to deduce their applicability to high-level concepts, which are then combined to infer the feasibility of attack objectives.

[0023] 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 the compiler must follow in using 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 be manifested by system calls the attacker will attempt, 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 allows for the assessment of the risk associated with code reuse attacks for a given application.

[0024] The proposed solution is also advantageous, being more precise than known approaches and exhibiting 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 enables the evaluation of the degree of control over the registers required to execute a prerequisite (system call, "load / store").

[0025] 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:

[0026] classify by prerequisite a set of gadgets identified in the application code, a prerequisite defining instructions in the application's binary code allowing an attacker to perform certain actions;

[0027] identify a plurality of operand registers of prerequisites;

[0028] construct a list of target registers from among said operand registers; calculate a value representing an attacker control level for each target register used as an operand of a prerequisite;

[0029] calculate a value representing an exposure level of each prerequisite based on the attacker's level of control for each target register;

[0030] calculate a value representing an exposure level of the objectives for each attacker's objective based on the exposure level of each prerequisite and a weight associated with each prerequisite; and calculate an exposure score of the application binaries to code reuse attacks based on the exposure levels of the attacker's objectives.

[0031] 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:

[0032] 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.

[0033] 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 said register in the calculation.

[0034] 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.

[0035] The step of calculating a value representing an exposure level of the objectives consists of calculating the weighted sum of the weights associated with each prerequisite. Attacking objectives are classified into three categories: (a) targeting resources external to the application; (b) corrupting memory accessible to the application; (c) executing third-party code.

[0036] The step of calculating an exposure score for application binaries to code reuse attacks consists of calculating the sum of the values ​​representing the level of exposure of the targets.

[0037] an additional step consisting of displaying the results of the calculation steps on a display device.

[0038] 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 method of evaluation of the invention.

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

[0040] The invention also relates to a security validation and remediation unit comprising such a software vulnerability detection unit. The invention further relates to a computer program comprising code instructions for performing the steps of a process to evaluate the exposure of application binaries to code reuse attacks by an attacker when the program is executed on a computer.

[0041] 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.

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

[0043] 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:

[0044] Figure 1 represents in the form of a flowchart the steps of a process for assessing the risk of attack by code reuse, according to one embodiment of the invention;

[0045] Figure 2 illustrates the ability to reach a given value for a target register; Figure 3 schematically represents the functional modules of the device of the invention, in one embodiment;

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

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

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

[0049] Once a set of gadgets has been identified, the code reuse attack risk assessment method 100 consists, in a first step 102, of classifying the gadgets by prerequisite. 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 support 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 of the prerequisites are system calls, although load instructions and store instructions can also be part of them, as 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 memory accessible to the application (in order to achieve a semi-persistent effect); (c) executing third-party code.

[0051] The prerequisites differ depending on the objective. For example, for objective (a) access to external resources, the prerequisites are:

[0052] - Any system call allowing access to external resources linked to files or communication channels: "open / read I write" commands;

[0053] - Any system call that allows alteration of the metadata of external resources:

[0054] “chmod” (change mode) / “chown” (change owner) commands;

[0055] - Any system call that makes an external resource addressable in memory: the "mmap" (memory map) command.

[0056] Similarly, the prerequisites for objective (b) of accessing memory are:

[0057] - Any instruction or system call that allows writing to memory, for example "store";

[0058] - Any instruction or system call that allows reading from memory, for example "load".

[0059] The prerequisites for objective (c) of third-party code execution are:

[0060] - Any system call that allows changing the status of a portion of memory:

[0061] “mprotect” (memory protect);

[0062] - Any system call that allows the execution of an "exec" binary;

[0063] - Any system call that allows cloning the "fork" execution flow.

[0064] In one embodiment, step 102 of gadget classification is performed on a subset of prerequisites, referred to as prerequisites of interest, which are sufficient to produce a malicious effect. Optionally, other prerequisites can be added to the initial, non-exhaustive list. Advantageously, the method of the invention allows for the management of side effects on gadgets. Indeed, if one gadget modifies registers A and B in that order, and a second gadget modifies registers B and A in that other order, then these two gadgets are considered incompatible if both A and B are necessary for a prerequisite. This is a conservative, yet 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 exploitable gadgets.Therefore, if this situation were to arise, it is necessary to explore both alternatives and choose the one most favorable to the attacker.

[0065] 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.

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

[0067] 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.

[0068] The process continues with a step 106 which allows a list of target registers to be built.

[0069] 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.

[0070] The identity of a target register:

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

[0072] The mode of a target register:

[0073] 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 with each allocation (therefore statistically small). Typically, a mode will have an identifier value less than 5000 on common 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).

[0074] 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 us to determine the mode (i.e., plausible values) of system call arguments (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).

[0075] The weight of a target register:

[0076] The weight indicates the importance of an argument from the attacker's perspective. The weight of a target register is determined by knowledge of the attacker's 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.

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

[0078] A typical example of a major register target 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 register target 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.

[0079] Each prerequisite has an associated weight depending on the attacker's objective. If a target register is to be used with different modes or weights, several target registers are generated.

[0080] In a subsequent step 108, the process allows for a calculation of an attacker control level for each target register.

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

[0082] 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).

[0083] 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 'R REG LOADSTACK'.

[0084] 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).

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

[0086] Thus, for each gadget that assigns a target register to a value N, the assignment depends on the value N and consists of:

[0087] 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 again satisfying this condition, with a different assignment value (gadgets adding the same value are eliminated);

[0088] If N is outside the preferred range, the value 'REGNFAVSET' is added on the first occurrence, then the value divided by two 'REGNFAVSET / 2' is added for each gadget again satisfying this condition, with a different assignment value (gadgets adding the same value are eliminated).

[0089] 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 through an assignment, 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.

[0090] [Table 1] Table 1 below illustrates an example of performing a Register Assignment Capacity calculation for a target register R, CAR(R) according to option (A). CAR = 0

[0091] IF NEW VALUE OF N THEN IF N BELONGS TO INTPREF THEN IF FIRST OCCURRENCE OF ASSIGNMENT THEN CAR = CAR + REGFAVSET

[0092] ELSE CAR = CAR + REGFAVSET 12

[0093] ENDIF ELSE IF FIRST OCCURRENCE OF ASSIGNMENT THEN CAR = CAR + REGNFAVSET

[0094] ELSE CAR = CAR + REGNFAVSET 12

[0095] ENDIF ENDIF ENDIF

[0096]

[0097] According to option (B), value transfer operations refer to all operations that transfer, 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 within that instruction). The measure of control achieved 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 that register is unique (which is the most frequent case).

[0098] In one embodiment, the calculation can be performed according to the following equation: CHAR(REGD) = CHAR(REGD) + MIN (CAR(REGSj)) where REGSj are the source registers of an instruction allowing a transfer of value, and REGD is a destination register.

[0099] 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 the set of source registers can be assigned (the value of CAR being non-zero), then the method allows adding to the value of the control measure on the register, a value of Capacity to Change the value of the Register, and denoted (CCR).

[0100] Register Changeability (RC) is the ability to change the value of a register using an arithmetic operation until the attacker's target value is reached. This value is limited by a maximum value denoted 'CCR_MAX'.

[0101] 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 at the first occurrence only;

[0102] 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;

[0103] 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;

[0104] For any operation other than addition or subtraction (e.g. XOR, OR, AND, multiplication, division), a low control value noted as 'REGLOWOP'.

[0105] [Table 2] Table 2 below illustrates an example of 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).

[0106] CCR = 0

[0107] IF NEW VALUE OF N THEN IF OPE IS ARITHMETIC THEN IF N == INCRPREF AND FIRST OCCURRENCE OF ASSIGNMENT

[0108] THEN CCR = MIN(CCR + REGFAVINC, CCRJMAX)

[0109] ELSE IF N == - INCRPREF AND FIRST OCCURRENCE OF ASSIGNMENT

[0110] THEN CCR = MIN(CCR + REGFAVDEC, CCRJMAX)

[0111] ELSE CCR = MIN(CCR + REGNFAVMV, CCRJMAX)

[0112] ENDIF ENDIF ELSE CCR = MIN(CCR + REGLOWOP, CCRJMAX)

[0113] ENDIF ENDIF

[0114]

[0115] The person skilled in the art understands that this example is not exhaustive and can adapt the calculation of a CCR for a register according to the nature of the transaction.

[0116] Calculating the level of control an attacker has over each target register also depends on the size of the register in question.

[0117] 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:

[0118] - 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;

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

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

[0121] [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.

[0122] IF WEIGHT(R) IS “MAJOR”

[0123] IF CAR != 0

[0124] THEN REGCON = MIN(CAR+CCR, 100)

[0125] ELSE REGCON = 0

[0126] ENDIF ELSEIF POIDS(R) IS “MINEUR”

[0127] THEN REGCON = MIN(CAR*2, 100)

[0128] ELSE REGCON = 100

[0129] ENDIVE

[0130]

[0131] 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.

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

[0133] 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:

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

[0135] Thus, step 110 allows us to obtain an FP(P) value, defining the level or degree of exposure for each prerequisite.

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

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

[0138] This value is unbounded, since each prerequisite is a potential path for the attack. The calculation of F0(0) for a target O can be performed using a function FO defined by the following equation:

[0139] 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.

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

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

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

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

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

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

[0146] Preliminary steps in process 100 allow for the definition of attacker profiles and types of action. In this embodiment, step 112, which calculates 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 the attacking targets.

[0147] [Fig. 3] Figure 3 schematically represents the functional modules of the evaluation device of the invention, in one embodiment.

[0148] In the example shown in Figure 3, the electronic evaluation device 300 comprises an information processing unit 302, consisting, 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, and FA. Each of the different modules is implemented as a software program, or a software component, comprising code instructions executable by the processor. The memory of the electronic device is thus 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 the functions FP, FO, and FA.The processor is then capable of running each of the software programs.

[0149] 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 Specific Integrated Circuit).

[0150] As an optional addition, the evaluation device includes a 312 display module 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 FO attacking objectives.

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

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

[0153] When an electronic device is implemented as one or more software programs, that is, as a computer program, also called a computer program product, it is also capable of being stored on a computer-readable medium (not shown here). A computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. Examples of such a readable medium include 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 containing software instructions is then stored on this readable medium.

[0154] In a particular implementation, the parameterization of the device of the invention consists of predefining the mode parameters and control values ​​on the registers at the following preferred values: Identifier: it is defined as a preferred interval 'INTPREF' an interval [0, 5000], with a preferred increment 'INCRPREF' of 1.

[0155] Memory (address): it is defined as preferred interval 'INTPREF' an interval [0x400000000, 0x400FFFFFF] (RISC-V 32 bits), with a preferred increment 'INCRPREF' of 4.

[0156] - Size: it is defined as preferred interval 'INTPREF' an interval [0,8192], with a preferred increment 'INCRPREF' of 4.

[0157] Bitfield: a preferred increment 'INCRPREF' of 1 is defined (there is no preferred interval defined for this value).

[0158] CAR_MAX: maximum control over a register via assignment. Predefined value of 50.

[0159] CCR_MAX: maximum control over a register via arithmetic operations. Predefined value of 50.

[0160] REGLOADSTACK: Control bonus obtained from the ability to load a value from the stack. Predefined value of 90.

[0161] REGFAVSET: control bonus obtained from the ability to assign a value to the register within the preferred range. Predefined value of 30.

[0162] REGNFAVSET: control bonus obtained from the ability to assign a value to the register outside the preferred range. Predefined value of 10.

[0163] REGFAVINC: control bonus obtained from the ability to add the preferred increment to the register. Preset value of 30.

[0164] REGFAVDEC: control bonus obtained from the ability to subtract the preferred increment from the register. Preset value of 20.

[0165] REGNFAVMV: Control bonus obtained from the ability to add or subtract a value other than the preferred increment to the register. Preset value: 10. REGLOWOP: Control bonus obtained from an operation other than addition or subtraction. Preset value: 5.

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

[0167] The method for assessing the risk of vulnerabilities in a binary can be advantageously applied in an industrial process such as Integration / Verification / Validation / Qualification (IVVQ). In such a chain, the method for assessing the invention can be implemented in a component called a "Software Vulnerability Detection Unit" (LVDU) integrated within an electronic component that is itself part of a Continuous Integration / Continuous Development (CI / CD) process, and more specifically, within IVVQ. The role of the electronic component, called a "Security Validation and Remediation Unit" (SUV), is to assess the exposure to software vulnerabilities in software artifacts, to escalate a decision to the IVVQ chain, and, optionally, to apply appropriate hardening measures to the final software (binaries, libraries).

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

[0169] - An electronic sub-component for vulnerability detection 402 performing the exposure calculation technique presented above;

[0170] - A 404 electronic decision sub-component taking into account the specific safety and security needs of the product via a configuration;

[0171] - A 406 electronic remediation sub-component 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).

[0172] One alternative use case is to loop by executing the decision unit after the detection unit by re-injecting the hardened software into the Software Vulnerability Detection Unit.

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

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

[0175] - At the end of the compilation;

[0176] - After the link editing;

[0177] - Following system integration.

[0178] At each of these stages, the checks and validations performed on the artifacts of these stages must be carried out after the security validation stage, because the latter can implement countermeasures which, by definition, have an impact on the software.

[0179] Decision unit 404 is an electronic component that takes the following input:

[0180] - a structured list of vulnerabilities; - a configuration.

[0181] The structured list of vulnerabilities describes:

[0182] - the prerequisites detected;

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

[0184] The configuration describes:

[0185] - the acceptable vulnerability threshold (dependent on the product's needs);

[0186] - the detection method (direct or incremental);

[0187] - operational safety requirements (which may limit applicable countermeasures).

[0188] 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 exploitability of families already detected in previous steps.

[0189] 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 execution by setting a specific error value in "errno" and displaying an explicit message.

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

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

[0192] A risk assessment method for an application against 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 a detailed understanding of the application's properties and the attacker's objectives, and by breaking with known approaches, the present invention offers the following advantages:

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

[0194] - 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 in execution even in verifiable cases), and a commonly adopted approach equating the ability to write to a register with complete control of the register;

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

[0196] 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:

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

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

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

Claims

DEMANDS 1. A method for evaluating the exposure of application binaries to code reuse attacks by an attacker having an objective chosen from the group of: targeting resources external to the application but accessible to it, corrupting memory accessible to the application, and executing third-party code, the method being implemented by computer and comprising steps consisting of: classify by prerequisite (102) a set of gadgets identified in the application code, a prerequisite defining instructions in the application's binary code allowing an attacker to perform certain actions; identify (104) a plurality of operand registers of prerequisites; construct (106) a list of target registers from among said operand registers; calculate (108) a value representing an attacker control level for each target register used as an operand of a prerequisite; calculate (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 objective exposure level for each attacker objective based on the exposure level of each prerequisite and a weight associated with each prerequisite; and calculate (114) an exposure score of the application binaries to code reuse attacks based on the exposure levels of the attacker's objectives.

2. A 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 during compilation, by a triplet defining a target register identity, a target register mode and a target register weight.

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

4. A method according to any one of the preceding claims, 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. A method according to any one of the preceding claims, 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. A method according to any one of the preceding claims, 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.

7. A method according to any one of the preceding claims, 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.

8. A method according to any one of the preceding claims, further comprising a step of displaying the results of the calculation steps on a display device.

9. 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 according to any of the preceding claims when the program is executed on a computer.

10. Device for evaluating the exposure of binaries of an application to code reuse attacks by an attacker having an objective selected from the group consisting of: targeting resources external to the application but accessible to it, corrupting the memory accessible to the application, and executing third-party code, the device comprising means for implementing the steps of the evaluation process of any one of claims 1 to 8.

11. Software vulnerability detection unit comprising a device according to claim 10.

12. Security validation and remediation unit comprising a software vulnerability detection unit according to claim 11.

Images