A static false positive confirmation method and system based on fuzz testing, a terminal and a storage medium

Abstract

The application relates to the technical field of data processing, and discloses a static false alarm confirmation method and system based on fuzzy testing, a terminal and a storage medium. The method comprises the following steps: obtaining static alarm data corresponding to target source code, and performing pretreatment to obtain a pretreatment result; performing correlation analysis on the pretreatment result to obtain a correlation analysis result, and constructing a minimum compilation code segment according to the pretreatment result and the correlation analysis result; performing program slicing processing on the minimum compilation code segment to obtain an execution code segment, and performing fuzzy testing processing on the execution code segment to obtain a fuzzy testing result; and performing alarm classification processing on the fuzzy testing result to obtain an alarm classification result. According to the application, the minimum compilation code segment is generated according to the static alarm data, and the program slicing processing, the fuzzy testing processing and the alarm classification processing are performed, so that the alarm classification result is obtained, and the accuracy and efficiency of automatic confirmation of the static alarm can be effectively improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a static false alarm confirmation method, system, terminal, and computer-readable storage medium based on fuzz testing. Background Technology

[0002] Static analysis tools often generate a large number of false positives when reporting true positive alerts (i.e., the vulnerabilities reported in the alert actually exist), which seriously affects the usability of static analysis tools. To solve this problem, a dynamic-based automatic confirmation method for static alerts is generally used.

[0003] However, existing automatic confirmation methods for static alarms based on dynamic approaches can only solve part of the automatic confirmation problem for static alarms, and the processing time is relatively long, which cannot meet user needs.

[0004] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0005] The main objective of this invention is to provide a static false alarm confirmation method, system, terminal, and computer-readable storage medium based on fuzz testing. This aims to solve the problem that existing static alarm automatic confirmation methods based on dynamic methods can only solve part of the static alarm automatic confirmation problem and have a long processing time, which cannot meet user needs.

[0006] To achieve the above objectives, the present invention provides a static false alarm confirmation method based on fuzz testing, the static false alarm confirmation method based on fuzz testing comprising the following steps:

[0007] Obtain the static alarm data corresponding to the target source code, and preprocess the static alarm data to obtain the preprocessing result;

[0008] A correlation analysis is performed on the preprocessing results to obtain the correlation analysis results, and a minimum compiled code snippet is constructed based on the preprocessing results and the correlation analysis results.

[0009] The minimum compiled code fragment is sliced ​​to obtain an executable code fragment, and the executable code fragment is then subjected to fuzz testing to obtain the fuzz test results.

[0010] The fuzzy test results are then processed for alarm classification to obtain alarm classification results.

[0011] Optionally, in the static false alarm confirmation method based on fuzz testing, the preprocessing result includes static alarm data, compilation commands, structured information, and target variables;

[0012] The process of obtaining static alarm data corresponding to the target source code and preprocessing the static alarm data to obtain preprocessing results specifically includes:

[0013] Identify the target program, and download and configure the static analysis tool on the target program;

[0014] The target source code is identified, and static analysis is performed on the target source code using the static analysis tool to obtain the static alarm data;

[0015] The compilation commands are generated using the Bear tool, and the structured information of the target program is generated using srcML.

[0016] Obtain the location of the vulnerability when it occurs in the static alarm data, and traverse the target source code according to the location of the vulnerability until the traversed characters are non-spaces or non-special symbols, and obtain the target variable.

[0017] Optionally, the static false positive confirmation method based on fuzz testing, wherein performing correlation analysis on the preprocessing results to obtain correlation analysis results, and constructing a minimal compiled code fragment based on the preprocessing results and the correlation analysis results, specifically includes:

[0018] The target function is determined based on the structured information in the preprocessing result and the location of the vulnerability, and multiple target parameters in the target function are obtained.

[0019] Calculate the correlation between each target parameter and the target variable to obtain the correlation analysis results;

[0020] Obtain the parameter type corresponding to each target parameter, and assign values ​​to each target parameter according to the parameter type and the correlation analysis results to obtain the minimum compiled code fragment.

[0021] Optionally, in the static false alarm confirmation method based on fuzz testing, the correlation analysis results include control dependencies and data dependencies;

[0022] The process of calculating the correlation between each target parameter and the target variable to obtain correlation analysis results further includes:

[0023] The basic block in which the target variable is located is determined, and the basic block is marked to obtain the target basic block;

[0024] Determine the entry node and obtain multiple path constraints from the entry node to the target basic block;

[0025] If the target parameter is included in multiple path constraints, then it is determined that the target parameter and the target variable have the control dependency relationship.

[0026] Determine the variable nodes and construct a target set based on the variable nodes and the target parameters;

[0027] Determine whether the parameters in the target set reach the target basic block. If so, determine that the target parameters and the target variables have the data dependency relationship.

[0028] Optionally, the static false positive confirmation method based on fuzz testing, wherein obtaining the parameter type corresponding to each target parameter and assigning values ​​to each target parameter according to the parameter type and the correlation analysis results to obtain the minimum compiled code fragment specifically includes:

[0029] Obtain the parameter type corresponding to each objective parameter in the objective function;

[0030] If the parameter type is a non-structure type, then a declaration statement and an assignment statement are generated for each target parameter, and the minimum compiled code fragment is obtained based on the declaration statement and the assignment statement;

[0031] If the parameter type is a structure type, then the assignment process is performed using either a full assignment strategy or a simple assignment strategy based on the correlation analysis results to obtain the minimum compiled code fragment.

[0032] Optionally, the static false positive confirmation method based on fuzzing, wherein the step of performing program slicing on the minimum compiled code segment to obtain an executable code segment, and performing fuzzing on the executable code segment to obtain a fuzzing result, specifically includes:

[0033] Determine the preset program slicing tool, and determine the preset slicing standard and the location of the code to be sliced;

[0034] The preset program slicing tool is used to slice the smallest compiled code segment according to the preset slicing standard and the location of the code to be sliced, to obtain the executable code segment;

[0035] Determine the preset fuzzing tool and obtain the target file location corresponding to the executed code fragment;

[0036] The target file location is fuzzed using the preset fuzzing tool to obtain the fuzzing test result.

[0037] Optionally, in the static false alarm confirmation method based on fuzz testing, the alarm classification result includes true positive alarms and false positive alarms;

[0038] The alarm classification process performed on the fuzzy test results to obtain alarm classification results specifically includes:

[0039] Based on the fuzz test results, determine whether a data corruption has occurred at the target file location;

[0040] If a data corruption occurs at the target file location, and the cause of the data corruption is consistent with the cause of the vulnerability in the static alarm data, then the fuzz test result is determined to be a true positive alarm.

[0041] If no data corruption occurs at the target file location, the fuzz test result is determined to be a false positive alarm.

[0042] Furthermore, to achieve the above objectives, the present invention also provides a static false alarm confirmation system based on fuzz testing, wherein the static false alarm confirmation system based on fuzz testing includes:

[0043] The preprocessing module is used to obtain static alarm data corresponding to the target source code and preprocess the static alarm data to obtain the preprocessing result;

[0044] A correlation analysis module is used to perform correlation analysis on the preprocessing results, obtain correlation analysis results, and construct a minimum compiled code fragment based on the preprocessing results and the correlation analysis results.

[0045] The fuzzing module is used to perform program slicing on the minimum compiled code fragment to obtain an executable code fragment, and to perform fuzzing on the executable code fragment to obtain fuzzing results.

[0046] The alarm classification module is used to perform alarm classification processing on the fuzz test results to obtain alarm classification results.

[0047] In this invention, static alarm data corresponding to the target source code is obtained, and the static alarm data is preprocessed to obtain a preprocessing result. Correlation analysis is performed on the preprocessing result to obtain a correlation analysis result, and a minimal compiled code fragment is constructed based on the preprocessing result and the correlation analysis result. The minimal compiled code fragment is then subjected to program slicing to obtain an executable code fragment, and fuzz testing is performed on the executable code fragment to obtain a fuzz test result. Finally, the fuzz test result is used for alarm classification to obtain an alarm classification result. This invention generates a minimal compiled code fragment by preprocessing and performing correlation analysis on static alarm data, and then performs program slicing, fuzz testing, and alarm classification on the minimal compiled code fragment to finally obtain an alarm classification result, which can effectively improve the accuracy and efficiency of automatic confirmation of static alarms. Attached Figure Description

[0048] Figure 1 This is a flowchart of a preferred embodiment of the static false alarm confirmation method based on fuzz testing of the present invention;

[0049] Figure 2 This is a schematic diagram of the overall implementation process of a preferred embodiment of the static false alarm confirmation method based on fuzz testing of the present invention;

[0050] Figure 3 This is a schematic diagram of the code snippet generation algorithm of a preferred embodiment of the static false alarm confirmation method based on fuzz testing of the present invention;

[0051] Figure 4 This is a structural diagram of a preferred embodiment of the static false alarm confirmation system based on fuzz testing of the present invention;

[0052] Figure 5 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0054] When static analysis tools report true positive alerts (i.e., the vulnerabilities (bugs) reported in the alerts actually exist), they are often accompanied by a large number of false alarms. This is because accurate static analysis takes a long time, so static analysis tools usually sacrifice some accuracy to ensure that the analysis time is not too long. However, because of the sacrifice of accuracy, the analysis is inaccurate, resulting in false alarms. This seriously affects the usability of static analysis tools.

[0055] Currently, static alarm auto-acknowledgment solutions based on dynamic methods can be divided into two categories according to the dynamic technology used: static alarm auto-acknowledgment methods based on fuzz testing and static alarm auto-acknowledgment methods based on symbolic execution.

[0056] For fuzz-based methods for automatic confirmation of static alerts: Existing technologies generally achieve efficient automatic confirmation of static alerts by decomposing the complex monolithic binary program in an RTOS (Real-time Operating System) into independent task slices and performing fuzz testing on slices with irrelevant paths pruned. Alternatively, bug-related functions can be obtained from the alert information, and an executable code snippet containing the bug-related functions can be generated using a compiler and GDB (GNU symbolic debugger). Fuzz testing can then be performed on the code snippet to achieve automatic confirmation of static alerts.

[0057] For methods of automatically verifying static alerts based on symbolic execution: Existing technologies generally verify static alerts automatically by executing symbols guided by reachability analysis results on the program. Alternatively, reachability analysis is used to eliminate invalid alerts, and hybrid symbolic execution is used to verify the remaining alerts. Another approach is to first prune irrelevant paths using reachability analysis and path constraint solving, and then use symbolic execution to automatically verify alerts. Program slicing can also be used to simplify the code, and symbolic execution can be performed on the simplified code to verify static alerts, but these methods often result in high latency or even timeouts.

[0058] Existing static alarm auto-confirmation methods based on dynamic approaches can only partially solve the problem of automatic static alarm confirmation and suffer from excessively long processing times. This invention proposes Fcs4sa (Fuzzing Code Snippet for Static Analysis), a method for automatically confirming static alarms. It utilizes alarm information (primarily including the file containing the bug, its location (including line and column numbers), bug type, and the process of the bug's occurrence, and may also include bug-related variables) to synthesize code snippets, and performs fuzz testing on these snippets, enabling more targeted alarm confirmation.

[0059] Understandably, the high false alarm rate of static alerts significantly impacts the practicality of static analysis techniques. Dynamic methods (referring to methods that analyze programs or trigger bugs by executing programs) are currently widely used for the automatic confirmation of static alerts (static alerts are alerts that occur when analyzing source code in a non-running state and encountering problems). However, current automatic confirmation solutions for static alerts based on dynamic methods typically only achieve automatic confirmation of a portion of static alerts, and there is still room for improvement in terms of timeliness. Therefore, this invention proposes Fcs4sa, a method specifically designed for the automatic confirmation of static alerts. It first generates a minimal compiled code snippet containing relevant functions based on the alert information, and optimizes efficiency during the generation process using a parameter generation strategy. Then, it prunes irrelevant paths in the minimal compiled code snippet using program slicing. Finally, it uses fuzz testing to confirm the alert. This invention evaluates the performance of Fcs4sa on a preset test set, three open-source libraries, and one open-source dataset, and compares it with three traditional automatic confirmation methods for static alerts based on dynamic methods. The results show that Fcs4sa in this invention outperforms other methods in terms of accuracy and efficiency in automatically confirming static alerts.

[0060] The preferred embodiment of the static false alarm confirmation method based on fuzz testing described in this invention, such as... Figure 1 As shown, the static false alarm confirmation method based on fuzz testing includes the following steps:

[0061] Step S10: Obtain the static alarm data corresponding to the target source code, and preprocess the static alarm data to obtain the preprocessing result. The preprocessing result includes the static alarm data, compilation commands, structured information, and target variables.

[0062] like Figure 2 The diagram shows the overall process of Fcs4sa as set in this invention. Fcs4sa consists of four main parts: preprocessing, code snippet generation, fuzz testing, and alarm classification.

[0063] Preprocessing steps: 1. Obtain necessary information, including running a static analysis tool on the target program to generate static alert data (first, download the static analysis tool and configure the necessary environment, then prepare the target source code to be statically analyzed, and finally run the static analysis tool to analyze the target source code and obtain static alert data). 2. Use the Bear tool to build the project and store the build commands for subsequent creation of the minimum compilable code snippet. 3. Use srcML (Source Code Markup Language, an XML format for source code, used to convert the format of source code) to generate structured information of the target program, and extract bug-related target variables for correlation analysis (where the target variables are the bug-related variables in the static alert data).

[0064] Specifically, the target program is identified, and a static analysis tool is downloaded and configured on the target program; the target source code is identified, and static analysis is performed on the target source code using the static analysis tool to obtain the static alert data; the compilation command is generated using the Bear tool, and the structured information of the target program is generated using srcML; the vulnerability occurrence location corresponding to the vulnerability occurrence in the static alert data is obtained, and the target source code is traversed according to the vulnerability occurrence location until the traversed characters are non-spaces or non-special symbols, thereby obtaining the target variable.

[0065] The process of extracting the target variable is as follows: The target variable is the variable that triggers the bug. For example, when a variable is used again after its memory has been released, the alert will indicate that a certain variable was released in a certain line (release refers to the release of memory. The program allocates memory for a certain variable and then reclaims that memory in the subsequent process. This reclamation of memory is called release). And if the variable is still used in subsequent lines of code, then that variable is the target variable.

[0066] The target variable may be explicitly specified in the alert, allowing you to directly obtain its information, including its name and type. However, in some cases, the alert may not directly indicate the specific variable. In such situations, you need to traverse the source code starting from the location of the bug (line and column number) provided by the alert, using the condition that the current traversal character is neither a space nor a special character as the end condition. This will determine the ending position of the target variable name, allowing you to extract the target variable. After extracting the target variable information, return it in the format of "line number and variable name" for use in the subsequent code snippet generation process.

[0067] Step S20: Perform correlation analysis on the preprocessing results to obtain the correlation analysis results, and construct the minimum compiled code fragment based on the preprocessing results and the correlation analysis results.

[0068] The generation of the minimum compilable code snippet consists of three parts: 1. Performing correlation analysis to obtain the correlation between each parameter of the objective function and the objective variable; 2. Combining the preprocessed information (i.e., the preprocessing results in this invention, including static alarm data, compilation commands, structured information, and objective variables) and the results of the correlation analysis to create the minimum compilable code snippet (first, an initial code snippet is generated, then the declaration statements and assignment statements of the parameters in the objective function need to be generated, and finally the parameters are passed to the objective function to generate the calling code of the objective function, which is the minimum compilable code snippet, which can be used for subsequent fuzz testing); 3. Slicing the code snippet to reduce irrelevant paths.

[0069] Specifically, the target function is determined based on the structured information in the preprocessing result and the location of the vulnerability, and multiple target parameters in the target function are obtained; the basic block in which the target variable is located is determined, and the basic block is marked to obtain the target basic block.

[0070] The purpose and function of correlation analysis is to determine whether there is a correlation in data flow or control flow between the parameters of the objective function (the objective function is the function where the code line where the bug occurs, which is obtained by combining the bug location information in the static alarm data with the structured information obtained through srcML) and the target variable, and to further guide the generation of code snippets.

[0071] Specifically, correlation analysis primarily analyzes two types of static information: the control flow graph (CFG, a directed graph representing all possible control flow paths during program execution) and the data flow graph (DFG, a directed graph representing data dependencies and the order of operations in the program). Based on the control flow graph, it can be analyzed whether the parameters of the objective function are related to the execution of related paths (if so, the parameters are considered correlated with the target variable). Based on the data flow graph, it can be analyzed whether the parameters of the objective function affect the value of the target variable (based on the data flow graph, it can be analyzed whether the parameters of the objective function are related to the value of the target variable; if so, the parameters are considered correlated with the target variable). Based on the correlation, the parameters of the objective function are divided into a relevant parameter set (rp) and an irrelevant parameter set (urp). (Correlation is obtained through analysis of the control flow graph and data flow graph; parameters are then divided into relevant and irrelevant parameter sets based on correlation. If a correlation exists, the parameter is placed in the relevant parameter set; if no correlation exists, the parameter is placed in the irrelevant parameter set.)

[0072] Determine the entry node and obtain multiple path constraints from the entry node to the target basic block; if the multiple path constraints include the target parameter, then determine that the target parameter and the target variable have the control dependency relationship.

[0073] During the code generation process, different collections select different generation strategies. The following will detail the analysis process of two types of static information.

[0074] The control flow graph analysis process is as follows: 1. This invention specially marks the basic block containing the target variable, calling it the target basic block; 2. Starting from the entry node, traverse all paths reachable from the entry node, collecting the paths that can reach the target basic block and their related path constraints; 3. If a path constraint contains a certain parameter, it is considered that the parameter has a control dependency relationship with the target variable, and the parameter is added to the relevant parameter set rp. If a parameter is not in any path constraint, then this invention considers that the parameter has no control dependency relationship with the target variable.

[0075] Identify variable nodes and construct a target set based on the variable nodes and the target parameters; determine whether the parameters in the target set reach the target basic block; if so, determine that the target parameters and the target variables have the data dependency relationship.

[0076] For data flow graph analysis: The data flow graph describes the data dependencies in the program. For each parameter of the objective function, this invention propagates the parameter along the data flow graph. The propagation process is as follows: 1. Initially, the set elements only contain the parameters of the objective function being analyzed; 2. Traverse the elements in the set, adding the variable nodes in the data flow graph that have edges with the elements (referring to variable nodes that may have data dependencies with the elements) to the set; 3. Repeat this process until the target variable or the end of the function is reached. If the target variable is successfully reached, it is considered that the parameter has a data dependency relationship with the target variable, and the parameter is added to the relevant parameter set rp (the set rp will be used to guide code snippet generation).

[0077] Obtain the parameter type corresponding to each target parameter in the target function; if the parameter type is a non-structure type, generate a declaration statement and an assignment statement for each target parameter, and obtain the minimum compiled code fragment based on the declaration statement and the assignment statement; if the parameter type is a structure type, perform assignment processing using a full assignment strategy or a simple assignment strategy based on the correlation analysis results to obtain the minimum compiled code fragment.

[0078] This invention also includes an irrelevant parameter set urp. The parameters of the objective function will only be added to the irrelevant parameter set when there is neither a control dependency nor a data dependency between the objective parameters and the objective variables.

[0079] like Figure 3 The diagram shows the algorithm for generating code snippets. It takes bug alert W (i.e., static alert data in this invention) and source code C (i.e., target source code in this invention) as input, and outputs the generated code snippet CS (i.e., the minimum compiled code snippet in this invention). First, the target variable (i.e., the location of the bug in the alert) is extracted. Figure 3 The first step involves analyzing the target function's dependencies on the source code, generating a program dependency graph, including a control flow graph (CFG) and a data flow graph (DFG). Then, the correlation between the target function's parameters and the target variable is analyzed on the control flow graph and data flow graph, returning a set of parameters (rp) related to the target variable.

[0080] Finally, the code snippets are synthesized (i.e., ...). Figure 3(Lines 6-23 in the code) The process is as follows: 1. The algorithm first generates an initial code snippet (the initial code snippet only contains the target function, other functions mentioned in the static alarm data, and related dependent functions. This generation process is based on the information in the static alarm data and the structured information of the source code generated by srcML to obtain all related functions, and then extract the code of the related functions and put it into the initial code snippet). The initial code snippet contains the target function, related functions, and entry function. 2. The algorithm traverses each parameter of the target function and generates declaration statements and assignment statements for each parameter (the type of each parameter can be known from the source code of the target function, and then declaration statements are generated according to these types. The assignment statement needs to first calculate the memory size required by the parameter, and then allocate memory for assignment). 3. For the currently traversed parameter, if the parameter is a non-structure type parameter, it can be directly declared and assigned; if the parameter is a structure type parameter, it is necessary to further consider whether it is related to the target variable and select different generation strategies.

[0081] The generation strategies include full assignment and simple assignment, and the detailed processes of these two strategies are as follows:

[0082] For the full assignment strategy: The full assignment strategy is applied when there is a relationship between the parameter and the target variable. Under this strategy, Fcs4sa adds the declaration statement of the parameter in the entry function of the initial code snippet.

[0083] The parameter is added to the Worklist collection as an initial element, and the following processing is performed: 1. Compile the code snippet and collect variables of incomplete types based on error messages. 2. Use GDB to collect the subfields of the currently processed parameter, add declaration statements for these subfields in the entry function, and generate new code snippets. These subfields will be used as elements to replace the Worklist collection in the next round of processing. 3. After obtaining all the variables to be generated and the incomplete type variables among them, assign values ​​to these variables. Since the size of incomplete type variables is uncertain, this invention uses the smallest char type size as the memory size parameter for memory allocation and assignment when assigning values ​​to incomplete type variables to ensure that the assignment operation does not exceed the memory usage range of the variable. 4. Repeat the above processing until no new elements are replaced in the Worklist collection, i.e., the Worklist is an empty set. Finally, assign the corresponding type variable to the subfield of its parent type variable according to the type relationship.

[0084] For the simple assignment strategy: This strategy is applied when the parameter and the target variable are unrelated. Under this strategy, Fcs4sa also adds a declaration statement for the parameter in the entry function of the initial code snippet. Since this parameter is unrelated to the occurrence of bugs in terms of data flow and control flow, a simple approach is adopted: directly assigning a random value to the memory location of the parameter using the memcpy function (memorycopy). This method requires only one compilation (to determine if the parameter is an incomplete type, thus determining the assignment strategy). The memcpy function is suitable for most cases, but not for complex structures (such as pointers and fictitious functions). This invention uses a normal assignment method for complex structures to avoid causing program errors. After the above process, the final code snippet CS (i.e., the minimum compiled code snippet in this invention) is obtained.

[0085] Step S30: Perform program slicing on the minimum compiled code segment to obtain an executable code segment, and perform fuzz testing on the executable code segment to obtain the fuzz test result.

[0086] After generating the fuzzy target (i.e., the executable code snippet in this invention), a fuzzing tool is invoked to perform fuzz testing on the fuzzy target and collect the resulting crashes.

[0087] Specifically, a preset program slicing tool is determined, along with preset slicing standards and the location of the code to be sliced. The preset program slicing tool is then used to slice the smallest compiled code segment according to the preset slicing standards and the location of the code to be sliced, to obtain an executable code segment.

[0088] After obtaining the minimum compiled code snippet, the first step is to slice it. Program slicing is a technique that extracts code snippets related to specific variables or statements (slicing criteria) from the original code by analyzing the data flow and control flow dependencies in the program. The program slicing process is as follows: First, a slicing criterion is defined. In this invention, the criterion in Fcs4sa is set as the target variable, so the program slice obtains the code snippets related to the target variable. Then, a program dependency graph is constructed and analyzed to determine the code related to the target variable. Finally, these related codes are extracted to form code snippets, completing the program slicing.

[0089] The program slicing in this invention is achieved through a program slicing tool. First, the program slicing tool is downloaded and the environment is configured. The tool is then invoked via command line, and the slicing standard and the location of the code to be sliced ​​are passed to the program slicing tool as parameters to complete the slicing.

[0090] A preset fuzzing tool is determined, and the target file location corresponding to the executed code fragment is obtained; the target file location is fuzzed using the preset fuzzing tool to obtain the fuzzing result.

[0091] The fuzzing process is as follows: 1. Select the target program and determine the test scope; 2. Construct a large number of abnormal inputs through random generation; 3. Automatically inject the abnormal inputs into the target program and monitor its running status; 4. Record the input samples that trigger the abnormalities, analyze the root cause and reproduce the problem for developers to fix the vulnerability.

[0092] The fuzzing in this invention is performed using the fuzzing tool LibFuzzer. The fuzzing process is as follows: Download LibFuzzer and configure the environment. Then, an entry function needs to be written, which is generated during the code snippet generation process. Finally, LibFuzzer is called via the command line, passing the file location of the code snippet as a parameter to LibFuzzer to complete the fuzzing. The fuzzing results will be displayed in the command line, and Fcs4sa will further classify the alerts based on the fuzzing results.

[0093] Step S40: Perform alarm classification processing on the fuzzy test results to obtain alarm classification results. The alarm classification results include true positive alarms and false positive alarms.

[0094] After Fcs4sa finishes running, it will directly provide information on whether a crash with the same cause as the bug in the alert occurred at the target location (i.e., the line of code where the bug mentioned in the alert occurred). If so, it will provide detailed information about the crash (i.e., the fuzz test results in this invention).

[0095] For alarm classification processing: it can be based on whether there is a crash whose location and cause are consistent with the alarm (i.e., determine whether the cause and location of the crash in the fuzz test results are consistent with the cause and location of the crash in the alarm data). Furthermore, alarms are divided into possible true positives (i.e., true positive alarms in this invention) and possible false positives (i.e., false positive alarms in this invention). In addition to true positive alarms and false positive alarms, the alarm classification results can also include two types: unreachable and uncompileable.

[0096] Specifically, the fuzz test results are used to determine whether a data corruption has occurred at the target file location. If a data corruption has occurred at the target file location, and the cause of the data corruption is consistent with the cause of the vulnerability in the static alert data, then the fuzz test result is determined to be a true positive alert. If no data corruption has occurred at the target file location, then the fuzz test result is determined to be a false positive alert.

[0097] Understandably, static alert data can be classified based on the crash results (i.e., the fuzz test results in this invention). If a crash is triggered at the location where the bug occurs in the alert (the target location), and the cause of the crash is the same as the cause in the fuzz test results, then the alert is classified as a possible true positive. If the fuzz test at the target location is performed, but no crash with the same cause is triggered, then the alert is classified as a possible false positive. If the fuzz test is not performed at the target location, then it is classified as unreachable. If the generated code snippet shows a compilation failure, then it is classified as incompilable.

[0098] Furthermore, many of the alerts generated by static analysis tools may be incorrect. The purpose of Fcs4sa in this invention is to eliminate these incorrectly judged alerts and only filter out the alerts that are classified as possible true positives (i.e., true positive alerts in this invention) and send them to the developers for further confirmation, thereby reducing the workload of the developers.

[0099] Experimental results:

[0100] This invention selected 30 buffer overflow alerts from the Helium dataset as the experimental dataset, including 2 true positives and 28 false positives. The dataset was then compared with dynamic tools Helium, Unit+KLEE, and FUZZSLICE (all of which are fuzz testing related tools).

[0101] Regarding the effectiveness of code snippet generation: Table 1 shows the effectiveness of code snippets generated by each tool. The Unit+KLEE method suffers from a large number of failures in generating executable code snippets, with a success rate of only 40%. While Helium successfully generated 29 executable code snippets, only 20 of these snippets are valid. This is because the remaining 9 snippets contain switch blocks, and Helium's processing of switch blocks is incomplete; it only generates the conditional switch statement, missing the branching content. This results in semantic discrepancies with the source code, leading to inaccurate results and thus invalid code snippets. In contrast, FUZZSLICE and Fcs4sa can generate executable and valid code snippets for all alerts, and their efficiency is higher than Helium and Unit+KLEE. This is because Helium and Unit+KLEE generate code snippets by generating code with the same semantics as the source code. However, this method is prone to generating invalid code snippets due to incomplete or inaccurate semantic parsing, and Helium has flaws in its handling of switch block generation. Fcs4sa and FUZZSLICE utilize a compiler and GDB to extract the necessary code from the source code and generate the call code for the target function, thus producing valid code snippets. The main processing involves generating valid compilation commands and correct definitions, which is simpler than Helium's semantic parsing, making it easier to synthesize valid code snippets. Furthermore, due to optimizations in parameter generation, Fcs4sa is more efficient than FUZZSLICE.

[0102] Table 1: Validity of Code Snippet Generation

[0103]

[0104] Table 2: Validity of Alarm Confirmation

[0105]

[0106] Regarding accuracy and recall: As shown in Table 2 (TP (true positive) in Table 2 refers to the number of alerts judged as true positives by the tool, and RTP (real true positive) refers to the number of alerts judged as TPs by the tool that are actually true positives, i.e., the number of correct judgments; similarly, FP and RFP are the number of false positive alerts), Fcs4sa outperformed the other three dynamic methods in accuracy. Specifically, Fcs4sa correctly identified 2 true positive alerts and 18 false positive alerts. In contrast, Unit+KLEE identified only 1 true positive alert and 10 false positive alerts, Helium identified 1 true positive alert and 13 false positive alerts, and FUZZSLICE identified 2 true positive alerts and 14 false positive alerts. This is mainly because Unit+KLEE and Helium generated many invalid code snippets. The UK (unknown) results are due to invalid code snippets or the dynamic test failing to cover the target location, and Fcs4sa had significantly fewer UK results than Helium and Unit+KLEE. Furthermore, due to the use of procedural slicing to prune irrelevant paths, Fcs4sa's fuzzing test can more easily cover the target location, resulting in fewer UKs than FUZZSLICE. These results demonstrate that Fcs4sa achieves the best experimental performance.

[0107] In summary, Fcs4sa achieves automatic confirmation of static alerts by generating executable code snippets for targeted fuzzing. Fcs4sa improves the efficiency of code snippet generation by introducing parameter generation optimization strategies and performs program slicing on the code snippets to reduce irrelevant paths, thus improving fuzzing efficiency. Compared to other methods, Fcs4sa is more efficient and has advantages in both the success rate of generating code snippets and fuzzing target code lines, as well as the accuracy of alert confirmation.

[0108] Furthermore, such as Figure 4 As shown, based on the above-described static false alarm confirmation method based on fuzz testing, the present invention also provides a static false alarm confirmation system based on fuzz testing, wherein the static false alarm confirmation system based on fuzz testing includes:

[0109] The preprocessing module 51 is used to obtain static alarm data corresponding to the target source code, and to preprocess the static alarm data to obtain a preprocessing result;

[0110] The correlation analysis module 52 is used to perform correlation analysis on the preprocessing results, obtain the correlation analysis results, and construct the minimum compiled code fragment based on the preprocessing results and the correlation analysis results.

[0111] The fuzzing module 53 is used to perform program slicing on the minimum compiled code fragment to obtain an executable code fragment, and to perform fuzzing on the executable code fragment to obtain a fuzzing result.

[0112] The alarm classification module 54 is used to perform alarm classification processing on the fuzz test results to obtain alarm classification results.

[0113] Furthermore, such as Figure 5 As shown, based on the above-mentioned static false alarm confirmation method and system based on fuzz testing, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 5 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0114] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard disk or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores a fuzz-based static false alarm confirmation program 40, which can be executed by the processor 10 to implement the fuzz-based static false alarm confirmation method of this application.

[0115] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the static false alarm confirmation method based on fuzz testing.

[0116] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display 30 is used to display information on the terminal and to display a visual user interface.

[0117] In one embodiment, the steps of the fuzz-based static false alarm confirmation method are implemented when the processor 10 executes the fuzz-based static false alarm confirmation program 40 in the memory 20.

[0118] In summary, this invention provides a static false alarm confirmation method, system, and terminal based on fuzz testing. The method includes: acquiring static alarm data corresponding to the target source code, preprocessing the static alarm data to obtain a preprocessing result; performing correlation analysis on the preprocessing result to obtain a correlation analysis result, and constructing a minimal compiled code fragment based on the preprocessing result and the correlation analysis result; performing program slicing on the minimal compiled code fragment to obtain an executable code fragment, and performing fuzz testing on the executable code fragment to obtain a fuzz testing result; and performing alarm classification processing on the fuzz testing result to obtain an alarm classification result. This invention generates a minimal compiled code fragment by preprocessing and performing correlation analysis on static alarm data, and then performs program slicing, fuzz testing, and alarm classification processing on the minimal compiled code fragment to finally obtain an alarm classification result, which can effectively improve the accuracy and efficiency of automatic confirmation of static alarms.

[0119] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0120] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.

[0121] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A static false alarm confirmation method based on fuzz testing, characterized in that, The static false alarm confirmation method based on fuzz testing includes: Obtain the static alarm data corresponding to the target source code, and preprocess the static alarm data to obtain the preprocessing result; The preprocessing results include static alarm data, compilation commands, structured information, and target variables; The process of obtaining static alarm data corresponding to the target source code and preprocessing the static alarm data to obtain preprocessing results specifically includes: Identify the target program, and download and configure the static analysis tool on the target program; The target source code is identified, and static analysis is performed on the target source code using the static analysis tool to obtain the static alarm data; The compilation commands are generated using the Bear tool, and the structured information of the target program is generated using srcML. Obtain the location of the vulnerability when it occurs in the static alarm data, and traverse the target source code according to the location of the vulnerability until the traversed characters are non-spaces or non-special symbols, and obtain the target variable; A correlation analysis is performed on the preprocessing results to obtain the correlation analysis results, and a minimum compiled code snippet is constructed based on the preprocessing results and the correlation analysis results. The step of performing correlation analysis on the preprocessing results to obtain correlation analysis results, and constructing a minimal compiled code fragment based on the preprocessing results and the correlation analysis results, specifically includes: The target function is determined based on the structured information in the preprocessing result and the location of the vulnerability, and multiple target parameters in the target function are obtained. Calculate the correlation between each target parameter and the target variable to obtain the correlation analysis results; Obtain the parameter type corresponding to each target parameter, and assign values ​​to each target parameter according to the parameter type and the correlation analysis results to obtain the minimum compiled code fragment; The minimum compiled code fragment is sliced ​​to obtain an executable code fragment, and the executable code fragment is then subjected to fuzz testing to obtain the fuzz test results. The fuzzy test results are then processed for alarm classification to obtain alarm classification results.

2. The static false alarm confirmation method based on fuzz testing according to claim 1, characterized in that, The correlation analysis results include control dependencies and data dependencies; The process of calculating the correlation between each target parameter and the target variable to obtain correlation analysis results further includes: The basic block in which the target variable is located is determined, and the basic block is marked to obtain the target basic block; Determine the entry node and obtain multiple path constraints from the entry node to the target basic block; If the target parameter is included in multiple path constraints, then it is determined that the target parameter and the target variable have the control dependency relationship. Determine the variable nodes and construct a target set based on the variable nodes and the target parameters; Determine whether the parameters in the target set reach the target basic block. If so, determine that the target parameters and the target variables have the data dependency relationship.

3. The static false alarm confirmation method based on fuzz testing according to claim 1, characterized in that, The step of obtaining the parameter type corresponding to each target parameter, and assigning values ​​to each target parameter according to the parameter type and the correlation analysis results to obtain the minimum compiled code fragment, specifically includes: Obtain the parameter type corresponding to each objective parameter in the objective function; If the parameter type is a non-structure type, then a declaration statement and an assignment statement are generated for each target parameter, and the minimum compiled code fragment is obtained based on the declaration statement and the assignment statement; If the parameter type is a structure type, then the assignment process is performed using either a full assignment strategy or a simple assignment strategy based on the correlation analysis results to obtain the minimum compiled code fragment.

4. The static false alarm confirmation method based on fuzz testing according to claim 1, characterized in that, The process of slicing the minimum compiled code fragment to obtain an executable code fragment, and then performing fuzz testing on the executable code fragment to obtain fuzz test results, specifically includes: Determine the preset program slicing tool, and determine the preset slicing standard and the location of the code to be sliced; The preset program slicing tool is used to slice the smallest compiled code segment according to the preset slicing standard and the location of the code to be sliced, to obtain the executable code segment; Determine the preset fuzzing tool and obtain the target file location corresponding to the executed code fragment; The target file location is fuzzed using the preset fuzzing tool to obtain the fuzzing test result.

5. The static false alarm confirmation method based on fuzz testing according to claim 4, characterized in that, The alarm classification results include true positive alarms and false positive alarms; The alarm classification process performed on the fuzzy test results to obtain alarm classification results specifically includes: Based on the fuzz test results, determine whether a data corruption has occurred at the target file location; If a data corruption occurs at the target file location, and the cause of the data corruption is consistent with the cause of the vulnerability in the static alarm data, then the fuzz test result is determined to be a true positive alarm. If no data corruption occurs at the target file location, the fuzz test result is determined to be a false positive alarm.

6. A static false alarm confirmation system based on fuzz testing, characterized in that, The fuzz-based static false alarm confirmation system is applied to the fuzz-based static false alarm confirmation method according to any one of claims 1-5, wherein the fuzz-based static false alarm confirmation system comprises: The preprocessing module is used to obtain static alarm data corresponding to the target source code and preprocess the static alarm data to obtain the preprocessing result; A correlation analysis module is used to perform correlation analysis on the preprocessing results, obtain correlation analysis results, and construct a minimum compiled code fragment based on the preprocessing results and the correlation analysis results. The fuzzing module is used to perform program slicing on the minimum compiled code fragment to obtain an executable code fragment, and to perform fuzzing on the executable code fragment to obtain fuzzing results. The alarm classification module is used to perform alarm classification processing on the fuzz test results to obtain alarm classification results.

7. A terminal, characterized in that, The terminal includes: a memory, a processor, and a fuzz-based static false alarm confirmation program stored in the memory and executable on the processor. When the fuzz-based static false alarm confirmation program is executed by the processor, it implements the steps of the fuzz-based static false alarm confirmation method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a static false alarm confirmation program based on fuzz testing, which, when executed by a processor, implements the steps of the static false alarm confirmation method based on fuzz testing as described in any one of claims 1-5.

Images