A method for detecting release-referencing vulnerability based on symbolic execution

Abstract

The application discloses a kind of release reference leak detection methods based on symbolic execution, including based on symbolic execution system, establish release reference leak detection strategy, obtain the criterion and basic method of detecting release reference leak;According to symbolic execution system, release reference leak detection algorithm is established;According to release reference leak detection algorithm, constraint solving is carried out, and whether the source program to be checked exists release reference leak is judged;If there is a solution that satisfies, the source program to be checked exists release reference leak, otherwise the source program to be checked does not exist release reference leak.The present application establishes the detection strategy of release reference leak based on symbolic execution system, so as to solve the constraint by first-order logic formula, judge whether there is satisfiability solution, realize the vulnerability detection in the use process of release reference leak.

Description

Technical Field

[0001] This invention relates to the field of vulnerability analysis and detection technology, and in particular to a method for detecting release-reference vulnerabilities based on symbolic execution. Background Technology

[0002] With the rapid development of software design technology, while bringing various conveniences, it has also led to a proliferation of vulnerabilities, which can cause network security problems. Therefore, we need to analyze the various vulnerabilities that have emerged. Software vulnerabilities include language vulnerabilities, logic vulnerabilities, and so on.

[0003] Symbolic execution is a formal program analysis method that uses operational semantics to describe symbols and execute symbolic programs. The operands of a symbolic execution system are symbols; it cannot execute statements in a programming language that describe the source program.

[0004] The shortcoming of existing technology is that current methods for exploiting the free-reuse vulnerability involve dynamically allocating heap space to store data using methods such as `new` or `malloc` during program writing, and then freeing it using `delete` or `free`. Generally, this approach does not cause any problems, but if the dangling pointer in the freed heap space is used again, it will create a security vulnerability, and the vulnerability cannot be detected in advance. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the existing technology. To achieve the above objective, a release-rereference vulnerability detection method based on symbolic execution is adopted to solve the problems mentioned in the background technology.

[0006] A method for detecting free-reuse vulnerabilities based on symbolic execution, comprising the following steps:

[0007] Step S1: Based on the symbolic execution system, establish a release rereference vulnerability detection strategy to obtain the criteria and basic methods for detecting release rereference vulnerabilities;

[0008] Step S2: Based on the symbolic execution system, establish a release-reference vulnerability detection algorithm;

[0009] Step S3: Solve the constraints according to the release-reuse vulnerability detection algorithm to determine whether the detected source program has a release-reuse vulnerability;

[0010] Step S4: If a satisfactory solution exists, the source program under inspection has a release-reuse vulnerability; otherwise, the source program under inspection does not have a release-reuse vulnerability.

[0011] As a further aspect of the present invention: the specific steps of the symbolic execution system in step S1 include:

[0012] Based on the symbolic execution system, the symbolic execution system includes a symbol set, a path language and its syntax system, and a symbolic translation rule set;

[0013] Based on the symbolic execution system and the principle of the release-rereference vulnerability, the operation and state changes of pointer variables are designed to obtain the correspondence between source program statements and path language.

[0014] The symbol translation rule set includes expression description methods based on operation semantics, expression translation rules, statement translation rules, and system function translation rules.

[0015] As a further aspect of the present invention, the specific steps for establishing the release-reuse vulnerability detection algorithm in step S2 include:

[0016] Based on the path language and syntax system of the symbolic execution system, the source program is converted into multiple path language programs by means of the path language correspondence.

[0017] Then, the statements in each path language are translated according to the symbol translation rule set to obtain the security constraints of the first-order logic representation;

[0018] The security constraints of the first-order logic representation are solved to determine whether there is a satisfyable solution to the security constraints. If there is no solution, it means there is no vulnerability and the path language program is traversed. If there is a solution to the security constraints, then there is a vulnerability.

[0019] Compared with the prior art, the present invention has the following technical advantages:

[0020] By adopting the above technical solution, a detection strategy for release-reference vulnerabilities is established based on a symbolic execution system. Constraints are solved by first-order logic formulas to determine whether there is a satisfiable solution, thereby realizing vulnerability detection during the use of release-reference vulnerabilities. Attached Figure Description

[0021] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings:

[0022] Figure 1 This is a schematic diagram illustrating the steps of a vulnerability detection method according to an embodiment of this application;

[0023] Figure 2 This is a flowchart illustrating the process of detecting a free-rereference vulnerability based on symbolic execution, as disclosed in this application.

[0024] Figure 3 This diagram illustrates the correspondence between the three state transitions and four operations of a pointer according to an embodiment disclosed in this application. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] Please refer to Figure 1 In this embodiment of the invention, a method for detecting release-rereference vulnerabilities based on symbolic execution includes the following steps:

[0027] Step S1: Based on the symbolic execution system, establish a release-reference vulnerability detection strategy, and obtain the criteria and basic methods for detecting release-reference vulnerabilities. Specific steps include:

[0028] Based on the symbolic execution system, the symbolic execution system includes a symbol set, a path language and its syntax system, and a symbolic translation rule set;

[0029] Based on the symbolic execution system and the principle of the release-rereference vulnerability, the operation and state changes of pointer variables are designed to obtain the correspondence between source program statements and path language.

[0030] The symbol translation rule set includes expression description methods based on operation semantics, expression translation rules, statement translation rules, and system function translation rules.

[0031] Step S2: Based on the symbolic execution system, establish a release-reference vulnerability detection algorithm;

[0032] Step S3: Solve the constraints according to the release-reuse vulnerability detection algorithm to determine whether the detected source program has a release-reuse vulnerability;

[0033] Step S4: If a satisfactory solution exists, the source program under inspection has a release-reuse vulnerability; otherwise, the source program under inspection does not have a release-reuse vulnerability.

[0034] In this embodiment, as Figure 2 As shown in the diagram, the process of detecting a release-reuse vulnerability based on symbolic execution is illustrated. The specific steps in step S2 of establishing the release-reuse vulnerability detection algorithm include:

[0035] Based on the path language and syntax system of the symbolic execution system, the source program is converted into multiple path language programs by means of the path language correspondence.

[0036] Then, the statements in each path language are translated according to the symbol translation rule set to obtain the security constraints of the first-order logic representation;

[0037] The security constraints of the first-order logic representation are solved to determine whether there is a satisfyable solution to the security constraints. If there is no solution, it means there is no vulnerability and the path language program is traversed. If there is a solution to the security constraints, then there is a vulnerability.

[0038] Example:

[0039] 1) Construct a symbolic execution system, VDUSEx, that can be used to detect release rereference vulnerabilities.

[0040] The symbolic execution system VDUSEx includes: a symbol set (containing a basic symbol set, an operator set, and a keyword set), a path language and its syntax system, and a symbol translation rule set.

[0041] 2) Establish a detection strategy for release rereference vulnerabilities.

[0042] By using the symbolic execution system VDUSEx, and based on the changes in pointer variable operations and states—namely, the relationships between pointer states and pointer operations, pointer states and variable tuples, and pointer operations and program statements—a release rereference vulnerability detection strategy is established, and the criteria and basic methods for detecting release rereference vulnerabilities are obtained.

[0043] 3) Establish a vulnerability detection process for freeing and rereferencing vulnerabilities based on symbolic execution.

[0044] By constructing the correspondence between source program statements and path languages, the expression description method based on operation semantics, and the symbol translation rules for expressions, statements, and system function calls, a release-rereference vulnerability detection process based on symbolic execution was established.

[0045] 4) Design an algorithm for detecting symbolic execution release and rereference vulnerabilities.

[0046] The path language conversion algorithm is used to obtain the path language program of the source program being tested. For each statement in the path language, the path language statements are translated according to symbolic translation rules. Variable objects are created, and symbolic translation of expressions, statements, and system function calls is performed to obtain the first-order logic formulas for path constraints and security constraints. The constraint solution of the conjunctive first-order logic formulas of the path constraints and security constraints can then be performed to determine whether the tested source program has a release-reference vulnerability. If the conjunctive first-order logic formula has a satisfyable solution, the tested source program has a release-reference vulnerability; otherwise, the tested source program does not have a release-reference vulnerability.

[0047] Detection strategy for release rereference vulnerability:

[0048] For a pointer p that has already been created, there are four operations and three states. The four operations are: associate with a certain address, use, release, and destroy; the three states are: pointing to a valid address space, dangling pointer, and pointing to NULL.

[0049] like Figure 3 As shown in the diagram, the correspondence between the three state transitions of a pointer and the four operations is illustrated.

[0050] Based on the principle behind the free-reuse vulnerability, using a pointer after it has become a dangling pointer will trigger a free-reuse vulnerability. Analysis shows that... Figure 3 The use and release operations corresponding to the return from the dangling pointer state to the dangling pointer state will cause a release-rereference vulnerability.

[0051] In this embodiment, we will first discuss the objects operated on in the symbolic translation rules. Unlike other symbolic execution systems that only focus on the values ​​of program variables (i.e., the objects of operation) using symbolic values ​​and their expressions, the symbolic execution system VDUSEx not only focuses on the values ​​of program variables (i.e., the objects of operation), but also on the attributes of the variable to be analyzed and its relationships with other variables, in order to facilitate the analysis of variable pointers and memory operations. Therefore, by extending the general symbolic execution system, for a program variable, in addition to the variable's value, we also need to consider the variable's attributes and its relationships with other variables. For example, for pointer variables, we need to focus on the size of the memory space pointed to by the pointer variable, and analyze the value of the pointer variable and the size of the memory space pointed to by the pointer variable.

[0052] Generally speaking, variables declared in a programming language source program are divided into three categories. We construct tuples corresponding to these three categories of variables, analyze the variable's value, attributes, and relationships with other variables according to their type, and then construct the attributes of the tuples. During symbolic translation, we operate on the analyzed tuples, not only processing the variable values ​​but also tracking the state of pointer variables and analyzing pointer variable memory operations.

[0053] Therefore, the symbolic execution system VDUSEx categorizes variables declared in a program into three types: pointer type, structure type, and basic data type. It analyzes the variable's value, attributes, and relationships with other variables according to the variable's type. For example, for pointer type variables, it analyzes the object the pointer type variable points to, the length of the memory space it points to, etc. The properties of the analyzed variables are constructed into the attributes of the variable tuple σ, which participates in symbolic translation.

[0054] 1) Pointer type: For variables of pointer and array type, a seven-tuple is used to represent them.

[0055]

[0056] 2) Structure type: For variables of structure, union, and enum types, a tuple is used.

[0057] σ s =<type, ptscope> (2)

[0058] 3) Basic data types: For other variables in the program that are not in the above two cases, a tuple is used to represent them.

[0059]

[0060] The constituent elements of a tuple of three types are called the attributes of the tuple:

[0061] a) The `type` attribute identifies the type of a variable, and its possible values ​​are:

[0062] type∈{Pointer, Struct, int, short, long, char, float, double}

[0063] b) The val attribute identifies the symbolic value of the variable. If it is a pointer type variable, it identifies the address that the pointer variable points to.

[0064] c) The size attribute indicates the size of the buffer that the pointer variable points to when it is allocated.

[0065] d) The length attribute indicates the actual size of the data stored in the buffer pointed to by the pointer.

[0066] e) The start attribute identifies the offset between a pointer position in the buffer and the starting position of the buffer.

[0067] f) The `pointto` property stores the tuple corresponding to the variable that the pointer points to.

[0068] g)ptscope is an attribute in pointer variables or structure variable tuples that points to the mapping from variable names (composed of array elements or structure member variables) to variable tuples.

[0069] According to equations (1) to (3) above, Figure 3 The corresponding pointer states are represented using variable tuples, and pointer operations are represented using program statements, thus obtaining the corresponding relationship:

[0070] 1) The correspondence between pointer states and pointer variable tuples

[0071]

[0072]

[0073]

[0074] 2) The correspondence between pointer operations and program statements. Let p be a pointer variable and n be an integer.

[0075] use Pointer usage statements, such as strcpy(p1, p2), &p, *p, etc.

[0076] Associated with a certain address Or a pointer assignment statement.

[0077]

[0078]

[0079] Based on the relationships between pointer state and pointer operation, pointer state and variable tuple, and pointer operation and program statement, it can be seen that for a pointer operation statement, the release rereference vulnerability can be detected by detecting the state changes of the relevant tuple before and after the statement execution.

[0080] For a pointer operation statement, let σ be the tuple corresponding to the pointer that existed in the statement before execution. p After execution, the tuple corresponding to the same pointer is σ′. p Then there is a release rereference vulnerability detection assertion:

[0081] If the pointer tuple σ is executed before the pointer manipulation statement is executed... p The `pointto` attribute is null, i.e., "σ". p ".pointto = null" records the val attribute σ of the pointer tuple at this time. p .val. After pointer manipulation statements are executed, the pointer tuple σ′ p The `pointto` attribute is still null, i.e., "σ′". p ".pointto = null", at this time the assertion "σ" is generated. p .val>0∧σ′ p If `val > 0` is used, and this is combined with the current path constraint, then if the first-order logical formula after the combination has a satisfyable solution, then the current statement has a release rereference vulnerability.

[0082] Symbolic execution-based free-reuse vulnerability detection algorithm:

[0083] Algorithm 1 for detecting free-reference vulnerabilities based on symbolic execution uses pointer variable object obj. p Represents the pointer tuple σ p .

[0084] Algorithm 1: Detect() algorithm for detecting release and rereference vulnerabilities

[0085] Algorithm principle: When translating a statement in each path language, if the statement contains a pointer, then a release and rereference vulnerability is detected for that statement.

[0086] Input: program statement, current symbol table, current path constraint ∏;

[0087] Output: Release rereference vulnerability detection result. If it exists, return "exist"; otherwise, return "nonexist".

[0088] Algorithm steps:

[0089] Step 1: If a pointer variable Vp exists in the statement, then retrieve the corresponding pointer object 0bj from the symbol table for each pointer variable. p ,Right now:

[0090] There is an unanalyzed pointer variable V in the while statement. p

[0091] Create a pointer-type data structure object obj p ;

[0092] The pointer variable Vp is symbolically translated using the function symExpr(), and the result is saved to the object obj. p middle;

[0093] end while

[0094] Step 2: Check the `pointto` property of each pointer object. If it satisfies "obj p If ".pointto = null", then the value of the pointer object and its val property will be obtained from obj. p Record the value using .val; otherwise, proceed to step 6.

[0095] Step 3: Use the function symStatement() to perform symbolic translation on the statement, i.e., symStatement(statement), to obtain the pointer object obj in the SymbolTable after symbolic execution. p ′;

[0096] Step 4: For the pointer object obj of the record p The `.pointto` property continues the check; if it satisfies "obj pIf '.pointto = null', then the safety constraint "obj" will be generated. p .val>0∧obj p If '.val>0” is combined with the current path constraint ∏, a new path constraint ∏′ is obtained; otherwise, proceed to step 6).

[0097] Step 5: Apply the path constraint ∏′=∏∧obj obtained in Step 4. p .val>0∧obj p If '.val > 0, perform a satisfiability check and call the constraint solving algorithm Solver():

[0098] 5.1) By substituting propositional variables for each constraint in the first-order logic formula ∏′, we obtain the Boolean satisfiability formula;

[0099] 5.2) Use the DPLL algorithm to solve the Boolean satisfiability formula. If the Boolean satisfiability formula has no satisfiable solution, then the formula ∏′ has no satisfiable solution; otherwise, an assignment model of the Boolean satisfiability formula can be obtained.

[0100] 5.3) Transform the propositional variables back into the corresponding constraints, and combine them with the assignment model to determine whether there are any satisfiable values ​​that make each constraint hold under the conditions of the assignment model. If such a satisfiable value exists, it means that the formula ∏′ has a satisfiable solution. Otherwise, construct a theoretical conflict clause under the current assignment conditions, add it to the Boolean satisfiability formula, and repeat the above process until it is determined whether the formula ∏′ is satisfiable.

[0101] 5.4) If the formula ∏′ has a satisfyable solution, it can be determined that there is a release rereference vulnerability at the current statement, and return to exist; otherwise, proceed to Step 6.

[0102] Step 6: Determine if there is no vulnerability to release and rereference, and return nonexist;

[0103] The time complexity of Algorithm 1 depends on steps Step 1, Step 2, and Step 5. The number of loops executed in Step 1 and Step 2 depends on the number of pointer variables in the statement, and the number of loops executed in Step 5 depends on the number of times the algorithm checks whether the formula ∏′ is satisfyable. Assuming there are n1 pointer variables in the statement, Step 2 needs to check these n1 pointer variables. Furthermore, assuming the algorithm checks n2 times in Step 5, let n = max{n1, n2}, then the time complexity of Algorithm 1 is O(n).

[0104] The process of detecting free-reuse vulnerabilities based on symbolic execution:

[0105] To achieve release-rereference vulnerability detection based on symbolic execution, we must first solve problems such as the mapping relationship between source program statements and path language, constructing an expression description method based on operation semantics, and symbolic translation rules for expressions, statements, and system function calls.

[0106] In this embodiment, the correspondence between source program statements and path languages ​​is shown in Table 1 below:

[0107] Table 1. Mapping between source program statements and path language

[0108]

[0109] The expression description based on operation semantics is shown in Table 2 below:

[0110] Table 2. Expression description methods based on operation semantics

[0111]

[0112] The symbol translation rules for expressions, statements, and system function calls are shown in Tables 3, 4, and 5 below:

[0113] Translation rules for expressions in Table 3

[0114]

[0115] Table 4 Translation Rules

[0116]

[0117] Table 5 System Function Translation Rules

[0118] malloc function call MALLOC The symbol translation rules for the system function malloc() free function call FREE The symbol translation rules for the system function free() strlen function call STRLEN The symbol translation rules for the system function strlen() strcpy function call STRCPY Describes the symbol translation rules for the system function strcpy()

[0119] The detection process for free-reuse vulnerabilities based on symbolic execution consists of three stages:

[0120] Phase 1: Based on the source program described in Table 1, perform path language conversion through the path language correspondence to convert the source program into multiple path language programs;

[0121] Phase 2: For a path language statement, based on the machine state represented by operation semantics in Table 2, it is converted from the numeric domain to the symbolic domain, including the changes in machine state and the operations required to cause these changes. The path language program performs symbolic translation using the symbolic translation rules described in Tables 3, 4, and 5. The essence of these symbolic translation rules is the abstract semantics of various statements in the corresponding path language program. Specifically:

[0122] 2.1) For selection statements in path language, symbolic translation will generate path constraints based on the judgment conditions. Path constraints describe the conditions that variables in the program should satisfy when the program executes the current path.

[0123] 2.2) When symbolically translating security-sensitive statements related to release-reuse vulnerabilities in path languages, it is necessary to combine the release-reuse vulnerability detection algorithm Detect() based on symbolic execution described in Algorithm 1 to generate security constraints using first-order logic representation. The security constraints describe the conditions that variables in the program should satisfy when the program can trigger the release-reuse vulnerability.

[0124] Phase 3: If security constraints represented by first-order logic were generated in Phase 2, they need to be solved. The process of solving the constraints mainly involves determining whether there is a satisfiable solution for the security constraints. If not, it means there is no vulnerability, and the path language program continues to be traversed. If there is a solution for the security constraints, then there is a vulnerability, and the existence of the vulnerability is reported.

[0125] like Figure 2 The diagram illustrates the detection process for a free-reuse vulnerability based on symbolic execution.

[0126] Algorithm 2: Symbolic Execution-based Free-Reference Vulnerability Detection Algorithm (SymbolicExecution())

[0127] Algorithm principle: Convert the source program into a path language program, perform symbolic translation on the path language program, solve the security constraints obtained from the symbolic translation, and determine whether a vulnerability exists.

[0128] Input: Source code file;

[0129] Output: A report on whether vulnerabilities exist in the source code;

[0130] Algorithm steps:

[0131] Step 1: Use the Transform() path language conversion algorithm to convert the source program into a path language program;

[0132] Step 2: If not all path language programs have been analyzed, take out one path language program and translate it.

[0133] Step 3: If the path language program has finished traversing, return to Step 2; otherwise, extract a statement from the path language program.

[0134] Step 4: Perform symbolic translation on the path language statements extracted in Step 3:

[0135] 4.1) If the statement is a selection statement, a path constraint is generated; otherwise, proceed to 4.2).

[0136] 4.2) If the statement is a security-sensitive statement, combine it with the release-reference vulnerability detection algorithm to generate security constraints and proceed to Step 5; otherwise, proceed to Step 3.

[0137] Step 5: Use the constraint solving algorithm Solver() to solve the security constraints. If there is a satisfyable solution, it is determined that there is a vulnerability and a report is generated; otherwise, go back to Step 3.

[0138] Step 6: If the path language program has been completely analyzed and symbol execution has ended, return;

[0139] The time complexity of Algorithm 2 depends on Steps 2 through 5. For a single path language program, the number of loop executions depends on the number of statements n′ in the file. Therefore, for a single path language program, the time complexity of Algorithm 2 is O(n′). Let there be m path language programs in total, and let the number of statements in each program be n1, n2, ..., n. m Let n = n1 + n2 + ... + n m Where n means that there are a total of n statements in the m path language programs, the time complexity of Algorithm 2 is O(n).

[0140] Example of detecting a free-reuse vulnerability based on symbolic execution:

[0141] This paper illustrates a symbolic execution-based method for detecting release-reference vulnerabilities using an example. The process involves converting the source program file into a path language program, translating the path language program into symbols, generating security constraints at security-sensitive statements, solving the constraints, and finally determining that the source program has a release-reference vulnerability.

[0142] Example 1: Detection process for a free-reuse vulnerability based on symbolic execution

[0143]

[0144]

[0145] In Example 1, line 10 is a branch statement. Depending on the branch selected, the source program of Example 1 can be converted into two path language programs. These two path language programs each select one branch of the branch statement for conversion. If the branch with the condition being true is selected for conversion, it is marked with the @true keyword; otherwise, it is marked with the @false keyword.

[0146] The source program is converted into two path language programs using a path language conversion algorithm:

[0147]

[0148] Symbolic translation of path language program 1:

[0149] Step 1: The first line of the path language program 1 is a marker "@enter main", indicating that the program enters the main function for execution. According to the ENTERSTATEMENT rules, the system enters the scope of the main function for symbolic execution. At this time, the actual parameter stack is empty, so it can directly enter the scope of the main function.

[0150] Step 2: The second line of Path Language Program 1 is an assignment statement. According to the statement symbol translation rule ASSIGN, after symbol translation of this statement, the machine state changes:

[0151] The machine state Δ changes to Δ′, which is obtained by calculating Δ′=Δ[σ1←σ2], where the tuple σ1 is symbolically translated from the expression on the left-hand side of the assignment operator. The expression on the left-hand side of the assignment operator is a pointer variable `buf`. Using the expression symbol translation rule (VAR), we know that:

[0152]

[0153] The system finds the pointer type tuple σ1 corresponding to the buf variable in the symbol table. At this point, σ1 is its initial value, and we have:

[0154] σ1=Δ(buf)=<Pointer, 0, 0, 0, 0, null, null> (2)

[0155] Here, rand0 is the symbolic value. The tuple σ2 is symbolically translated from the expression on the right-hand side of the assignment operator. The assignment operator results in a call to the system function malloc() on the right-hand side. According to the MALLOC rules:

[0156]

[0157] Here, rand1, rand2, and rand3 are sign values. Therefore:

[0158] σ2=<Pointer, rand1, 10, rand2, 0, <int, rand3>, null> (4)

[0159] Perform the calculation Δ′=Δ[σ1←σ2], update the tuple σ1 in the symbol table Δ with the tuple σ2, and after the update, in the new symbol table Δ′, we have:

[0160] Δ′(buf)=<Pointer, rand1, 10, rand2, 0, <int, rand3>, null> (5)

[0161] For the tuple Δ′(buf), the condition “pointto=null” is not satisfied, so there is no vulnerability to release and rereference.

[0162] Step 3: The third line of Path Language Program 1 is an input statement, so we directly assign a value to the `des` object:

[0163]

[0164] Among them, rand4, rand_length, and rand5 are symbolic values.

[0165] Step 4: The fourth line of Path Language Program 1 is a system function call statement of the form "expr1 = strlen(expr2)". According to the system function translation rule STRLEN, after symbolic translation of this statement, the machine state changes:

[0166] The machine state Δ changes to Δ′, which is obtained by calculating Δ′ = Δ[σ1←<int, σ2.length>]. Here, the tuple σ1 is obtained by symbolically translating the expression on the left-hand side of the assignment operator. The expression on the left-hand side of the assignment operator is an integer variable tmp. Using the symbolic translation rule VAR, we know that:

[0167]

[0168] The system finds the pointer type tuple σ1 corresponding to the tmp variable in the symbol table. At this point, σ1 is its initial value, and we have:

[0169] σ1=Δ(tmp)=<int, rand6> (8)

[0170] Here, rand6 is the symbolic value. The tuple σ2 is symbolically translated from the expression. The result is that, where the expression expr2 is the variable des, we have: σ2.length = rand_length. We then perform the calculation Δ′ = Δ[σ1←<int, σ2.length>], updating the tuple σ1 in the symbol table Δ using the tuple <int, σ2.length>. After the update, in the new symbol table Δ′, we have:

[0171] Δ′(tmp)=<iht, rand_length> (9)

[0172] The machine state ∏ changes to ∏′, which is obtained by calculating ∏∧(σ2.length>0), where σ2.length=rand_length. Therefore, we have: ∏′=σ2.length>0=rand_length>0.

[0173] Step 5: The fifth line of path language program 1 is a call to the system function `free()`. According to the translation rule `FREE` for the system function `free()`, after symbolic translation of this statement, the machine state changes:

[0174] The machine state Δ changes to Δ′, and Δ′ is calculated as follows:

[0175] Δ′=Δ[σ←<Pointer, σ.val, 0, 0, σ.start, null, σ.ptscope>] (10)

[0176] And thus obtained.

[0177] Here, tuple σ is obtained by symbolically translating the expression buf. Using the symbolic translation rule VAR to symbolically translate the expression buf, we can see that:

[0178]

[0179] The possible values ​​of tuple σ can be obtained as follows:

[0180] σ=Δ(buf)=<Pointer, rand1, 10, rand2, 0, <int, rand3>, null> (12)

[0181] Perform the calculation:

[0182] Δ′=Δ[σ←<Pointer, rand1, 0, 0, 0, null, null>] (13)

[0183] After the update is complete, in the new symbol table Δ′, we have:

[0184] Δ′(buf)=<Pointer, rand1, 0, 0, 0, null, null> (14)

[0185] For the tuple Δ(buf), the condition "pointto = null" is not satisfied, so there is no vulnerability to release and rereference.

[0186] Step 6: The sixth line of Path Language Program 1 is a conditional selection statement, and Path Language Program 1 corresponds to the branch where the selection condition is true.

[0187] According to the TRUECOND translation rule, after the symbolic translation of this statement, the machine state changes:

[0188] The machine state ∏ changes to ∏′, which is obtained by calculating ∏′=∏∧σ.val, where the tuple σ is obtained by symbolically translating the expression tmp>1. This expression is a binary operation expression, which can be translated using the BINARY_OP rule to obtain:

[0189]

[0190] Therefore, we know that the value of tuple σ is:

[0191] σ=<int,rand_length>1> (16)

[0192] The path constraint at this point is:

[0193] ∏′=Π∧σ.val=rand_length>0∧rand_length>1 (17)

[0194] Step 7: The seventh line of Path Language Program 1 is an assignment statement. According to the symbol translation rule ASSIGN, after symbol translation of this statement, the machine state changes:

[0195] The machine state Δ changes to Δ′, which is obtained by calculating Δ′=Δ[σ1←σ2], where the tuple σ1 is symbolically translated from the expression on the left-hand side of the assignment operator. The expression on the left-hand side of the assignment operator is a pointer variable `buf`. Using the expression symbol translation rule (VAR), we know that:

[0196]

[0197] The system finds the pointer type tuple σ1 corresponding to the buf variable in the symbol table. At this point, σ1 is its initial value, and we have:

[0198] σ1=Δ(buf)=<Pointer, rand1, 0, 0, 0, null, null> (19)

[0199] Here, rand1 is the symbolic value. The tuple σ2 is symbolically translated from the expression on the right-hand side of the assignment operator. The result is that the right-hand side of the assignment operator is NULL. According to the rules of NULL translation, we know that:

[0200] σ2=<Pointer, 0, 0, 0, 0, null, null> (20)

[0201] Perform the calculation Δ′=Δ[σ1←σ2], update the tuple σ1 in the symbol table Δ with the tuple σ2, and after the update, in the new symbol table Δ′, we have:

[0202] Δ′(buf)=<Pointer, 0, 0, 0, 0, null, null> (21)

[0203] For the tuple Δ′(bur), the condition “pointto=null” is not satisfied, so there is no vulnerability to release and rereference.

[0204] Step 8: Line 8 of the path language program 1 is a call to the system function strcpy. According to the symbolic translation rules of STRPY, after symbolic translation of this statement, the machine state changes:

[0205] The machine state Δ changes to Δ′, and Δ′ is calculated.

[0206]

[0207] Sure.

[0208] Here, tuple σ1 is obtained by symbolically translating the expression buf, and we know from the symbolic translation rule VAR that:

[0209]

[0210] The system finds the tuple σ1 of pointer type corresponding to the buf variable in the symbol table, and has:

[0211] σ1=Δ(buf)=<Pointer, 0, 0, 0, 0, null, null> (24)

[0212] The tuple σ² is obtained by symbolically translating the expression des. Using the symbolic translation rule VAR, we know that:

[0213]

[0214] The system finds the tuple σ2 of pointer type corresponding to the variable des in the symbol table, and has:

[0215]

[0216] Perform the calculation:

[0217] Δ′=Δ[σ1←<Pointer, 0, 0, rand_length, 0, null, null>] (27)

[0218] In the new symbol table Δ′, we have:

[0219] Δ′(buf)=<Pointer, 0, 0, rand_length, 0, null, null> (28)

[0220] For tuples Δ(buf) and Δ′(buf), the condition “pointto=null” is satisfied. Therefore, the detection algorithm Detect() for the release-reference vulnerability described by Algorithm 1 has the following:

[0221] ∏′=∏∧0>0∧0>0=false

[0222] At this point, ∏ = rand_length > 1, therefore:

[0223] ∏′=rand_length>0∧rand_length>1∧0>0∧0>0=false

[0224] We need to determine whether ∏′ holds true given that rand_length is an integer. We need to check if a solution exists that makes ∏′ true to determine if there is a vulnerability in the program that allows for the release and rereferencing of data.

[0225] The satisfiability of the first-order logic formula ∏′ is solved using the constraint solving algorithm Solver():

[0226] Using propositional variable p to replace the constraint rand_length>1, propositional variable q to replace the constraint 0>0, propositional variable r to replace the constraint 0>0, and propositional variable s to replace the constraint rand_length>0, we obtain the Boolean satisfiability formula p∧q∧r∧s. Solving for its satisfiability, we have the assignment model M: {p→true, q→true, r→true, s→true}. Substituting the values ​​of propositions p, q, r, and s into the constraints rand_length>1, 0>0, 0>0, and rand_length>0, we know that there is no integer value of rand_length that can make the first-order logic formula ∏′ true. Therefore, there is no release rereference vulnerability on the branch path represented by path language program 1.

[0227] Step 9: The ninth line of Path Language Program 1 is a "@return" statement. According to the symbol translation RETURN rule, the path pointer stack is empty at this time, and there is no saved symbol table in the scope. At this time, the current scope is exited directly.

[0228] Symbolic translation is performed on path language program 2. The first five lines of path language program 2 are the same as those of path language program 1. Using the results of Steps 1 to 5 in path language program 1, symbolic translation starts directly from the sixth line of path language program 2:

[0229] Step 1: The sixth line of Path Language Program 2 is a conditional selection statement, and Path Language Program 1 corresponds to the branch where the selection condition is false.

[0230] According to the FALSECOND symbolic translation rule, after symbolic translation of this statement, the machine state changes:

[0231] The machine state ∏ changes to ∏′, and ∏′ is calculated. We obtain the tuple σ, which is obtained by symbolically translating the expression tmp > 1. This expression is a binary operation expression, and its translation using the BINARY_OP rule yields the following:

[0232]

[0233] We know that the value of tuple σ can be:

[0234] σ=<int,rand_length>1> (30)

[0235] The path constraint at this point is:

[0236]

[0237] Step 2: Line 7 of Path Language Program 2 is a call to the system function strcpy. According to the STRPY symbolic translation rules, after symbolic translation of this statement, the machine state changes:

[0238] The machine state Δ changes to Δ′, and Δ′ is calculated.

[0239]

[0240] Sure.

[0241] Here, tuple σ1 is obtained by symbolically translating the expression buf, and we know from the symbolic translation rule VAR that:

[0242]

[0243] The system finds the tuple σ1 of pointer type corresponding to the buf variable in the symbol table, and has:

[0244] σ1=Δ(buf)=<Pointer, rand1, 0, 0, 0, null, null> (34)

[0245] The tuple σ² is obtained by symbolically translating the expression des. Using the symbolic translation rule VAR, we know that:

[0246]

[0247] The system finds the tuple σ2 of pointer type corresponding to the variable des in the symbol table, and has:

[0248]

[0249] Perform the calculation:

[0250] Δ′=Δ[σ1←<Pointer, rand1, 0, rand_length, 0, null, null>] (37)

[0251] In the new symbol table Δ′, we have:

[0252] Δ′(buf)=<Pointer, rand1, 0, rand_length, 0, null, null> (38)

[0253] For tuples Δ(buf) and tuple Δ′(buf), the condition “pointto=nul1” is satisfied. Therefore, the detection algorithm Detect() for the release rereference vulnerability described by Algorithm 1 has the following:

[0254] ∏′=∏∧rand1>0∧rand1>0 (39)

[0255] At this point, ∏ = rand_length > 5, therefore:

[0256] ∏′=rand_length>0∧rand_length≤1∧rand1>0∧rand1>0 (40)

[0257] Equation (40) indicates that ∏′ holds true when both rand_length and rand1 are integers. We now need to determine if there is a release-reference vulnerability in the program by checking if a solution exists that makes ∏′ true.

[0258] The satisfiability of the first-order logic formula ∏′ is solved using the constraint solving algorithm Solver():

[0259] Using propositional variable n to replace the constraint rand_length>0, propositional variable ρ to replace the constraint rand_length≤1, propositional variable q to replace the constraint rand1>0, and propositional variable r to replace the constraint rand1>0, we obtain the Boolean satisfiability formula n∧p∧q∧r. Solving its satisfiability yields the assignment model M: {n→true, p→true, q→true, r→true}. Substituting the values ​​of propositions n, p, q, and r into the constraints rand_length>0, rand_length≤1, rand1>0, and rand1>0, we find that there exist integer values ​​for rand_length and rand1 such that the constraints rand_length>0, rand_length≤1, rand1>0, and rand1>0 are all true (e.g., rand_length=1 and rand1=2). Therefore, the first-order logic formula ∏′ is satisfiable, and a release-rereference vulnerability exists on the current branch path.

[0260] Step 3: The eighth line of Path Language Program 2 is a "@return" statement. According to the RETURN rule of public symbol translation, since the path pointer stack is empty at this time, there is no saved symbol table in the scope. At this time, we can directly exit the current scope.

[0261] At this point, the path language program has been completely traversed, and symbolic translation is complete. Symbolic execution of the path language program revealed that path language program 1 does not have a free-reuse vulnerability, while path language program 2 does. This indicates that the path in the source program corresponding to path language program 2 contains a free-reuse vulnerability.

[0262] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention. The scope of the invention is defined by the appended claims and their equivalents, all of which should be included within the scope of protection of the invention.

Claims

1. A method for detecting release-rereference vulnerabilities based on symbolic execution, characterized in that, The specific steps include: Step S1: Based on the symbolic execution system, establish a release rereference vulnerability detection strategy to obtain the criteria and basic methods for detecting release rereference vulnerabilities; Step S2: Based on the symbolic execution system, establish a release-rereference vulnerability detection algorithm, the specific steps of which include: Based on the path language and syntax system of the symbolic execution system, the source program is converted into multiple path language programs by means of the path language correspondence. Then, the statements in each path language are translated according to the symbol translation rule set to obtain the security constraints of the first-order logic representation; The security constraints of the first-order logic representation are solved to determine whether there is a satisfiable solution to the security constraints. If there is no solution, it means there is no vulnerability and the path language program is traversed. If there is a solution to the security constraints, then there is a vulnerability. Step S3: Solve the constraints according to the release-reuse vulnerability detection algorithm to determine whether the detected source program has a release-reuse vulnerability; Step S4: If a satisfactory solution exists, the source program under inspection has a release-reuse vulnerability; otherwise, the source program under inspection does not have a release-reuse vulnerability.

2. The method for detecting release-rereference vulnerabilities based on symbolic execution according to claim 1, characterized in that, The specific steps in step S1 based on the symbolic execution system include: Based on the symbolic execution system, the symbolic execution system includes a symbol set, a path language and its syntax system, and a symbolic translation rule set; Based on the symbolic execution system and the principle of the release-rereference vulnerability, the operation and state changes of pointer variables are designed to obtain the correspondence between source program statements and path language. The symbol translation rule set includes expression description methods based on operation semantics, expression translation rules, statement translation rules, and system function translation rules.

Images