A method and device for screening target program defect reports

Abstract

The present invention discloses a method and device for screening defect reports of a target program, wherein the method comprises: obtaining a defect report of a target program, determining a defect starting position, a program instruction that triggers a defect, and defects in the target program indicated by the defect report according to the defect report; using symbolic execution and static analysis to analyze the path to be searched from the defect starting position to the program instruction that triggers the defect, and judging whether there is a vulnerable path that meets the triggering condition of the defect between the defect starting position and the program instruction that triggers the defect; if there is no vulnerable path between the defect starting position and the program instruction that triggers the defect, then judging the defect report as a false positive. By implementing the present invention, it is possible to quickly judge whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, thereby quickly completing the screening of defect reports, and users can obtain real defects in the target program from the screened defect report.

Description

Technical Field

[0001] The present invention relates to the technical field of software defect detection, and in particular to a method and device for screening target program defect reports. Background Art

[0002] Static analysis tools are widely used in software defect detection. There are currently many commercial and open source tools that use a variety of approximation and abstraction techniques to efficiently analyze defects in large-scale software. However, when using static analysis tools to detect software, there are a large number of false positives, making it difficult for users to quickly obtain useful information from defect reports. Summary of the invention

[0003] Therefore, the technical problem to be solved by the present invention is to overcome the defect of a large number of false positives when detecting software through static analysis tools in the prior art, thereby providing a method for screening target program defect reports.

[0004] A first aspect of the present invention provides a method for screening defect reports of a target program, comprising: obtaining a defect report of the target program, determining a defect starting position, a program instruction that triggers a defect, and defects in the target program indicated in the defect report based on the defect report; using symbolic execution and static analysis to analyze a path to be searched from the defect starting position to the program instruction that triggers the defect, and determining whether there is a vulnerable path that meets the triggering condition of the defect between the defect starting position and the program instruction that triggers the defect, and there are one or more paths to be searched from the defect starting position to the program instruction that triggers the defect in the target program; if there is no vulnerable path between the defect starting position and the program instruction that triggers the defect, the defect report is determined to be a false alarm.

[0005] Optionally, in the target program defect report screening method provided by the present invention, symbolic execution and static analysis are used to analyze the path to be searched from the defect starting position to the program instruction that triggers the defect, and determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, including: traversing each program instruction in the path to be searched respectively, and updating the symbolic state of the path to be searched according to the symbolic execution result or static analysis result of each program instruction in the path to be searched; determining whether the path to be searched meets the triggering condition of the defect according to the symbolic state of the path to be searched; if the path to be searched meets the triggering condition, determining that there is a vulnerable path between the defect starting position and the program instruction that triggers the defect.

[0006] Optionally, in the target program defect report screening method provided by the present invention, if a to-be-searched path satisfying the trigger condition is not detected within a preset time period, it is determined that there is no vulnerable path between the defect start position and the program instruction that triggers the defect.

[0007] Optionally, in the target program defect report screening method provided by the present invention, the program instructions in the path to be searched are traversed, and the symbolic state of the path to be searched is updated according to the symbolic execution results or static analysis results of each program instruction in the path to be searched, including: performing static analysis on each program instruction in the target program, converting the target program into a memory static single assignment form, and constructing a value flow graph based on the target program converted into a memory static single assignment form; taking the defect starting position as the starting point, traversing each program instruction in the path to be searched, and judging whether the current program instruction meets the skip condition according to the value flow graph; if the current program instruction meets the skip condition, updating the symbolic state according to the static analysis result of the current program instruction.

[0008] Optionally, the target program defect report screening method provided by the present invention further includes, if the current program instruction does not satisfy the skip condition, updating the symbol status according to the symbolic execution result of the current program instruction.

[0009] Optionally, in the target program defect report screening method provided by the present invention, before the step of determining whether the current program instruction satisfies the skip condition according to the value flow graph, it also includes: if the distance from the defect starting position to the current program instruction is less than or equal to the maximum search path length, executing the step of determining whether the current program instruction satisfies the skip condition according to the value flow graph; if the current program instruction satisfies the skip condition and the static analysis result of the current program instruction is consistent with the attribute of the current symbolic state of the path to be searched, then updating the symbolic state according to the static analysis result of the current program instruction; if the distance from the defect starting position to the current program instruction is greater than the maximum search path length, determining that the path to be searched does not satisfy the trigger condition of the defect.

[0010] Optionally, in the target program defect report screening method provided by the present invention, after the step of determining the defect starting position, the defect triggering program instructions, and the defect existing in the target program indicated by the defect report according to the defect report, before the step of using symbolic execution and static analysis to analyze the path to be searched from the defect starting position to the defect triggering program instructions, it also includes: deleting program instructions in the target program that have no data dependency and control dependency on the defect starting position, the defect triggering program instructions, and the path to be searched, to form a simplified target program.

[0011] The second aspect of the present invention provides a target program defect report screening device, including: a defect report acquisition module, used to obtain a defect report of the target program, determine the defect starting position, the defect triggering program instruction, and the defect in the target program indicated by the defect report based on the defect report; a path search module, used to use symbolic execution and static analysis to analyze the path to be searched from the defect starting position to the defect triggering program instruction, and determine whether there is a vulnerable path between the defect starting position and the defect triggering program instruction, and there are one or more paths to be searched from the defect starting position to the defect triggering program instruction in the target program; a defect report screening module, if there is no vulnerable path that meets the triggering condition of the defect between the defect starting position and the defect triggering program instruction, the defect report screening module is used to determine that the defect report is a false alarm.

[0012] The third aspect of the present invention provides a computer device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor, thereby executing the target program defect report screening method provided in the first aspect of the present invention.

[0013] A fourth aspect of the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the target program defect report screening method provided in the first aspect of the present invention.

[0014] The technical solution of the present invention has the following advantages:

[0015] The present invention provides a method and device for screening defect reports of a target program. After obtaining a defect report of a target program, a path to be searched between a defect starting position and a program instruction that triggers a defect is analyzed, and it is determined whether there is a vulnerable path in the path to be searched. If there is no vulnerable path, the defect report is determined to be a false positive, thereby achieving screening of defect reports. A user can quickly obtain real defect information existing in the target program from the screened defect report. Furthermore, if the path to be searched is analyzed only by symbolic execution, it is necessary to use symbolic execution to search all program instructions in the path to be searched, so as to determine whether the path to be searched is a vulnerable path. In the method and device for screening defect reports of a target program provided by the present invention, when analyzing the path to be searched between a defect starting position and a program instruction that triggers a defect in combination with symbolic execution and static analysis, some program instructions can be skipped based on the static analysis results. That is, by implementing the present invention, it is not necessary to use symbolic execution to search all program instructions in the path to be searched, thereby improving the analysis efficiency of the path to be searched. Based on the above analysis, by implementing the present invention, it is possible to quickly determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, thereby quickly completing the screening of defect reports for the target program, and the user can obtain the real defects of the target program from the screened defect reports. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0017] Figure 1 A flowchart of a target program defect report screening method provided by an embodiment of the present invention;

[0018] Figure 2 The target program provided in the embodiment of the present invention;

[0019] Figure 3 The target program converted into Memory-SSA form in the embodiment of the present invention;

[0020] Figure 4 The LLVM instruction set provided in the embodiment of the present invention;

[0021] Figure 5 are standard rules and instructions for entering μ and χ in the embodiment of the present invention;

[0022] Figure 6 A value flow graph constructed for a target program in an embodiment of the present invention;

[0023] Figure 7 Value stream related rules used to construct a value stream graph in an embodiment of the present invention;

[0024] Figure 8 The value stream aggregation rules used to construct the value stream graph in the embodiment of the present invention;

[0025] Fig. 9 is the symbol state in the embodiment of the present invention;

[0026] Fig.10 It is the standard semantic rule when symbolically executing instructions in the embodiment of the present invention;

[0027] Fig.11 corresponding rules used when updating the symbol status according to the static analysis results in the embodiment of the present invention;

[0028] Fig.12 These are all the paths to be searched that are analyzed when screening defect reports in an embodiment of the present invention;

[0029] Fig.13 21 real open source applications for evaluating the target program defect report screening method in the embodiment of the present invention;

[0030] Fig.14 The experimental results of the Juliet test suite in the embodiment of the present invention;

[0031] Fig.15 The experimental results of 21 real applications in the embodiments of the present invention are as follows;

[0032] FIG. 16( a ) is a result of tracking potential “use after free” vulnerabilities under different time limits in an embodiment of the present invention;

[0033] FIG. 16( b ) is a result of tracking a potential “null pointer dereference” vulnerability under different time limits in an embodiment of the present invention;

[0034] FIG. 16( c ) shows the impact of different strategies on defect report screening when tracking potential “use after free” vulnerabilities in an embodiment of the present invention;

[0035] FIG. 16( d ) shows the impact of different strategies on defect report screening when tracking potential “null pointer dereference” vulnerabilities in an embodiment of the present invention.

[0036] Fig.17 A structural block diagram of a target program defect report screening device provided by an embodiment of the present invention;

[0037] Fig.18 A structural block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0038] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0039] The embodiment of the present invention provides a method for screening target program defect reports, such as Figure 1 As shown, including:

[0040] Step S10: Obtain a defect report of the target program, and determine the defect start position, the instruction that triggers the defect program, and the defect in the target program indicated by the defect report according to the defect report.

[0041] In an optional embodiment, the target program is composed of a large number of program instructions, and a static analysis tool can be used to detect the target program to obtain a defect report of the target program.

[0042] In an optional embodiment, after the target program instructions are detected, multiple defect reports are usually obtained, each defect report is composed of<Source,Sink,{Steps}> The source represents the starting position of the defect, the sink represents the program instruction that triggers the defect, and {steps} represents a set of key path points from the starting position of the defect to the program instruction that triggers the defect. Through the information in the defect report, we can further extract the "step-by-step" path that is likely to trigger the reported defect, that is, the path to be searched.

[0043] Step S20: Use symbolic execution and static analysis to analyze the path to be searched from the defect starting position to the program instruction that triggers the defect, and determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect that meets the triggering condition of the defect. There are one or more paths to be searched from the defect starting position to the program instruction that triggers the defect in the target program.

[0044] In an optional embodiment, symbolic execution technology will systematically check each path, which is prone to path explosion problems. In the embodiment of the present invention, a method combining symbolic execution and static analysis is used to analyze the search path, and certain program instructions are selectively skipped based on the static analysis results. There is no need to check each path through symbolic execution technology, thereby improving the analysis efficiency of the search path.

[0045] If there is no vulnerable path between the defect starting position and the program instruction that triggers the defect, the defect report is determined to be a false alarm; if there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, the defect report is determined to be a true report.

[0046] In an optional embodiment, different types of defects have corresponding trigger conditions. Only when the trigger conditions are met during the execution of program instructions, the target program is considered to have the defect. Therefore, when judging whether a defect report is a false alarm, it is judged whether there is a search path between the defect starting position and the program instruction that triggers the defect that meets the trigger conditions. If so, the defect report is judged to be a true report. If not, the defect report is judged to be a false alarm.

[0047] In an optional embodiment, there are multiple paths to be searched between the defect starting position and the program instruction that triggers the defect. When determining whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, each path to be searched is detected in turn. When one path to be searched is detected as a vulnerable path, the detection of other paths to be searched is stopped, and it is determined that the defect report is not a false alarm.

[0048] In an optional embodiment, when there are many paths to be searched between the defect starting position and the program instruction that triggers the defect, if all the paths to be searched are analyzed, the problem of long analysis time is likely to occur. Therefore, when no vulnerable path is detected within the preset time length, it is determined that there is no vulnerable path between the defect starting position and the program instruction that triggers the defect, and the defect report is a false alarm. In an optional embodiment, the preset time length can be 5s, 10s, 50s, 100s, etc.

[0049] An embodiment of the present invention provides a method for screening defect reports of a target program. After obtaining a defect report of a target program, a path to be searched between a defect starting position and a program instruction that triggers a defect is analyzed, and it is determined whether there is a vulnerable path in the path to be searched. If there is no vulnerable path, the defect report is determined to be a false positive, thereby implementing screening of defect reports. A user can quickly obtain real defect information existing in the target program from the screened defect report. Furthermore, if the path to be searched is analyzed only by symbolic execution, it is necessary to use symbolic execution to search all program instructions in the path to be searched, so as to determine whether the path to be searched is a vulnerable path. In the method for screening defect reports of a target program provided by an embodiment of the present invention, when analyzing the path to be searched between a defect starting position and a program instruction that triggers a defect in combination with symbolic execution and static analysis, some program instructions can be skipped based on the static analysis results. That is, by implementing the embodiment of the present invention, it is not necessary to use symbolic execution to search all program instructions in the path to be searched, thereby improving the analysis efficiency of the path to be searched. Based on the above analysis, by implementing the embodiments of the present invention, it is possible to quickly determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, thereby quickly completing the screening of defect reports for the target program, and the user can obtain the real defects of the target program from the screened defect reports.

[0050] In an optional embodiment, the above step S20 specifically includes:

[0051] First, the program instructions in each to-be-searched path are traversed respectively, and the symbolic state of the to-be-searched path is updated according to the symbolic execution result or static analysis result of each program instruction in the to-be-searched path.

[0052] In an optional embodiment, when analyzing the path to be searched, starting from the defect starting position, each program instruction between the defect starting position and the program instruction that triggers the defect is analyzed in sequence, so as to obtain the analysis result of the path to be searched, and the analysis result of the path to be searched is the symbolic state of the path to be searched.

[0053] In an optional embodiment, when analyzing the path to be searched, each program instruction in the path to be searched is analyzed in turn. After analyzing each program instruction, a symbolic state is formed according to its symbolic execution result or static analysis result, and the symbolic state is used to replace the symbolic state formed according to the previous program instruction as the current symbolic state of the path to be searched.

[0054] Then, it is determined whether the path to be searched satisfies the triggering condition of the defect according to the symbol status of the path to be searched.

[0055] In an optional embodiment, each time the symbol state of the path to be searched is updated, it is determined whether the trigger condition of the defect is met based on the symbol state. When it is detected that the trigger condition of the defect is met based on the current symbol state, the path to be searched is determined to be a vulnerable path, and the analysis of the path to be searched is stopped.

[0056] If the path to be searched meets the triggering condition, it is determined that there is a vulnerable path between the defect start position and the program instruction that triggers the defect.

[0057] In an optional embodiment, different defects correspond to different trigger conditions. For example, when the defect is a null pointer dereference, the corresponding trigger condition is: a specific instruction performs a dereference operation on a pointer marked as NULL in the symbolic state of the corresponding program. That is, when the path to be searched is executed according to the symbolic state, if the path to be searched is feasible and the above trigger condition is met on the specific instruction marked as Sink in the defect report, the current path to be searched is considered to be a vulnerable path.

[0058] In an optional embodiment, when analyzing one of the paths to be searched, the program instructions in the path to be searched are traversed, and the symbolic state of the path to be searched is updated according to the symbolic execution result or static analysis result of each program instruction in the path to be searched, including:

[0059] First, static analysis is performed on each program instruction in the target program, the target program is converted into a memory-static single assignment (Memory-SSA) form, and a value flow graph (ValueFlow Graph) is constructed based on the target program converted into a memory-static single assignment form. In an embodiment of the present invention, the constructed value flow graph has context-sensitive properties and flow-sensitive properties, and the value flow graph captures the definition and use chain of all pointer variables in the target program within and between procedures.

[0060] Then, starting from the defect start position, traverse each program instruction in the path to be searched, and determine whether the current program instruction meets the skip condition according to the value flow graph.

[0061] In an optional embodiment, the skip condition for determining whether a program instruction can be skipped can be a general condition or a specific condition set according to the type indicated in the defect report. Exemplarily, in practice, pointer alias is one of the main sources of inaccurate analysis results. The program instruction can be used as a general condition that does not cause the increase of suspicious aliases (i.e., does not cause a pointer to have multiple pointing values), that is, if the execution of the current program instruction does not cause the increase of aliases, it means that the current program instruction meets the skip condition. Exemplarily, the general condition can be that the current program instruction is to call an external unknown application program interface, because even if an error occurs in the execution of an external unknown application program interface, it can be considered as a defect of an external location application program, rather than a defect of the target program itself. Therefore, if the current program instruction is to call an external unknown application program interface, it can be directly skipped. When the defect indicated in the defect report is a use after release, the specific condition can be that the current program instruction is an unconditional release of a specified pointer, and when the defect indicated in the defect report is a null pointer dereference, the specific condition can be that the current program instruction contains a non-null judgment on a specific pointer.

[0062] If the current program instruction meets the skip condition, the symbolic state is updated according to the static analysis result of the current program instruction. If the current program instruction meets the skip condition, it is considered that the symbolic state generated according to the static analysis result of the current program instruction is consistent with the symbolic state generated by the symbolic execution of the current program instruction. Since the symbolic execution of the current program instruction takes a long time, if the current program instruction meets the skip condition, the symbolic state is updated according to the static analysis result of the current program instruction.

[0063] If the current program instruction does not meet the skip condition, the symbolic state is updated according to the symbolic execution result of the current program instruction.

[0064] In an alternative embodiment, a restricted abstract symbolic state may be set so that each pointer points to at most one target, and the symbolic state is updated by interpreting each instruction or by static analysis information.

[0065] In an optional embodiment, in order to achieve rapid analysis of the path to be searched and to alleviate the problem of path explosion, the computing resources for analyzing the path to be searched are limited: the maximum search path length is set, and if the distance from the defect starting position to the current program instruction is less than or equal to the maximum search path length, the symbolic execution result or static analysis result of the current program instruction is used to update the symbolic state of the path to be searched, and the symbolic state of the path to be searched is judged based on the symbolic state of the path to be searched to determine whether the path to be searched meets the triggering condition of the defect. If the distance from the defect starting position to the current program instruction is greater than the maximum search path length, it is determined that the path to be searched does not meet the triggering condition of the defect. Exemplarily, the maximum search path length can be set to 500 steps.

[0066] In an optional embodiment, in order to achieve rapid analysis of the path to be searched, after determining the defect starting position and the instruction that triggers the defect program according to the defect report, the target program is first sliced, that is, the program instructions in the target program that have no data dependency and control dependency with the defect starting position, the instruction that triggers the defect program, and the path to be searched are deleted to form a simplified target program, and then symbolic execution and static analysis are used to determine whether there is a vulnerable path between the defect starting position and the defect triggering program in the simplified target program. It has been verified experimentally that after slicing the target program, when determining whether the defect report is a false alarm according to the simplified target program, the memory usage of the computer device is reduced by 13.05%, and the runtime performance of the computer device is improved by 9.3%.

[0067] In an optional embodiment, there are multiple paths to be searched between the defect starting position and the program instruction that triggers the defect, and different path exploration strategies can be executed to analyze each path to be searched to improve the efficiency of searching for vulnerable paths. The path exploration strategy includes a default strategy, a distance-based heuristic strategy, etc. When analyzing each path to be searched according to the default strategy, false branches are always explored first. When analyzing each path to be searched according to the distance-based heuristic strategy, the order of each path to be searched is sorted according to the distance from the defect starting position to the program instruction that triggers the defect.

[0068] In an optional embodiment, if the path to be searched includes loop instructions, in order to improve analysis efficiency, when analyzing the loop instructions, the loop is simply expanded in situ no more than 3 times to process the loop within the process.

[0069] In an optional embodiment, to maintain higher performance, when analyzing the search path, only constraints introduced by common arithmetic and comparison operations are considered, and complex arithmetic and pointer operations such as bit operations are ignored.

[0070] In order to describe in detail the target defect report screening method provided in the above embodiments, the embodiment of the present invention provides a target program, a defect report of the target program, and a process for screening the defect report:

[0071] like Figure 2 The target program is shown in Figure 1. There are two functions in the target program: hash_add() (lines 22 to 28) and hash_insert() (lines 6 to 21). The hash_insert() function attempts to insert entry into the global array hash_table: the get_table() function is called in line 7 and the hash_table pointer is returned to the table pointer. The loop from lines 9 to 14 traverses the entire array to find an available position. If there is an available position, the entry is inserted into the hash_table and stored in the corresponding parameter (line 17). Then, the function returns 0 (line 18). Otherwise, 1 (line 20) is returned to indicate that the insertion failed. The function hash_add() allocates a new memory object in in line 23 and calls hash_insert() to insert it into the hash_table (line 25). If the insertion fails (line 26), the object is released, otherwise the object is returned through the added pointer.

[0072] For example Figure 2 The target program shown in the figure has one defect report obtained by the static analysis tool: <23, 27, {26}>. Figure 2 In the target program shown, since there is a false alias between in and added, line 23 is the source location of the allocated object, and then the object is released on line 26 (as the key step in the vulnerability report) and used on line 27 (here as a Sink to trigger the vulnerability). The false positive is caused by the incorrect alias relationship - after calling the function hash_insert(), the content of in or added may point to the object created on line 23. Therefore, since the object is released on line 26 and used on line 27, it looks like a "use-after-free" vulnerability. However, the alias only holds when the insertion is successful and the function call returns 0, causing added to point to NULL instead of the released object, and the vulnerability cannot be triggered on line 27 in this case.

[0073] In order to detect the above defect reports, the following methods were used:

[0074] Step 1: Convert the target program into Figure 3 Memory-SSA form shown.

[0075] When converting the target program, the following Figure 4 The LLVM instruction set shown in Figure 4 In the table shown, the upper half is the LLVM instructions in standard SSA (static single assignment) form.

[0076] When converting the target program, an insensitive Andersen-style pointer analysis is performed as a pre-analysis to build SSA. The pre-analysis computes the following information: pts(p) is the set of static memory locations pointed to by pointer p, mod(F) and ref(F) are the memory locations outside of F that are modified and read by function F, respectively.

[0077] To construct the Memory-SSA form, two additional functions μ and χ are introduced to indicate the potential use of each instruction on memory objects and the indirect use of the definition. For an instruction S, Sμ and Sχ are used to represent the set of μ and χ and the instructions introduced for S, respectively. Sμ is inserted directly before S, while Sχ is introduced immediately after S.

[0078] Figure 5 The following are the standard rules and instructions for introducing μ and χ. Given a load instruction x:=*y, for each object O∈pts(y), a μ(O) instruction is introduced (rule [LOAD]). Similarly, each store instruction *x:=y is appended with a series of χ instructions, where the instruction O:=χ(O) represents an indirect update of the object O pointed to by y (rule [STORE]). At the function call site, μ and χ instructions are introduced to propagate the implicit definition and use of memory objects between procedures. This is achieved through three rules: [CALL], [REF], and [MOD]. For each object O r ∈ref(F), introduce μ(O r ) ∈F instruction, and introduce the corresponding μ(O r ) instruction (rule [CALL]). For each object O m ∈mod(F), a μ(O m ) ∈F function (rule [MOD]) and insert the corresponding μ(O before and after its call point x:=F(...) m ) and O m = x(O m )(Rule [CALL]). Conceptually, the μ and χ functions introduced at the function call and function entry / exit points act as extended parameters and return values ​​of function F, explicitly expressing the indirect use and definition of memory objects across procedures by F like passing values.

[0079] After the introduction of μ and χ instructions, the standard SSA algorithm is used to construct Figure 3 Memory-SSA shown in Figure 1. When constructing Memory-SSA, each instruction is labeled after its corresponding source code line location. For example, the statement on line 25 produces 5 instructions in Memory-SSA, labeled 25.1 to 25.5. added Pointed to by added, instruction 24.2:*added:=NULL introduces "24.3: added :=χ(O added )". SSA will rename the instruction to Since mod(hash_insert)={ added , O hash_table} leads to μ(O added ) and μ(O hash_table ) is introduced at the function hash_insert entry (7.1-7.4), exit (20.4 and 20.5) and call point (25.1 and 25.2). Here, the pseudo instruction 7.1:O is introduced. added =... and 7.3:O hash_table = ... to make it a valid SSA form. In addition, 25.4:O added :=χ(O added ) and 25.5:O hash_table :=χ(O hash_table ) is inserted after the call site of hash_insert.

[0080] Step 2: Convert the target program into Figure 3 After the Memory-SSA form shown, construct Figure 6 The value stream diagram shown:

[0081] When constructing the value flow graph, a value flow graph containing μ and χ functions is constructed in a standard flow-sensitive way. The value flow edge y←x represents the dependency relationship between x and y (i.e., the def-use relationship). In addition to the def-use chain provided by LLVM's SSA, value flow edges are also introduced for indirect def-use relationships, such as Figure 7As shown. According to rules [COPY] and [PHI], value flow edges are introduced to represent direct assignment operations. According to rule [LOAD], the implicit use of memory object O is connected to the load instruction. According to rule [STORE], O′←O represents a weak update to O. If a strong update is possible (i.e., when the stored value uniquely points to the only object O), this edge can be eliminated. Rule [CALL] encodes the standard pass-by-value semantics, where PAR F (q j ) is the actual parameter q of F j The formal parameters of RET F is the return value of F. The interprocedural value flows are annotated using context-sensitive call site labels. Rules [CALLMU] and [CALLCHI] introduce indirect interprocedural value flows into and out of the called function, respectively. At the function call site l:x:=F(...), for each memory allocation O used in F, two value flows are introduced and μ(O)←O. Thus, O is explicitly passed to O via the extended parameter μ(O) ∈F Similarly, for each memory object O modified in F, two value streams are introduced and μ(O) ∈F ←O ∈F , through the extended return value μ(O) ∈F O ∈F Returns to its corresponding caller value O′. By definition, O ∈F is Here, the label ( l and) l Indicates the context of the call point l corresponding to this value flow edge. In the value-flow summary, four more rules are introduced to summarize the value flow in the called function. The symbol Indicates that there is a reachable path from x to y in the value flow graph, and there should be matching context information, Figure 8 The rule [SUM] summarizes the sum of the parameters of F and its return value. A feasible value flow path for is when the method is at its call point, such as A summary edge is introduced. The summary edge is represented by the call site label l. The remaining three rules [SUMPAR], [SUMRET], and [SUMEXD] are used to handle indirect inter-procedural value flows in different situations. In short, [SUMPAR], [SUMRET], and [SUMEXD] summarize the indirect value flows from parameters to indirect return values, from indirect inputs to return values, and from indirect inputs to indirect return values, respectively.

[0082] For ease of explanation, Figure 6 In the embodiment shown, each node is marked with a corresponding instruction label. For example, the variable in in line 23 is represented as a node numbered 23. Figure 6 The value flow path in the gray area Take this as an example: Introduced at call point 25.3:err:=hash_table(in,added), parameter 23:in:=alloc is passed to parameter 6:entry:=... of function hash_insert. Next, instruction 17.1:*matched:=entry and According to the rule [STORE], the edge 17.2←6 is generated (for example, ). Side 20.1←17.2 in the instruction ) is introduced in accordance with Rule [PHI]. Finally, given and The existence of two value flow edges Introduced by rule [CHI]. Introduced by rule [SUMPAR]( Figure 8 ), value flow path Summarize as Explanation: in is stored in after calling instruction 25.3:err:=hash_table(in,added)

[0083] Step 3: After constructing the value flow graph, analyze each program instruction in the search path to obtain the symbolic state of the search path:

[0084] Fig. 9The symbolic state is shown. The symbolic state is maintained for each different path. The symbolic state consists of a heap H, a stack S, and a constraint list Σ. The heap H maps memory locations to symbolic objects, and the stack S contains a collection of local variables. When a path is symbolically executed, the conditional branch introduces constraints Σ. In an optional embodiment, for greater clarity, it can be assumed that both stack objects and global objects are managed by the heap H, and that local variables in different stack frames are not distinguished. When returning from a stack frame, stack objects and local variables are automatically recycled. An object o is a mapping from a constant offset to a value. The value is a symbolic expression or location c . Symbolic Expression Can be a constant c, an introduced symbolic value Or binary operation of two symbolic expressions. Position l c represents a location that is offset c from storage location l. For simplicity, symbol locations are not modeled and the offsets to storage locations are always guaranteed to be concrete values.

[0085] Fig.10 The following are the standard semantic rules for symbolic execution of instructions. In rule [ALLOC], for the allocation instruction x:=alloc, a new location is created in the heap H and the value of x is set to l0. The two rules [ASSIGN] and [ARITHMETIC] update the values ​​of the result variables. The φ instruction is generated by rule [ASSIGN], and its input value is unique during the path search process. Rules [LOAD] and [STORE] perform standard heap search and update, respectively. In [LOAD], only when location l c A heap search is performed for x:=*y only when (referenced by y) is in heap H. Can be handled by rules combined with static analysis. In rule [STORE], if Then the position l c will be lazily initialized and updated in H. In rule [CALL], the value of the actual parameter is copied to the formal parameter of the called function to update the stack, and symbolic execution continues from the entry point of the called function. In rule [RETURN], the return value is returned to the calling function, and the local variable (y F ∈F) and the local stack object (l F ∈F) is discarded. Finally, a branch instruction will differentiate (fork) into two states, one is the true branch state (rule [BRANCHT]), and the other is the false branch state (rule [BRANCHF]). At the same time, the constraint list will be updated accordingly, so that the symbolic execution of the subsequent path starts from the state of the corresponding branch.

[0086] Fig.11The corresponding rules are shown below. The rule [INIT] assigns a value to each parameter of the entry function FSource, thereby initializing the symbolic state. Each pointer parameter is assigned a new label l, and each non-pointer parameter is given a symbolic value.

[0087] In addition to Fig. 9 In addition to the symbolic states shown, an additional mapping is maintained Map static analysis object O to a unique location l in symbol heap H. If a store instruction *x:=y strongly updates O, then O has a unique corresponding location with value x, so rule [CHI] updates the mapping in a strong update (e.g., {O′:=x(O)} == {[*x:=y] χ}and ).

[0088] When instruction x:=*y is loaded from a new memory location that is not in the heap, a lazy initialization strategy is adopted for the corresponding symbolic object. There are three different cases: 1) When rule [LOADVAL] processes a non-pointer value x, a new symbolic value is assigned to it in heap H; 2) In rule [LOADPTR], if x is a pointer to an untracked object, when loading the pointer, an empty object is allocated in heap H and x is made to point to it; 3) In rule [LOADPTRM], x is a pointer value pointing to a tracked object O (i.e., O∈dome(M)), and x is assigned the tracked value of O, i.e., H[M[O]].

[0089] For any value k returned from a function call x:=F(...), for example, x and O′:=χ(O)∈[x:=F(...)] χ , skip the symbolic execution of this function call: if there is only one value in the value flow summary flowing to k. Therefore, if no false alias is introduced, that is, there is only one incoming value in this function call that flows directly or indirectly to all the returned values, the symbolic execution of this function call will be skipped, and the rule [SKIP] is used to handle this special case. The skipped function call is updated by the rule [SUMMARY], where the return value can be updated by this unique incoming value. In this rule, when the input value is a static object O, the return value will be updated similarly according to the rules [LOADPTR] and [LOADPTRM], which will not be repeated here.

[0090] Step 4: Determine whether there is a vulnerable path in the path to be searched based on the symbol status of the path to be searched.

[0091] like Fig.12 The whole process is summarized in and all the paths to be searched are illustrated for the given examples. Fig.12Not all traversed instructions are listed in , and each node only uses the first instruction of the traversed basic block as the label. Starting from the starting point, the initial state is instruction Strong Update From this we can conclude that has the same value as added. Instruction 25.3:err:=hash_insert(in,added) aggregates the two edges. and Introduced Therefore, this function call cannot be skipped and the called function is symbolically executed starting from 6:entry:=... When calling instruction 7.5:table:=get_table(...), the return value table has a unique passed value. Therefore, this function call is skipped, and table is updated to the symbolic value of hash_table. In this example, the bug report does not find the corresponding vulnerability trace. However, if the vulnerability condition error! = 0 is modified to error == 0 ( Figure 2 ), the vulnerability trajectory is indicated by a dotted line in Fig.12 Winning bid.

[0092] In an optional embodiment, in order to verify the effectiveness and efficiency of the target program defect report screening method provided in the above embodiment in detecting false positives, the target program defect report screening method provided in the above embodiment is run on a platform equipped with an Intel Xeon Gold6230@2.10GHz CPU and 512GB memory to track the use-after-free and null pointer dereference vulnerabilities reported by the static analysis tool. Two sets of benchmarks are used for the evaluation: 1) Juliet test suite; 2) Fig.13 A set of 21 real open source applications is shown.

[0093] The Juliet test suite contains a large number of small defective programs of different types (each defective program is usually accompanied by a correct version) and is widely used to evaluate vulnerability detection tools. In the embodiment of the present invention, the target program defect report screening method provided in the above embodiment is evaluated for three defect types: CWE401 (memory leak), CWE416 (use after free) and CWE476 (null pointer dereference).

[0094] like Fig.14The experimental results are summarized in the table shown. There are 2045 test cases (column 2), and the static analysis tool generates a total of 2462 vulnerability reports (column 3). The target program defect report screening method provided in the above embodiment searches for 1435 vulnerability traces in 2462 reports (column 4), and successfully eliminates 1027 false positives.

[0095] Fig.15 The results of a set of 21 real applications are reported in the table shown. The size of these applications ranges from 5,000 lines of code (wrk) to 309,000 lines of code (httpd), with a total of 1,666,000 lines of code (column 2). The static analysis tool reported 904 use-after-free vulnerabilities (column 3) and 2,954 null pointer dereference vulnerabilities (column 8) in the 21 applications. Based on the initial set of potential vulnerabilities, the true vulnerability tracking (TP), the vulnerability trajectory (FP) of the vulnerability, the memory usage, and the analysis time of the target program defect report screening method provided in the above embodiment are reported. The analysis time includes the time to establish the context and process sensitive value flow chart, and the time to symbolically search for the vulnerability trajectory. In an embodiment of the present invention, a time limit of 10 seconds is set for each defect report, and a time budget of 2 hours is provided for each application. For each benchmark application, the target program defect report screening method is run at least 3 times and the average data in the 3 runs is reported.

[0096] In general, by executing the target program defect report screening method provided in the above embodiment, 29 post-release reuse (column 4) and 895 null pointer dereference (column 9) vulnerability traces were successfully confirmed, effectively eliminating 71.4% of the false positives of the static analysis tool. 100 defect reports that did not search for vulnerability traces by executing the target program defect report screening method provided in the above embodiment were manually randomly checked, and it was confirmed that they were all false positives. There were also 12 invalid post-release reuse vulnerabilities (column 4) and 45 invalid false null pointer dereference (column 9) vulnerability traces, with a total false positive rate of 5.88% (29.3% for post-release reuse vulnerabilities and 4.79% for null pointer dereference vulnerabilities). Fig.15 The memory consumption (columns 6 and 11) and time cost (columns 7 and 12) in show the performance of the target program defect report screening method provided in the above embodiments on each benchmark application.

[0097] In an embodiment of the present invention, the results of executing the target program defect report screening method provided in the above embodiment through different execution strategies are also evaluated, so as to compare the effects of different strategy schemes on efficiency and effectiveness, and these differences are reflected in the timeout percentage and the accuracy of vulnerability trajectory.

[0098] Figure 16(a) and Figure 16(b) compare the results of applying different time limits to tracking potential "use-after-free" or "null pointer dereference" vulnerabilities. As the time limit increases (from 5s to 100s), the amount of timeouts decreases significantly, while the number of defects in the identified vulnerability tracks and the number of confirmed false positives also increase steadily.

[0099] Figure 16(c) and Figure 16(d) provide the impact of different tradeoffs on defect report screening. The strategies are: default always gives priority to the false branch of the branch instruction in the path selection strategy; priority gives priority to the branch target closer to the sink in the path selection strategy; no-slice does not perform program slicing; no-step-in always uses static analysis summary information to update the symbolic state when calling a function; step-in tries to symbolically execute the called function at the function call point without skipping the function call.

[0100] The experimental results show that the difference between priority and default is small, while the number of timeouts caused by the no-slice scheme is significantly larger than that of default: for the null pointer dereference vulnerability, the number of timeouts increases from 13.85% to 19.26%. Overall, the program slicing optimization reduces memory usage by 13.05% and improves runtime performance by 9.3%. Finally, since static analysis summaries are not always accurate, the accuracy drops significantly when no-step-in is used. When step-in is used, the number of timeouts for the use-after-free vulnerability increases significantly compared to default: from 45.8% to 63.4% (Figure 16(c)), and the accuracy of the vulnerability trajectory is slightly different. This shows that by using static analysis summary information, the symbolic execution performance can be significantly improved while maintaining the same level of accuracy.

[0101] The embodiment of the present invention also provides a target program defect report screening device, such as Fig.17 As shown, including:

[0102] The defect report acquisition module 10 is used to obtain a defect report of the target program, determine the defect starting position, trigger the defect program instruction, and the defect in the target program pointed out by the defect report according to the defect report. For details, please refer to the description in the above embodiment and will not be repeated here.

[0103] The path search module 20 is used to use symbolic execution and static analysis to analyze the path to be searched from the defect starting position to the program instruction that triggers the defect, and determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect. There are one or more paths to be searched from the defect starting position to the program instruction that triggers the defect in the target program. For details, please refer to the description in the above embodiment and will not be repeated here.

[0104] The defect report screening module 30 is used to determine that the defect report is a false alarm if there is no vulnerable path between the defect starting position and the program instruction that triggers the defect that satisfies the triggering condition of the defect. For details, please refer to the description in the above embodiment and will not be repeated here.

[0105] An embodiment of the present invention provides a target program defect report screening device. After obtaining the defect report of the target program, the path to be searched between the defect starting position and the program instruction that triggers the defect is analyzed, and it is determined whether there is a vulnerable path in the path to be searched. If there is no vulnerable path, the defect report is determined to be a false alarm, thereby realizing the screening of defect reports. The user can quickly obtain the real defect information of the target program from the screened defect report. Moreover, if the path to be searched is analyzed only by symbolic execution, it is necessary to use symbolic execution to search all program instructions in the path to be searched, so as to determine whether the path to be searched is a vulnerable path. In the target program defect report screening device provided by the embodiment of the present invention, when analyzing the path to be searched between the defect starting position and the program instruction that triggers the defect in combination with symbolic execution and static analysis, some program instructions can be skipped based on the static analysis results. That is, by implementing the embodiment of the present invention, it is not necessary to use symbolic execution to search all program instructions in the path to be searched, thereby improving the analysis efficiency of the path to be searched. Based on the above analysis, by implementing the embodiments of the present invention, it is possible to quickly determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, thereby quickly completing the screening of defect reports for the target program, and the user can obtain the real defects of the target program from the screened defect reports.

[0106] An embodiment of the present invention provides a computer device, such as Fig.18 As shown, the computer device mainly includes one or more processors 41 and a memory 42. Fig.18 A processor 41 is taken as an example.

[0107] The computer device may further include: an input device 43 and an output device 44 .

[0108] The processor 41, the memory 42, the input device 43 and the output device 44 may be connected via a bus or other means. Fig.18 The example of connecting through bus is taken in the following.

[0109] Processor 41 can be a central processing unit (CPU). Processor 41 can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components and other chips, or a combination of the above-mentioned various types of chips. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The memory 42 can include a storage program area and a storage data area, wherein the storage program area can store an operating system, at least one application required for a function; the storage data area can store data created according to the use of the target program defect report screening device, etc. In addition, the memory 42 can include a high-speed random access memory, and can also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage devices. In some embodiments, the memory 42 optionally includes a memory remotely arranged relative to the processor 41, and these remote memories can be connected to the target program defect report screening device through a network. The input device 43 can receive the calculation request (or other digital or character information) input by the user, and generate key signal input related to the target program defect report screening device. The output device 44 can include a display device such as a display screen to output the calculation result.

[0110] An embodiment of the present invention provides a computer-readable storage medium, which stores computer instructions, and the computer storage medium stores computer executable instructions, which can execute the target program defect report screening method in any of the above method embodiments. Among them, the storage medium can be a disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory (Flash Memory), a hard disk (HDD) or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above types of memory.

[0111] Obviously, the above embodiments are merely examples for the purpose of clear explanation, and are not intended to limit the implementation methods. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the implementation methods here. The obvious changes or modifications derived therefrom are still within the scope of protection of the invention.

Claims

1. A method for screening target program defect reports, characterized in that: include: Obtaining a defect report of the target program, and determining the defect starting position, triggering defect program instructions, and the defect existing in the target program indicated by the defect report according to the defect report; By using symbolic execution and static analysis, the to-be-searched path from the defect starting position to the defect-triggering program instruction is analyzed to determine whether there is a vulnerable path between the defect starting position and the defect-triggering program instruction that satisfies the defect triggering condition, and there are one or more to-be-searched paths from the defect starting position to the defect-triggering program instruction in the target program; If there is no vulnerable path between the defect start position and the defect triggering program instruction, determining that the defect report is a false alarm; Different types of defects have their corresponding trigger conditions. When the trigger conditions are met during the execution of program instructions, the target program is considered to have the defect. It is determined whether there is a search path that meets the trigger conditions between the defect start position and the program instruction that triggers the defect. If so, the defect report is determined to be a true report. If not, the defect report is determined to be a false alarm. Symbolic execution and static analysis are used to analyze the path to be searched from the defect starting position to the program instruction that triggers the defect, and determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, including: Traversing the program instructions in each of the paths to be searched respectively, and updating the symbolic status of the paths to be searched according to the symbolic execution results or static analysis results of each of the program instructions in the paths to be searched; Determining whether the path to be searched satisfies a trigger condition of a defect according to a symbol state of the path to be searched; If the path to be searched satisfies the trigger condition, determining that there is a vulnerable path between the defect start position and the program instruction that triggers the defect; If no path to be searched that meets the trigger condition is detected within the preset time period, it is determined that there is no vulnerable path between the defect start position and the defect triggering program instruction; Traversing the program instructions in the path to be searched, and updating the symbolic state of the path to be searched according to the symbolic execution result or static analysis result of each program instruction in the path to be searched, including: Performing static analysis on each program instruction in the target program, converting the target program into a memory static single assignment form, and constructing a value flow graph according to the target program converted into the memory static single assignment form; Taking the defect starting position as the starting point, traverse each program instruction in the path to be searched, and determine whether the current program instruction meets the skip condition according to the value flow graph; the skip condition is a general condition, or, according to the specific condition set according to the type indicated in the defect report, the program instruction will not cause the increase of suspicious aliases as a general condition, or the current program instruction is a call to an external unknown application program interface as a general condition; when the defect indicated in the defect report is a use after release, the specific condition is that the current program instruction is an unconditional release of a specified pointer, and when the defect indicated in the defect report is a null pointer dereference, the specific condition is that the current program instruction contains a non-null judgment on a specific pointer; If the current program instruction satisfies the skip condition, updating the symbol status according to the static analysis result of the current program instruction; If the current program instruction does not satisfy the skip condition, updating the symbolic state according to the symbolic execution result of the current program instruction; Before the step of judging whether the current program instruction satisfies the skip condition according to the value flow graph, the method further includes: If the distance from the defect starting position to the current program instruction is less than or equal to the maximum search path length, executing the step of determining whether the current program instruction satisfies the skip condition according to the value flow graph; If the distance from the defect starting position to the current program instruction is greater than the maximum search path length, it is determined that the path to be searched does not meet the triggering condition of the defect.

2. The target program defect report screening method according to claim 1, characterized in that: After determining the defect starting position, the defect-triggering program instruction, and the defect existing in the target program indicated by the defect report according to the defect report, and before analyzing the path to be searched from the defect starting position to the defect-triggering program instruction by using symbolic execution and static analysis, the method further includes: Delete the program instructions in the target program that have no data dependency and control dependency with the defect starting position, the defect triggering program instructions, and the path to be searched, to form a simplified target program.

3. A target program defect report screening device, characterized in that: include: A defect report acquisition module, used to acquire a defect report of a target program, determine a defect starting position, trigger a defect program instruction, and the defect existing in the target program indicated by the defect report according to the defect report; a path search module, configured to analyze the path to be searched from the defect starting position to the defect-triggering program instruction by using symbolic execution and static analysis, and determine whether there is a vulnerable path between the defect starting position and the defect-triggering program instruction, and whether there is one or more paths to be searched from the defect starting position to the defect-triggering program instruction in the target program; A defect report screening module, configured to determine that the defect report is a false alarm if there is no vulnerable path between the defect start position and the defect triggering program instruction that satisfies the defect triggering condition; Different types of defects have their corresponding trigger conditions. When the trigger conditions are met during the execution of program instructions, the target program is considered to have the defect. It is determined whether there is a search path that meets the trigger conditions between the defect start position and the program instruction that triggers the defect. If so, the defect report is determined to be a true report. If not, the defect report is determined to be a false alarm. Symbolic execution and static analysis are used to analyze the path to be searched from the defect starting position to the program instruction that triggers the defect, and determine whether there is a vulnerable path between the defect starting position and the program instruction that triggers the defect, including: Traversing the program instructions in each of the paths to be searched respectively, and updating the symbolic status of the paths to be searched according to the symbolic execution results or static analysis results of each of the program instructions in the paths to be searched; Determining whether the path to be searched satisfies a trigger condition of a defect according to a symbol state of the path to be searched; If the path to be searched satisfies the trigger condition, determining that there is a vulnerable path between the defect start position and the program instruction that triggers the defect; If no path to be searched that meets the trigger condition is detected within the preset time period, it is determined that there is no vulnerable path between the defect start position and the defect triggering program instruction; Traversing the program instructions in the path to be searched, and updating the symbolic state of the path to be searched according to the symbolic execution result or static analysis result of each program instruction in the path to be searched, including: Performing static analysis on each program instruction in the target program, converting the target program into a memory static single assignment form, and constructing a value flow graph according to the target program converted into the memory static single assignment form; Taking the defect starting position as the starting point, traverse each program instruction in the path to be searched, and determine whether the current program instruction meets the skip condition according to the value flow graph; the skip condition is a general condition, or, according to the specific condition set according to the type indicated in the defect report, the program instruction will not cause the increase of suspicious aliases as a general condition, or the current program instruction is a call to an external unknown application program interface as a general condition; when the defect indicated in the defect report is a use after release, the specific condition is that the current program instruction is an unconditional release of a specified pointer, and when the defect indicated in the defect report is a null pointer dereference, the specific condition is that the current program instruction contains a non-null judgment on a specific pointer; If the current program instruction satisfies the skip condition, updating the symbol status according to the static analysis result of the current program instruction; If the current program instruction does not satisfy the skip condition, updating the symbolic state according to the symbolic execution result of the current program instruction; Before the step of judging whether the current program instruction satisfies the skip condition according to the value flow graph, the method further includes: If the distance from the defect starting position to the current program instruction is less than or equal to the maximum search path length, executing the step of determining whether the current program instruction satisfies the skip condition according to the value flow graph; If the distance from the defect starting position to the current program instruction is greater than the maximum search path length, it is determined that the path to be searched does not meet the triggering condition of the defect.

4. A computer device, characterized in that: include: at least one processor; And a memory communicatively connected to at least one processor; wherein the memory stores instructions executable by at least one processor, and the instructions are executed by at least one processor, thereby executing the target program defect report screening method as described in claim 1 or 2.

5. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the target program defect report screening method as claimed in claim 1 or 2.

Images