A configurable system vulnerability reproduction system and reproduction method

Abstract

The present invention provides a similarity-based configurable system vulnerability reproduction method and system, which establishes a control relationship between software configuration options and source code by analyzing the compilation system and source code; uses default software configuration options to compile and generate default binary, uses BinDiff binary difference analysis software to analyze the difference between the default binary and the target binary, and maps the difference to the source code; combines the control relationship between the software configuration options and the source code to confirm whether the binary difference is caused by the software configuration options, and finally determines the software configuration options used by the target binary. The method and system can effectively infer the software configuration options used by the crash binary under the condition of missing installation / configuration information, saving the time required for software developers and security analysts to reproduce vulnerabilities.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology vulnerability reproduction, and more specifically, relates to a configurable system vulnerability reproduction system and a reproduction method. Background Art

[0002] With the rapid development of the Internet, software systems have played an increasingly important role in people's daily lives. In the global information security game, the security of software systems has become particularly important. Although software vendors have established their own testing teams and used some vulnerability mining techniques (such as fuzz testing) to find existing vulnerabilities in existing software, as software becomes increasingly complex, features increase, and release cycles shorten, the testing team can only find and fix some vulnerabilities before the new version is released. Once these vulnerabilities are discovered and used maliciously, all users of the software will be affected, and even cause privacy leaks and property losses.

[0003] Vulnerability reproduction is a key step for developers to debug and fix software vulnerabilities. Completing local vulnerability reproduction is very important. On the one hand, developers can detect the status information when the software crashes in detail to find the cause of the error. On the other hand, local testing can also check whether the vulnerability has been successfully fixed.

[0004] In particular, the lack of installation / configuration information in configurable systems has a great impact on vulnerability reproduction. First, open source software plays a key role in today's computer systems. Some open source software supports many customizable functions and can be compiled according to your own needs during compilation; second, highly configurable software systems cannot accurately predict software compilation options. More importantly, there are some vulnerabilities that are related to software configuration options, and such vulnerabilities will only exist in specific software configuration options. Abal pointed out in the article that people do not have a deep understanding of program errors caused by software configuration options. Due to large software such as the Linux Kernel and the lack of tools to analyze software configuration options, once problems occur in certain specific configuration options, it will be difficult for developers to locate and fix them. Therefore, there is an urgent need for an effective method to recover installation / configuration information in configurable systems.

[0005] Scholars at home and abroad have proposed many techniques and tools for vulnerability reproduction. They can be roughly divided into two directions: 1. Vulnerability repair and diagnosis, focusing more on the reproduction of vulnerability operation results, such as how to generate input files that can trigger crashes; 2. The impact of different information on vulnerability reproduction during vulnerability reproduction. When key information is missing, vulnerability reproduction may fail.

[0006] There are two common methods for fixing and diagnosing vulnerabilities: "record-replay" based on dynamic information and memory snapshots based on static information.

[0007] Record-reproduce method based on dynamic information. One part of the method is to instrument the entry of each method, record the function call relationship and parameter position information of the program at runtime, and use the recorded information to generate test cases to trigger the crash when the program crashes. The other part collects the status information of the program during execution, and then uses symbolic execution to simulate the execution based on the collected information, and uses symbolic execution technology to solve constraints, and then find possible test inputs, and then combine ad-hoc search strategies to generate test inputs to trigger crashes.

[0008] A memory snapshot method based on static information. This method avoids the need to instrument the software for the "record-reproduce" work. It only uses the memory stack information (core dump) collected by the operating system itself when the process crashes, and combines this information with the genetic testing tool EvoSuite to generate a test set that can trigger the crash. By using memory stack information, it gets rid of the reliance on instrumentation with high performance overhead, reduces the system's runtime overhead, and improves operating efficiency.

[0009] Missing information in vulnerability reproduction may lead to failure in vulnerability reproduction. Dhaliwal collected a large number of crash reports and vulnerabilities from 10 Firefox releases for research and analyzed the impact of stack information on vulnerability reproduction. Mu conducted large-scale and in-depth reproduction experiments on real-world vulnerabilities, explored solutions to improve reproducibility, and for the first time deeply understood the difficulty of reproducing vulnerabilities reported by the public. Through quantitative and qualitative analysis methods, it is pointed out that there are still many key factors in vulnerability reports that lead to failure in vulnerability reproduction (such as installation information, how to compile executable files containing vulnerabilities from source code), and proposed some standardized vulnerability reporting methods.

[0010] Unfortunately, almost all work in vulnerability repair and diagnosis assumes that there is an executable file that can cause a crash. However, in order to adapt to a wider user population, software systems usually contain a variety of configurable options for people with different needs. Therefore, there may be many executable files compiled by the system, which makes it difficult for software developers to easily obtain executable files that can cause crashes. Especially for open source systems, users can customize software configuration options according to their own needs, resulting in a large gap between the source code and the executable file that can cause a crash.

[0011] This shows that in a configurable system, when installation / configuration information is missing, vulnerability reproduction becomes more difficult. Summary of the invention

[0012] Purpose of the invention: In order to overcome the problem that it is difficult to reproduce vulnerabilities in a configurable system when installation / configuration information is missing, the present invention provides a configurable system vulnerability reproduction system and a reproduction method to infer the software configuration options used by the crash binary.

[0013] In order to solve the above technical problems, the present invention discloses a configurable system vulnerability reproduction system based on similarity, comprising:

[0014] The difference analysis module extracts binary differences and maps the differences to the source code level; the extracted binary differences use the comparison data generated by the binary difference analysis software BinDiff.

[0015] Feature extraction module, including source code feature extraction and binary feature extraction. Source code feature extraction is based on the abstract syntax tree VAST generated by the source code analysis tool TypeChef, and the constraint dependency of the code is extracted on the abstract syntax tree VAST. Binary feature extraction is based on the binary disassembly tool IDA (Interactive Disassembler Professional) to extract binary features; the features include basic strings, constants, and function calls;

[0016] The matching module uses the features generated by the feature extraction module for matching, including coarse-grained function-level feature matching and fine-grained combined feature matching.

[0017] The difference analysis module is used to extract the differences between the default binary and the target binary and map the differences to the source code level. The differences are reflected at the function level.

[0018] Obtain a database of binary differences through BinDiff, use Python to extract and analyze the information in the database, use the networkx function library to model the information in the database, build a function control flow graph with basic blocks as nodes, and record the difference nodes. Find the shortest common parent node and the shortest common child node of the difference node so that the binary difference can be mapped to the source code using the debugging information. The binary and source code correspondence uses the default binary debugging information to control the binary difference within a certain range of the source code. The so-called basic block refers to a program: a sequence of statements executed sequentially, in which there is only one entry and one exit, the entry is the first statement, and the exit is the last statement. Generally speaking, it is usually used as the basic unit of program analysis.

[0019] Feature extraction module, used to extract source code and binary features;

[0020] Source code feature extraction is completed by traversing the VAST tree. Different features can be extracted according to different needs. Function matching requires some features of the entire function, so the traversal of VAST starts from the function entry, traverses the entire function, and extracts features such as strings. In order to increase the matching accuracy, conditional branch (such as if statement) structural features are extracted in fragments with a smaller code range. When extracting features, each feature needs to record the corresponding constraints so that constraints can be solved when matching functions.

[0021] Binary feature extraction uses IDA as a disassembly tool. IDA provides a Python programming interface, which can be used to write scripts to extract the required features. When extracting binary features, the Python software library (networkx package) is used to encapsulate the IDA data. For instructions in the binary, only key instructions are retained, such as comparison instructions (cmp), strings, constants, etc., and the rest of the instructions are removed. The retained instructions are connected according to the original graph structure. At this time, a graph structure containing only key instructions can be obtained. In the subsequent matching process of this article, matching will be performed on this graph structure.

[0022] Feature matching is to search for the existence of source code features in the binary. For simple features, you only need to search on the binary graph and traverse all nodes to match the source code features. Networkx can be used to easily traverse all nodes of the graph. For combined features, because the combined features have certain structural information, building the combined features into a small graph structure is equivalent to searching the source code graph structure in the binary graph structure. It is worth noting that when matching combined features, the comparison instruction (cmp) is used as the matching root node, and the judgment conditions and content are matched in sequence. This has the benefit of improving matching efficiency.

[0023] Feature matching will match source code with binary, and the existence of source code has certain constraints, which are composed of some macro expressions. Design and implement lexical analysis and solution of constraints, build AST for each constraint, the first step is to divide words and operators, the second step is to use the grammar of logical expressions to parse the expression into AST tree, and finally traverse the AST tree to generate the input format that conforms to the constraint solver (Z3), and finally get the value that each macro should take, which can finally correspond to the software configuration options.

[0024] The present invention provides a configurable system vulnerability reproduction method based on similarity, comprising the following steps:

[0025] Step 1: Analyze the compilation system and source code, and establish the control relationship between software configuration options and source code;

[0026] Step 2: Build a local binary from source code using the same compiler-related information and default software configuration options as the crash binary as the default binary, and the crash binary as the target binary;

[0027] Step 3, using BinDiff binary difference analysis software to analyze the difference between the default binary and the target binary, and map the difference to the source code;

[0028] Step 4: Extract source code and match binary features to confirm whether the binary difference is caused by software configuration options, and finally determine the software configuration options used by the target binary.

[0029] In step 1, the compilation system reads the user-defined software configuration options, generates a configuration file that meets the user's configuration requirements, and finally compiles to generate a binary file. The compilation system controls the final generation of binary files in two ways: one is that the compilation system directly controls certain files in the configure script. When the user runs the command . / configure--with-lzma, the option with-lzma is turned on, and the source code files related to the option will be compiled into the binary; the other is that the compilation system will define some macros during the execution of the configure script, usually defined in the config.h file, and use conditional compilation instructions (#if, #ifdef) in the source code file to control the code related to the software configuration options. When the software is compiled, the compiler will read the value of the corresponding macro in the config.h file and choose to compile the corresponding code.

[0030] When conditional compilation controls the code related to software configuration options, macros are used as intermediaries. TypeChef is used to analyze the dependencies between all macros and code blocks in the source code, and an abstract syntax tree (VAST) containing macro nodes is generated to extract the constraint dependency conditions of the source code.

[0031] In step 2, it is assumed that the compiler-related information of the target binary is known, such as compiler, version, optimization level, etc. Use the same compiler information and default software configuration information as the target binary, and add debugging options to generate a default binary with debugging information for comparison with the target binary.

[0032] Use BinDiff to analyze the default binary and the target binary, establish the correspondence between functions, and analyze the differences between functions. All functions are divided into three categories: 1. Only in the default binary; 2. Only in the target binary; 3. Exist in both binaries, and analyze the differences in the functions.

[0033] Only in the default binary. This function only exists in the default binary. Obviously, when generating the target binary, this function should not be compiled into the binary. Therefore, first analyze the constraints of the function, and negate the constraints to prevent the function from being compiled into the target binary.

[0034] Only in the target binary. This function only exists in the target binary, which means that the function should be compiled into the target binary, but is not in the default binary. For this type of function, you can use some coarse-grained search strategies to match binary and source code features to determine which function the corresponding source code is, and then perform constraint solving to determine the constraints for the function's existence.

[0035] Exists in both binaries. If a function exists in both binaries, a more fine-grained analysis is required. First, the existence conditions of completely identical functions are extracted (constraints that need to be met for the function to be compiled into the binary), and the values ​​of the constraints are obtained through constraint solving. Then, functions that successfully match but are not completely consistent in similarity are analyzed. This type of function first performs source code analysis to see if the function is related to certain macros. If there are no macros inside the function, the difference in the function in the binary may be caused by other reasons, and the difference in the function can be considered a false positive. Secondly, if there are macros inside the function, it is necessary to further extract the difference blocks of the function in the binary.

[0036] Eventually, the differences need to be mapped to the source code, but the basic blocks that may have differences have no debugging information and cannot be mapped to the source code level (the target binary does not contain debugging information). In order to use the debugging information to find the corresponding source code, you first need to find the shortest common parent node and the shortest common child node, that is, the path from the parent node to the child node that can cover all the difference basic blocks. The parent node and the child node have a corresponding relationship in both the default binary and the target binary, and the debugging information can be used to map the binary instructions to the source code level.

[0037] In order to identify whether a macro-controlled source code exists in the binary, it is necessary to extract certain features of the binary and source code for matching, so as to verify whether the macro-controlled code exists in the binary. Feature extraction includes binary feature extraction and source code feature extraction

[0038] Analyze the source code corresponding to step 3, analyze and extract source code features on VAST, and include source code constraints; analyze the different code blocks corresponding to the binary in step 3, and use IDA to extract binary features. Source code and binary features select information such as strings, constants, function calls, and global variables, because these features are relatively simple and exist in both source code and binary, and will not be affected by compiler compilation optimization. Use features for code matching to determine whether the difference in binary code is caused by software configuration options (software configuration options can cause different codes to be compiled into the binary).

[0039] The present invention provides a similarity-based configurable system vulnerability reproduction method and system, which establishes a control relationship between software configuration options and source code by analyzing the compilation system and source code; uses default software configuration options to compile and generate default binary, uses binary difference analysis software (BinDiff) to analyze the difference between the default binary and the target binary, and maps the difference to the source code; combines the control relationship between the software configuration options and the source code to confirm whether the binary difference is caused by the software configuration options, and finally determines the software configuration options used by the target binary. The method and system can effectively infer the software configuration options used by the crash binary under the condition of missing installation / configuration information, saving the time required for software developers and security analysts to reproduce vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments, and the above and / or other advantages of the present invention will become more clear.

[0041] Figure 1 It is a schematic diagram of the overall process of a configurable system vulnerability reproduction method based on similarity according to an embodiment of the present invention;

[0042] Figure 2 A schematic diagram of the overall structure of a configurable system vulnerability reproduction system based on similarity according to an embodiment of the present invention;

[0043] Figure 3 Schematic diagram of binary difference analysis for BinDiff;

[0044] Figure 4 Schematic diagram of constraint solving.

[0045] Figure 5 Schematic diagram of converting constraint expressions into the format supported by the constraint solver (Z3). DETAILED DESCRIPTION

[0046] Vulnerability reproduction is a key step for developers to debug and fix software vulnerabilities, and it is very important to complete local vulnerability reproduction. However, in order to adapt to a wider user population, software systems usually contain a variety of configurable options for people with different needs, which means that developers have to pay attention to the software configuration options used by users when reproducing vulnerabilities locally.

[0047] The present invention assumes that compiler-related information (compiler, compiler version, optimization options, system architecture) used by the binary file that can generate the crash is known, and the binary file that can generate the crash is available, which should contain code segment information even if it cannot be executed.

[0048] The present invention provides a similarity-based configurable system vulnerability reproduction method, comprising: analyzing a compilation system and source code, establishing a control relationship between software configuration options and source code; using the same compiler-related information and default software configuration options as a crash binary (target binary), building a default binary from the source code, using BinDiff binary difference analysis software, analyzing the difference between the default binary and the target binary, and mapping the difference to the source code; extracting the source code and matching the binary features, confirming whether the binary difference is caused by the software configuration options, and finally determining the software configuration options used by the target binary.

[0049] See also Figure 1 , Figure 1 FIG. 1 is a schematic diagram of the overall process of a configurable system vulnerability reproduction method based on similarity according to an embodiment of the present invention. Figure 1 As shown, the binary vulnerability code cloning detection method includes:

[0050] Step 1: Analyze the compilation system and source code, and establish the control relationship between software configuration options and source code;

[0051] The compilation system reads the user-defined software configuration options, generates configuration files that meet the user's configuration requirements, and finally compiles to generate binary files. There are two ways for the compilation system to control the final generation of binary files: one is that the compilation system directly controls certain files in the configure script. When the user turns on the option with-lzma, these source code files will be compiled into the binary; the other is that the compilation system will define some macros during the execution of the configure script, usually defined in the config.h file, and use conditional compilation instructions (#if, #ifdef) in the source code file to control the code related to the software configuration options. When the software is compiled, the compiler will read the value of the corresponding macro in the config.h file and choose to compile the corresponding code.

[0052] When conditional compilation controls the code related to software configuration options, macros are used as intermediaries. TypeChef is used to analyze the dependencies between all macros and code blocks in the source code, and an abstract syntax tree (VAST) containing macro nodes is generated to extract the constraint dependency conditions of the source code.

[0053] Step 2: Build a local binary from source code using the same compiler-related information and default software configuration options as the crashing binary.

[0054] Assume that compiler-related information of the target binary is known, such as compiler, version, optimization level, etc. Use the same compiler information and default software configuration information as the target binary, and add debugging options to generate a default binary with debugging information for comparison with the target binary.

[0055] Step 3, using BinDiff binary difference analysis software to analyze the difference between the default binary and the target binary, and map the difference to the source code;

[0056] Use BinDiff to analyze the default binary and the target binary, establish the correspondence between functions, and analyze the differences between functions. All functions are divided into three categories: 1. Only in the default binary; 2. Only in the target binary; 3. Exist in both binaries, and analyze the differences in the functions.

[0057] Only in the default binary. This function only exists in the default binary. Obviously, when generating the target binary, this function should not be compiled into the binary. Therefore, first analyze the constraints of the function, and negate the constraints to prevent the function from being compiled into the target binary.

[0058] Only in the target binary. This function only exists in the target binary, which means that the function should be compiled into the target binary, but is not in the default binary. For this type of function, you can use some coarse-grained search strategies to match binary and source code features to determine which function the corresponding source code is, and then perform constraint solving to determine the constraints for the function's existence.

[0059] Exists in both binaries. If a function exists in both binaries, a more fine-grained analysis is required. First, the existence conditions of completely identical functions are extracted (constraints that need to be met for the function to be compiled into the binary), and the values ​​of the constraints are obtained through constraint solving. Then, functions that successfully match but are not completely consistent in similarity are analyzed. This type of function first performs source code analysis to see if the function is related to certain macros. If there are no macros inside the function, the difference in the function in the binary may be caused by other reasons, and the difference in the function can be considered a false positive. Secondly, if there are macros inside the function, it is necessary to further extract the difference blocks of the function in the binary.

[0060] like Figure 3 As shown, through BinDiff, we can see the difference between the two functions at the basic block level. The basic block labeled 1 is present in both binaries, the basic block labeled 2 is present only in the default binary, and the basic block labeled 3 is present only in the target binary.

[0061] Eventually, the differences need to be mapped to the source code, but the basic blocks that may have differences have no debugging information and cannot be mapped to the source code level (the target binary does not contain debugging information). In order to use the debugging information to find the corresponding source code, you first need to find the shortest common parent node and the shortest common child node, that is, the path from the parent node to the child node that can cover all the difference basic blocks. The parent node and the child node have a corresponding relationship in both the default binary and the target binary, and the debugging information can be used to map the binary instructions to the source code level.

[0062] Step 4: extract the source code and match it with the binary features to confirm whether the binary difference is caused by the software configuration options, and finally determine the software configuration options used by the target binary;

[0063] In order to identify whether a macro-controlled source code exists in the binary, it is necessary to extract certain features of the binary and source code for matching, so as to verify whether the macro-controlled code exists in the binary. Feature extraction includes binary feature extraction and source code feature extraction

[0064] Analyze the source code corresponding to step 3, analyze and extract source code features on VAST, and include source code constraints; analyze the different code blocks corresponding to the binary in step 3, and use IDA to extract binary features. Source code and binary features select information such as strings, constants, function calls, and global variables, because these features are relatively simple and exist in both source code and binary, and will not be affected by compiler compilation optimization. Use features for code matching to determine whether the difference in binary code is caused by software configuration options (software configuration options can cause different codes to be compiled into the binary).

[0065] like Figure 4 As shown, after the binary features are matched with the source code features, the dependency conditions required for each source code are determined, and a constraint solver is used to obtain a satisfiable solution. Based on the relationship between the software configuration options and the source code / macros analyzed in step 1, it is inferred whether the software configuration option is enabled.

[0066] Figure 2 A schematic diagram of the overall process of a configurable system vulnerability reproduction system based on similarity according to an embodiment of the present invention is shown in FIG. Figure 2 The present invention provides a configurable system vulnerability reproduction system based on similarity, including a feature difference analysis module, a feature extraction module and a matching module. The configurable system vulnerability reproduction method based on similarity in any of the above embodiments is implemented through the cooperation of each module. The specific implementation is as follows:

[0067] The difference analysis module is used to extract the differences between the default binary and the target binary and map the differences to the source code level. The differences are reflected at the function level.

[0068] Specifically, we use BinDiff to obtain a binary difference database, use Python to extract and analyze the information in the database, use the networkx library to model the information in the database, build a function control flow graph with basic blocks as nodes, and record the difference nodes. Figure 3 As shown, the shortest common parent node and the shortest common child node of the difference node are found so as to correspond the binary difference to the source code using the debugging information. The correspondence between binary and source code uses the default debugging information in the binary to control the binary difference within a certain range of the source code.

[0069] Feature extraction module, used to extract source code and binary features;

[0070] Specifically, source code feature extraction is completed by traversing the VAST tree, and different features can be extracted according to different needs. Function matching requires some features of the entire function, so the traversal of VAST starts at the function entry, traverses the entire function, and extracts features such as strings. In order to increase the matching accuracy, if structure features are extracted in fragments with a smaller code range, and the traversal entry position is the if node. When extracting features, each feature needs to record the corresponding constraints so that constraints can be solved when matching functions.

[0071] Binary feature extraction uses IDA as a disassembly tool. IDA provides a Python programming interface, which can be used to write scripts to extract the required features. When extracting binary features, the Python software library (networkx package) is used to encapsulate the IDA data. For instructions in the binary, only key instructions are retained, such as comparison instructions (cmp), strings, constants, etc., and the rest of the instructions are removed. The retained instructions are connected according to the original graph structure. At this time, a graph structure containing only key instructions can be obtained. In the subsequent matching process of this article, matching will be performed on this graph structure.

[0072] The matching module is used to match source code with binary features and solve constraints on successfully matched source code to ultimately obtain software configuration options.

[0073] Feature matching is to search for the existence of source code features in the binary. For simple features, you only need to search on the binary graph and traverse all nodes to match the source code features. Networkx can be used to easily traverse all nodes of the graph. For combined features, because the combined features have certain structural information, building the combined features into a small graph structure is equivalent to searching the source code graph structure in the binary graph structure. It is worth noting that when matching combined features, the cmp instruction is used as the matching root node, and the judgment conditions and content are matched in sequence. This has the benefit of improving matching efficiency.

[0074] Feature matching will match source code with binary, and the existence of source code has certain constraints, which are composed of some macro expressions. Design and implement lexical analysis and solution of constraints, build AST for each constraint, the first step is to divide words and operators, the second step is to use the grammar of logical expressions to parse the expression into AST tree, and finally traverse the AST tree to generate the input format that meets the constraint solver (Z3), such as Figure 5 As shown. Finally, the value of each macro will be obtained, which can eventually correspond to the software configuration options.

[0075] Example

[0076] It is necessary to take a specific vulnerability as an example to explain the process of the present invention in the form of specific steps and to specify the contents of each algorithm.

[0077] To facilitate understanding of the method in any embodiment, taking CVE-2018-14567 as an example, the inference process of software configuration options is described in detail:

[0078] The first step is to analyze the compilation system and source code and establish the control relationship between software configuration options and source code.

[0079] Analyze the compilation system and configure script files. Each software configuration option has a corresponding variable in the configure script. The variable will define the macro in the configuration file at runtime. The macro is generally a conditional compilation variable that controls a specific code block in the source code. For example, the software configuration option with-lzma corresponds to the variable WITH_LZMA in the configure script. The script defines the macro LIBXML_LZMA_ENABLED according to the value of the variable WITH_LZMA at runtime.

[0080] Analyze the relationship between macros and source code, use TypeChef to analyze all codes and generate VAST, and record the constraint relationship between each VAST node and macro, that is, the constraint conditions that the code needs to meet when it is compiled into the binary during conditional compilation, and finally establish the control relationship between software configuration options and source code. For example: in the function xmlParserInputBufferGrow, the macro LIBXML_LZMA_ENABLED controls the entire conditional branch statement, so that the software configuration option with-lzma can be turned on, and the conditional branch statement will be compiled into the binary.

[0081] In the second step, compile the default binary locally using the same compilation options as the target binary and using the default software configuration options.

[0082] The third step is to use BinDiff binary difference analysis software to analyze the difference between the default binary and the target binary, and find out the difference between the default binary and the target binary in the function, extract the specific difference code block, and map the difference to the specific line number of the source code. Figure 3 Shows the function-level differences between the default binary and the target binary. Using debug information, the differences can be mapped to source code lines: 3236-3259.

[0083] The fourth step is to confirm whether the binary difference is caused by the software configuration option. Analyze the code blocks related to the macro within the source code line number range, extract the features of the source code and binary difference code blocks within the range and match them. If the match is successful, extract the constraints satisfied by the source code when compiled into the binary, and finally determine the software configuration option. For example: the features extracted from the source code are: function call and conditional judgment branch; the features extracted from the binary are: comparison instruction (cmp) and function call instruction (call). At this time, the match is successful, indicating that the source code fragment should be compiled into the binary, and the constraint satisfied by the fragment is: LIBXML_LZMA_ENABLED=1. Combined with the relationship between the software configuration options and macros analyzed in the first step, it can be determined that the difference is caused by the software configuration option with-lzma, and then it can be inferred that the software configuration option of the target binary should be: with-lzma=yes.

[0084] In summary, the present invention can effectively infer the software configuration options used by the crash binary in the absence of installation / configuration information, thereby assisting developers in reproducing vulnerabilities and saving the time required for software developers and security analysts to reproduce vulnerabilities.

[0085] The present invention provides a configurable system vulnerability reproduction system and reproduction method. There are many methods and ways to implement the technical solution. The above is only a preferred implementation of the present invention. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present invention, several improvements and modifications can be made, and these improvements and modifications should also be regarded as the protection scope of the present invention. All components not specified in this embodiment can be implemented by existing technologies.

Claims

1. A configurable system vulnerability reproduction system based on similarity, characterized in that: include: The difference analysis module extracts binary differences and maps the differences to the source code level; Feature extraction module, including source code feature extraction and binary feature extraction. Source code feature extraction is based on the abstract syntax tree VAST generated by the source code analysis tool TypeChef, and the constraint dependency of the code is extracted on the abstract syntax tree VAST. Binary feature extraction is based on the binary disassembly tool IDA to extract binary features. The matching module uses the features generated by the feature extraction module to perform matching, including coarse-grained function-level feature matching and fine-grained combined feature matching; The difference analysis module is used to extract the differences between the default binary and the target binary and map the differences to the source code level. The differences are reflected at the function level. The local binary is built from the source code as the default binary, and the crash binary is used as the target binary. Obtain a binary difference database through BinDiff, use Python to extract and analyze the information in the database, use the networkx function library to model the information in the database, build a function control flow graph with basic blocks as nodes, and record the difference nodes; Find the shortest common parent node and shortest common child node of the difference node. Use the default debugging information in the binary to correspond to the source code. Find the start and end positions of the binary difference in the source code based on the debugging information. Control the binary difference within the function of the source code, or code fragments, including code fragments of loop or branch structures. Source code feature extraction is completed by traversing the VAST tree. The traversal of VAST starts from the function entry, traverses the entire function, and extracts string features. When extracting features, each feature must record the corresponding constraint conditions for constraint solving when matching functions. Binary feature extraction uses the binary disassembly tool IDA, and uses the Python software library networkx to encapsulate the data of the binary disassembly tool IDA. For the instructions in the binary, only the key instructions are retained and the rest are removed; the retained instructions are connected according to the original graph structure to obtain a graph structure containing only key instructions; the key instructions are one or more of the comparison instructions cmp, strings and constants; Feature matching is to search for source code features in the binary. For simple features, the search is performed on the binary graph, traversing all nodes to match source code features. Combine features, build an undirected graph with combined features, and search the graph structure of the source code in the binary graph structure, using the comparison instruction cmp as the matching root node, and matching the judgment conditions and content in sequence; Feature matching matches the source code with the binary, and constructs an abstract syntax tree AST for each constraint. The first step is to divide the words and operators. The second step is to use the grammar of logical expressions to parse the expression into an AST tree. Finally, the abstract syntax tree AST is traversed to generate an input format that conforms to the constraint solver Z3. The value of each macro will be obtained, which will eventually correspond to the software configuration options to reproduce the vulnerability.

2. A similarity-based configurable system vulnerability reproduction system according to claim 1, characterized in that: Binary features include strings, constants, and function calls.

3. A similarity-based configurable system vulnerability reproduction method, comprising the following steps: Step 1: Analyze the compilation system and source code, and establish the control relationship between software configuration options and source code; Step 2: Build a local binary from source code using the same compiler-related information and default software configuration options as the crash binary as the default binary, and the crash binary as the target binary; Step 3, using binary difference analysis software BinDiff to analyze the difference between the default binary and the target binary, and map the difference to the source code; Step 4: extract the source code and match it with the binary features to confirm whether the binary difference is caused by the software configuration options, and finally determine the software configuration options used by the target binary to reproduce the vulnerability; the binary features include strings, constants and function calls; In step 1, the compilation system reads the user-defined software configuration options, generates a configuration file that meets the user's configuration requirements, and finally compiles to generate a binary file; There are two ways in which the compilation system controls the final generation of binary files: one is that the compilation system directly controls the files in the configure script. When the user turns on the option with-lzma, the source code files will be compiled into the binary; the other is that the compilation system will define some macros during the execution of the configure script. These macros are defined in the config.h file, and the conditional compilation instructions #if and #ifdef are used in the source code file to control the code related to the software configuration options. When the software is compiled, the compiler will read the value of the corresponding macro in the config.h file and choose to compile the corresponding code; When conditionally compiling control and software configuration option codes, macros are used as intermediaries, and TypeChef is used to analyze the dependencies between all macros and code blocks in the source code, and an abstract syntax tree VAST containing macro nodes is generated to extract the constraint dependency conditions of the source code; In step 2, under the condition that the compiler information of the target binary is known, the same compiler information and default software configuration information as the target binary are used, and the debugging option is added to generate a default binary with debugging information for comparison with the target binary; Use BinDiff to analyze the default binary and the target binary, establish the correspondence between functions, and analyze the differences between functions; divide all functions into 3 categories: Category 1, only in the default binary; Category 2, only in the target binary; Category 3, exists in both binaries; Category 1: indicates that the function only exists in the default binary. First, the constraints of the function are analyzed, and the constraints are negated to prevent the function from being compiled into the target binary. Category 2, indicating that the function should be compiled into the target binary, but is not in the default binary; Use some coarse-grained search strategies to match binary and source code features to determine which function the corresponding source code is, and then perform constraint solving to determine the constraints of the function; Category 3 means that the function exists in both binaries, so a more fine-grained analysis is performed. First, the existence conditions of the completely identical functions are extracted, and the constraints that the function needs to meet when compiled into the binary are solved, and the values ​​of the constraints are obtained by constraint solving. Then, if the function matching is successful, the source code analysis of the Category 3 function is first performed to check whether the function is related to certain macros. If there are no macros in the function, the difference of the Category 3 function is determined to be a false positive. If there are macros in the function, the difference block of the function in the binary is further extracted. To map the difference blocks to the source code, we first need to find the shortest common parent node and the shortest common child node. The path from the parent node to the child node can cover all the difference basic blocks. The parent node and the child node have a corresponding relationship in both the default binary and the target binary. Therefore, we use the debugging information to map the binary instructions to the source code level. Analyze the source code corresponding to step 3, analyze and extract source code features on VAST, including source code constraints; analyze the different code blocks corresponding to the binary in step 3, and use IDA to extract binary features; Source code and binary features select string, constant, function call and global variable information, and use features for code matching to determine whether the difference in binary code is caused by software configuration options, thereby achieving system vulnerability reproduction.

Images