Vulnerability path-guided fuzzy test seed scheduling method and apparatus, and electronic device

Abstract

The invention relates to a vulnerability path guided fuzzy test seed scheduling method and device and electronic equipment, and the method comprises the steps: recognizing the vulnerability existence probability of each test case in the path recovery information of a plurality of test cases based on a pre-trained vulnerability path recognition model, and sending the first test case of which the probability is greater than a preset threshold value to a first preset queue, sending a second test case of which the probability is less than or equal to the preset threshold value and which triggers edge coverage to a second preset queue, and when the first test case meets a test ending condition, switching to the second test case for testing. And generating a scheduling method of a plurality of test cases according to the test result. Therefore, the problem that the vulnerability is ignored or delayed to be found in the existing coverage guide fuzzy test is solved, the test cases possibly triggering the vulnerability are identified by utilizing the vulnerability path identification model in the fuzzy test, and the test cases are preferentially tested to ensure that the vulnerability can be found in time.

Description

Technical Field

[0001] The present application relates to the field of computer software security technology, and in particular to a vulnerability path-guided fuzz test seed scheduling method, device, and electronic device. Background Art

[0002] Fuzz testing is a widely used software vulnerability discovery technology. This technology identifies potential security vulnerabilities by inputting a large number of random, malformed test cases into the target program and monitoring the behavior of the target program. Due to its easy deployment, good scalability and wide applicability, fuzz testing has become the main means of vulnerability discovery.

[0003] During the fuzz testing process, a large number of random test cases are usually used to expose as many vulnerabilities as possible. However, most of the test cases trigger repetitive program behaviors, which will lead to many invalid test cases. This will cause huge computational overhead and affect the efficiency of vulnerability mining.

[0004] In related technologies, theoretically, since the more code a test covers, the higher the possibility of discovering potential vulnerabilities, coverage-guided fuzz testing is usually used to model the fuzz testing process as a genetic algorithm, and use code coverage as an indicator to guide the fuzz testing tool to maximize the exploration of program code.

[0005] However, although the effectiveness of coverage-guided fuzz testing has been widely demonstrated and significant progress has been made in various vulnerability mining scenarios such as network protocol software, operating system kernels, and embedded firmware, existing coverage-guided fuzz testing research still has the following problems:

[0006] (1) Due to the widespread problem of path explosion, current coverage-guided fuzz testing tools usually use program edges (i.e., basic block to basic block migration) as exploration indicators. If a test case triggers a previously undiscovered program edge, it will be considered valid and retained as a seed for further testing. However, since no new program edges are introduced, the test case that still reveals a different execution path will be discarded or deferred. (2) For the retained seeds, in order to further improve the efficiency of fuzz testing, existing research has proposed optimized seed selection methods to prioritize test cases that are more likely to discover vulnerabilities. However, these methods mainly rely on intuitive heuristic methods to select seeds. For example, seeds with a large number of memory-sensitive operations in the covered code are prioritized, but this does not necessarily mean that there is a vulnerability, because some memory protection mechanisms often involve a large number of sensitive memory operations. Therefore, the above heuristic methods cannot accurately identify the complex patterns of vulnerabilities in the execution path, resulting in some test cases that are critical for triggering vulnerabilities being ignored, which urgently needs to be solved. Summary of the Invention

[0007] The present application provides a vulnerability path guided fuzz test seed scheduling method, device and electronic device to solve the problems of vulnerability being ignored or delayed in discovery in existing coverage guided fuzz testing.

[0008] The first embodiment of the present application provides a vulnerability path guided fuzz testing seed scheduling method, comprising the following steps:

[0009] Get path recovery information for multiple test cases;

[0010] Identify the probability of a vulnerability in each test case in the path recovery information based on a pre-trained vulnerability path identification model, and send a first test case whose probability is greater than a preset threshold to a first preset queue, and send a second test case whose probability is less than or equal to the preset threshold and triggers edge coverage to a second preset queue;

[0011] The first test case in the first preset queue is tested, and when the first test case in the first preset queue meets the test end condition, the second test case in the second preset queue is switched to be tested, so as to generate a scheduling method for the multiple test cases according to the test results.

[0012] According to one embodiment of the present application, before obtaining the path recovery information of the multiple test cases, the method further includes:

[0013] Build a vulnerability path identification model based on preset machine learning technology;

[0014] Acquire input information of the program execution of each test case, and track the input information to obtain path information of the program execution of each test case;

[0015] Extract features from the path information of each test case program execution, and collect existing vulnerability path information and non-vulnerability path information based on the extracted path information features, and generate a vulnerability path dataset of the existing vulnerability path information and a non-vulnerability path dataset of the non-vulnerability path information respectively;

[0016] Based on the vulnerability path data set and the non-vulnerability path data set, the vulnerability path identification model is trained using a preset training algorithm to obtain the pre-trained vulnerability path identification model.

[0017] According to one embodiment of the present application, obtaining input information of the program execution of each test case and tracking the input information to obtain path information of the program execution of each test case includes:

[0018] Setting a first number and a second number for a basic block in program execution of each test case, using the first number and the second number as subscripts of the basic block, recording the subscripts of the basic block and the basic block codes corresponding to the subscripts, and storing the basic block codes in a preset map mapping table in a preset storage method;

[0019] Obtain the first number map and the second number map of the basic block in the program execution of each test case, and combine the first number map and the second number map after the program execution of each test case is completed, match the first number map and the second number map with the preset map mapping table, and obtain the program execution instructions and execution times of the basic block in the program execution of each test case, so as to obtain the path information of the program execution of each test case according to the program execution instructions of the basic block and the execution times.

[0020] According to one embodiment of the present application, the feature extraction of the program execution path information of each test case includes:

[0021] Feature extraction is performed on the program execution path information of each test case based on a preset feature extraction method, wherein the preset feature extraction method includes structural features and statistical features.

[0022] According to one embodiment of the present application, obtaining the path recovery information of the multiple test cases includes:

[0023] Based on the secondary cache mechanism, the preset map mapping table is stored in the target memory, and a target storage space is set in the target memory to store the target map mapping table;

[0024] Determine whether a basic block is found in the target map mapping table;

[0025] If the basic block is not found in the target map mapping table, the search is transferred to the preset map mapping table to add the basic block found in the preset map mapping table to the target map mapping table, and the path recovery information of the multiple test cases is obtained based on the basic blocks in the target map mapping table.

[0026] According to one embodiment of the present application, sending the first test case whose probability is greater than the preset threshold to a first preset queue, and sending the second test case whose probability is less than or equal to the preset threshold and triggers edge coverage to a second preset queue, includes:

[0027] Allocating energy to a first test case in the first preset queue using a first energy allocation score, and increasing a first mutation count of the first test case according to the first energy allocation score, so as to increase a probability of discovering a vulnerability in the first test case according to the first mutation count;

[0028] Energy is allocated to the second test case in the second preset queue using a second energy allocation score, and a second mutation number of the second test case is increased according to the second energy allocation score, so as to increase the probability of discovering new potential vulnerabilities in the second test case according to the second mutation number.

[0029] According to the vulnerability path-guided fuzz test seed scheduling method of the embodiment of the present application, the probability of each test case having a vulnerability is identified in the path recovery information of multiple test cases based on a pre-trained vulnerability path identification model, and the first test case with a probability greater than a preset threshold is sent to a first preset queue, and the second test case with a probability less than or equal to the preset threshold and triggering edge coverage is sent to a second preset queue. When the first test case meets the test end condition, the test is switched to the second test case for testing, so as to generate a scheduling method for multiple test cases based on the test results. In this way, the problem of vulnerabilities being ignored or delayed in discovery in existing coverage-guided fuzz testing is solved. By using the vulnerability path identification model in fuzz testing to identify test cases that may trigger vulnerabilities, and giving priority to testing these test cases, it is ensured that the vulnerabilities can be discovered in a timely manner.

[0030] A second embodiment of the present application provides a vulnerability path-guided fuzz testing seed scheduling device, comprising:

[0031] The acquisition module is used to obtain the path recovery information of multiple test cases;

[0032] a filtering module, configured to identify the probability of a vulnerability in each test case in the path recovery information based on a pre-trained vulnerability path identification model, and send a first test case whose probability is greater than a preset threshold to a first preset queue, and send a second test case whose probability is less than or equal to the preset threshold and triggers edge coverage to a second preset queue;

[0033] A generation module is used to test the first test case in the first preset queue, and when the first test case in the first preset queue meets the test end condition, switch to the second test case in the second preset queue for testing, so as to generate a scheduling method for the multiple test cases according to the test results.

[0034] According to one embodiment of the present application, before obtaining the path recovery information of the multiple test cases, the obtaining module further includes:

[0035] A construction unit, used to build a vulnerability path identification model based on a preset machine learning technology;

[0036] A path tracking unit, configured to obtain input information of the program execution of each test case, and track the input information to obtain path information of the program execution of each test case;

[0037] a feature extraction unit, configured to extract features from the path information of each test case program execution, and collect existing vulnerability path information and non-vulnerability path information based on the extracted path information features, and respectively generate a vulnerability path dataset of the existing vulnerability path information and a non-vulnerability path dataset of the non-vulnerability path information;

[0038] A training unit is used to train the vulnerability path identification model based on the vulnerability path data set and the non-vulnerability path data set using a preset training algorithm to obtain the pre-trained vulnerability path identification model.

[0039] According to one embodiment of the present application, the path tracking unit includes:

[0040] a storage subunit, configured to set a first number and a second number of a basic block in program execution of each test case, use the first number and the second number as subscripts of the basic block, record the subscripts of the basic block and the basic block codes corresponding to the subscripts, and store the basic block codes in a preset map mapping table in a preset storage method;

[0041] An acquisition subunit is used to obtain the first number map and the second number map of the basic block in the program execution of each test case, and after the program execution of each test case is completed, combine the first number map and the second number map, match the first number map and the second number map with the preset map mapping table, and obtain the program execution instructions and execution times of the basic block in the program execution of each test case, so as to obtain the path information of the program execution of each test case according to the program execution instructions of the basic block and the execution times.

[0042] According to one embodiment of the present application, the feature extraction unit includes:

[0043] The extraction subunit is used to extract features from the program execution path information of each test case based on a preset feature extraction method, wherein the preset feature extraction method includes structural features and statistical features.

[0044] According to one embodiment of the present application, the acquisition module includes:

[0045] a setting unit, configured to store a preset map mapping table in a target memory based on a secondary cache mechanism, and set a target storage space in the target memory to store the target map mapping table;

[0046] A judging unit, configured to judge whether a basic block is found in the target map mapping table;

[0047] an acquisition unit, configured to transfer the search to the preset map mapping table if the basic block is not found in the target map mapping table, so as to add the basic block found in the preset map mapping table to the target map mapping table, and obtain path recovery information of the multiple test cases based on the basic blocks in the target map mapping table.

[0048] According to one embodiment of the present application, the filtering module includes:

[0049] a first allocating unit, configured to allocate energy to a first test case in the first preset queue using a first energy allocation score, and increase a first mutation count of the first test case according to the first energy allocation score, so as to increase a probability of discovering a vulnerability in the first test case according to the first mutation count;

[0050] The second allocation unit is used to allocate energy to the second test case in the second preset queue with a second energy allocation score, and increase the second mutation number of the second test case according to the second energy allocation score, so as to increase the probability of discovering new potential vulnerabilities in the second test case according to the second mutation number.

[0051] According to the vulnerability path guided fuzz test seed scheduling device of the embodiment of the present application, the probability of each test case having a vulnerability is identified in the path recovery information of multiple test cases based on a pre-trained vulnerability path identification model, and the first test case with a probability greater than a preset threshold is sent to a first preset queue, and the second test case with a probability less than or equal to the preset threshold and triggering edge coverage is sent to a second preset queue. When the first test case meets the test end condition, the second test case is switched to be tested, so as to generate a scheduling method for multiple test cases based on the test results. In this way, the problem of vulnerabilities being ignored or delayed in discovery in existing coverage-guided fuzz tests is solved. By using the vulnerability path identification model in fuzz testing to identify test cases that may trigger vulnerabilities, and giving priority to testing these test cases, it is ensured that the vulnerabilities can be discovered in a timely manner.

[0052] The third aspect of the present application provides an electronic device, comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the vulnerability path-guided fuzz testing seed scheduling method as described in the above embodiment.

[0053] A fourth aspect of the present application provides a computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable the computer to execute the vulnerability path-guided fuzzy test seed scheduling method as described in the above embodiment.

[0054] A fifth aspect of the present invention provides a computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in the above embodiment.

[0055] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0057] Figure 1 A flowchart of a vulnerability path-guided fuzz testing seed scheduling method provided according to an embodiment of the present application;

[0058] Figure 2 Schematic diagram of a path tracking process according to one embodiment of the present application;

[0059] Figure 3 A schematic diagram of a vulnerability path-guided fuzz testing seed scheduling method according to an embodiment of the present application;

[0060] Figure 4 Schematic diagram of a path information recovery process according to one embodiment of the present application;

[0061] Figure 5 This is a block diagram of an exemplary device for fuzzy testing seed scheduling guided by vulnerability paths according to an embodiment of the present application;

[0062] Figure 6 Schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0063] The following describes in detail embodiments of the present application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0064] The following describes the vulnerability path guided fuzz test seed scheduling method, device and electronic device of the embodiment of the present application with reference to the accompanying drawings. In response to the problem that vulnerabilities in the existing coverage guided fuzz test mentioned in the above background technology are ignored or delayed in discovery, the present application provides a vulnerability path guided fuzz test seed scheduling method, in which the probability of each test case having a vulnerability is identified in the path recovery information of multiple test cases based on a pre-trained vulnerability path identification model, and the first test case with a probability greater than a preset threshold is sent to a first preset queue, and the second test case with a probability less than or equal to the preset threshold and triggering edge coverage is sent to a second preset queue. When the first test case meets the test end condition, the test is switched to the second test case for testing, so as to generate a scheduling method for multiple test cases based on the test results. Thus, the problem that vulnerabilities in the existing coverage guided fuzz test are ignored or delayed in discovery is solved. By using the vulnerability path identification model in the fuzz test to identify test cases that may trigger vulnerabilities, and giving priority to testing these test cases, it is ensured that the vulnerabilities can be discovered in a timely manner.

[0065] Specifically, Figure 1 A flowchart of a vulnerability path-guided fuzz testing seed scheduling method provided in an embodiment of the present application.

[0066] like Figure 1 As shown in FIG, the vulnerability path guided fuzz testing seed scheduling method includes the following steps:

[0067] In step S101 , path recovery information of multiple test cases is obtained.

[0068] According to one embodiment of the present application, before obtaining the path recovery information of multiple test cases, it also includes: constructing a vulnerability path identification model based on a preset machine learning technology; obtaining the input information of the program execution of each test case, and tracking the input information to obtain the path information of the program execution of each test case; performing feature extraction on the path information of the program execution of each test case, and collecting existing vulnerability path information and non-vulnerability path information based on the extracted path information features, and generating a vulnerability path data set of the existing vulnerability path information and a non-vulnerability path data set of the non-vulnerability path information respectively; based on the vulnerability path data set and the non-vulnerability path data set, the vulnerability path identification model is trained using a preset training algorithm to obtain a pre-trained vulnerability path identification model.

[0069] According to one embodiment of the present application, input information of the program execution of each test case is obtained, and the input information is tracked to obtain path information of the program execution of each test case, including: setting the first number and the second number of the basic block in the program execution of each test case, and using the first number and the second number as the subscript of the basic block, while recording the subscript of the basic block and the basic block code corresponding to the subscript, and storing the basic block code in a preset map mapping table in a preset storage method; obtaining the first number map and the second number map of the basic block in the program execution of each test case, and combining the first number map and the second number map after the program execution of each test case is completed, matching the first number map and the second number map with the preset map mapping table, obtaining the program execution instructions and execution times of the basic block in the program execution of each test case, so as to obtain the path information of the program execution of each test case according to the program execution instructions and execution times of the basic block.

[0070] Among them, the preset machine learning technology and the preset training algorithm can be selected by technical personnel in this field according to actual testing requirements and are not specifically limited here.

[0071] Specifically, the embodiments of the present application aim to solve the problems existing in the existing coverage-guided fuzz testing technology and improve the efficiency of vulnerability mining. By constructing a vulnerability path identification model during the fuzz testing process, the model is used to identify seeds (i.e., test cases) that may trigger vulnerabilities, and these test cases are tested first to ensure that vulnerabilities can be discovered in a timely manner.

[0072] Specifically, if Figure 2As shown, first, the embodiment of the present application uses a preset machine learning technology to build a vulnerability path identification model, which is intended to guide the attention of the fuzz testing tool to the test cases whose execution paths may trigger vulnerabilities; secondly, during the compilation process, a first number, namely block_id, is assigned to each basic block. In order to reduce the potential risk of hash conflicts and performance overhead, a second number, namely module_id, is assigned to the module where the basic block is located. Each basic block is uniquely identified by the module_id of the module where it is located and its own block_id, and is subscripted with block_id+module_id. During the compilation process, the module_id+block_id of each basic block and the basic block code corresponding to the number are recorded, and the basic block code is stored in a preset storage method, such as key-value in the form of a local preset map mapping table. The preset map mapping table can be recorded as<id,instructions> map; finally, during the test case execution process, two maps are tracked and recorded, namely the first number map of the basic block (i.e., block_id map) and the second number map (i.e., module_id map). Among them, the subscript of the block_id map is block_id, and the array content corresponding to the subscript is the number of times the basic block is executed. The subscript of the module_id map is also block_id, but this map stores the module_id corresponding to the block_id. When the test case execution is completed, by combining the block_id map and the module_id map, a list information can be obtained, as shown below:

[0073]

[0074] Each row in the list indicates that the basic block numbered module_id+block_id has been executed count times, which is consistent with<id,instructions> Map matching can obtain the instructions contained in the execution path and the number of times these instructions are executed, so as to obtain the program execution path information of each test case based on the program execution instructions and execution times of the basic block.

[0075] According to one embodiment of the present application, feature extraction is performed on the path information of program execution of each test case, including: feature extraction is performed on the path information of program execution of each test case based on a preset feature extraction method, wherein the preset feature extraction method includes structural features and statistical features.

[0076] Among them, the preset feature extraction method can be selected by those skilled in the art according to actual testing requirements. Preferably, in the embodiment of the present application, it can include structural features and statistical features.

[0077] Specifically, in the embodiment of the present application, the program execution path information of each test case includes all instructions in the basic block executed, some of which may be irrelevant to the triggering of the vulnerability. If the complete path information is directly used, a lot of noise information may be generated, making it difficult to reflect the characteristics of the vulnerability path. Therefore, in order to more comprehensively reflect the vulnerability path characteristics, feature extraction is performed using a structural feature + statistical feature method to represent the path characteristics, as shown in Table 1:

[0078] Table 1

[0079]

[0080] For statistical features, we use function and instruction granularity to represent them. Memory operation functions are selected based on functions involved in vulnerabilities discovered in recent years by CVE (Common Vulnerabilities and Exposures) and library functions in libc, as shown in Table 2:

[0081] Table 2

[0082]

[0083]

[0084] Furthermore, the embodiment of the present application collects existing vulnerability path information and non-vulnerability path information based on the extracted path information features, and generates a vulnerability path dataset of the existing vulnerability path information and a non-vulnerability path dataset of the non-vulnerability path information, respectively.

[0085] Specifically, for the collection of vulnerability paths, first, PoCs (Proof of Concept) corresponding to vulnerabilities in open source programs are collected from references in CVE, reproducer testcases, minimized testcases, unminimized testcases in OSS-Fuzz, and issues in Github. To ensure the versatility of the training model, the collected vulnerability PoCs should cover different types of programs such as text, images, audio, video, binary, and network. Secondly, based on the path tracing method, the collected vulnerability PoCs can be used to generate the corresponding vulnerability path dataset. At the same time, from the programs involved in the collected PoCs, based on the path tracing method, paths where no vulnerabilities have been found are randomly selected as the vulnerability-free path dataset.

[0086] It should be noted that since the vulnerability path contains multiple features, and these feature dimensions involve multiple levels, the contribution of each feature to the vulnerability path determination is different, and complex patterns and relationships may be hidden therein. In order not to have a negative impact on the overall performance of fuzz testing, the selected machine learning algorithm needs to maintain a balance between model complexity and prediction accuracy. It should be able to understand the complex relationship between path features, while the model itself should avoid being overly complex. Taking the above factors into consideration, the embodiment of the present application can select a random forest model to learn vulnerability path patterns and train the vulnerability path identification model to obtain a pre-trained vulnerability path identification model.

[0087] According to one embodiment of the present application, path recovery information of multiple test cases is obtained, including: storing a preset map mapping table in a target memory based on a secondary cache mechanism, and setting a target storage space in the target memory to store the target map mapping table; determining whether a basic block is searched in the target map mapping table; if the basic block is not searched in the target map mapping table, transferring the search to the preset map mapping table to add the basic block searched in the preset map mapping table to the target map mapping table, and obtaining path recovery information of multiple test cases based on the basic blocks in the target map mapping table.

[0088] Specifically, if Figure 3 As shown, after the vulnerability path identification model is trained, the embodiment of the present application can evaluate the possibility of the execution path of the test case triggering a vulnerability during the testing process based on the trained vulnerability path identification model, and generate a vulnerability report at the same time, so as to use this possibility to guide the scheduling of test cases to give priority to test cases that may trigger vulnerabilities, so as to ensure that the fuzz testing tool has the ability to explore new code.

[0089] Specifically, if Figure 4As shown, after tracking the basic block ID and the number of times the program is executed, the generated<id,instructions> By matching the map, the program execution instructions and execution times of the basic blocks can be obtained. However, when the number of basic blocks is large, the matching process will cause a lot of overhead. For this reason, the embodiment of the present application can design a mechanism similar to the secondary cache. Since only a part of all basic blocks may be executed during the actual execution of the program, in addition to the local<id,instructions> The map is stored in the target memory, and a space is opened up in the target memory, namely the target storage space, to store the basic blocks most commonly used during program execution, namely the target map mapping table. During the path recovery process, priority is given to searching from the map of commonly used basic blocks, that is, priority is given to searching for commonly used basic blocks in the target map mapping table. If the commonly used basic blocks are not found in the target map mapping table, the search is transferred to the map of all basic blocks, that is, the search is performed in the preset map mapping table, and the commonly used basic blocks found in the preset map mapping table are added to the target map mapping table, so as to obtain path recovery information for multiple test cases based on the commonly used basic blocks in the target map mapping table.

[0090] In step S102, the probability of a vulnerability in each test case is identified in the path recovery information based on the pre-trained vulnerability path identification model, and the first test case with a probability greater than a preset threshold is sent to a first preset queue, and the second test case with a probability less than or equal to the preset threshold and triggering edge coverage is sent to a second preset queue.

[0091] According to one embodiment of the present application, a first test case with a probability greater than a preset threshold is sent to a first preset queue, and a second test case with a probability less than or equal to the preset threshold and triggering edge coverage is sent to a second preset queue, including: allocating energy to the first test case in the first preset queue with a first energy allocation score, and increasing the first mutation number of the first test case according to the first energy allocation score to increase the probability of discovering vulnerabilities in the first test case according to the first mutation number; allocating energy to the second test case in the second preset queue with a second energy allocation score, and increasing the second mutation number of the second test case according to the second energy allocation score to increase the probability of discovering new potential vulnerabilities in the second test case according to the second mutation number.

[0092] Among them, the preset threshold, the first preset queue and the second preset queue can all be selected by those skilled in the art according to actual test requirements and are not specifically limited here.

[0093] Specifically, if Figure 3As shown, based on the path recovery information, the vulnerability path identification model can predict the probability that a path may have vulnerabilities. When the probability is greater than a preset threshold, regardless of whether the test case triggers new edge coverage, the first test case with a probability greater than the preset threshold is sent to the first preset queue in the seed pool, such as the exploit queue, to ensure that those first test cases that do not trigger new edges but may have vulnerabilities in the path are not missed. These first test cases are considered to be likely to trigger vulnerabilities; at the same time, the second test cases with a probability less than or equal to the preset threshold and triggering new edge coverage are sent to the second preset queue in the seed pool, such as the explore queue. These second test cases are considered to be able to explore new code.

[0094] Furthermore, in the embodiments of the present application, with the guidance of vulnerability probability, the scheduling of test cases can focus on test cases that are more likely to trigger vulnerabilities. In addition to giving these test cases priority in selection, more energy scores (i.e., the number of times they can mutate) should be allocated to enable them to perform more mutations to fully tap the potential of these test cases to discover vulnerabilities.

[0095] Specifically, for the first test case in the exploit queue, based on the original method, energy is allocated to the first test case in the exploit queue using the first energy allocation score, and the first mutation number of the first test case is increased according to the first energy allocation score to increase the probability of discovering a vulnerability in the first test case according to the first mutation number. To this end, the energy calculation method is designed as follows:

[0096] score new (s)=score ori (s)*(1+f prob (s))

[0097] Among them, score ori (s) is the energy calculated for test case s according to the existing method, f prob (s) is the probability that test case s may trigger the vulnerability.

[0098] Furthermore, for the second test case in the explore queue, its mutation energy is still calculated according to the existing method, energy is allocated to the second test case in the explore queue using the second energy allocation score, and the second mutation times of the second test case are increased according to the second energy allocation score to increase the probability of discovering new potential vulnerabilities in the second test case according to the second mutation times.

[0099] In step S103, the first test case in the first preset queue is tested, and when the first test case in the first preset queue meets the test end condition, the second test case in the second preset queue is switched to be tested, so as to generate a scheduling method for multiple test cases according to the test results.

[0100] Specifically, if Figure 3 As shown, two queues are maintained in the seed pool, the exploit queue and the explore queue. During the testing process, the first test case in the exploit queue is given priority for testing to ensure that potential vulnerabilities in the program can be discovered as soon as possible. When all the first test cases in the exploit queue are tested and the first test case meets the test end condition, that is, no new first test case that may trigger the vulnerability is found, switch to the explore queue and select the second test case in the explore queue for testing, so that the fuzz testing tool can continue to explore new code and discover new second test cases that may have vulnerabilities.

[0101] Therefore, the embodiment of the present application utilizes known vulnerability path information to construct a vulnerability path identification model and trains the vulnerability path identification model. During the fuzz testing process, seeds that may trigger vulnerabilities are identified based on the trained vulnerability path identification model, and these seeds are tested first to ensure that vulnerabilities can be discovered in a timely manner, thereby compensating for the problems existing in the existing coverage-guided fuzz testing technology and improving the efficiency of vulnerability mining.

[0102] According to the vulnerability path-guided fuzz test seed scheduling method of the embodiment of the present application, the probability of each test case having a vulnerability is identified in the path recovery information of multiple test cases based on a pre-trained vulnerability path identification model, and the first test case with a probability greater than a preset threshold is sent to a first preset queue, and the second test case with a probability less than or equal to the preset threshold and triggering edge coverage is sent to a second preset queue. When the first test case meets the test end condition, the test is switched to the second test case for testing, so as to generate a scheduling method for multiple test cases based on the test results. In this way, the problem of vulnerabilities being ignored or delayed in discovery in existing coverage-guided fuzz testing is solved. By using the vulnerability path identification model in fuzz testing to identify test cases that may trigger vulnerabilities, and giving priority to testing these test cases, it is ensured that the vulnerabilities can be discovered in a timely manner.

[0103] Next, a fuzzy test seed scheduling device guided by vulnerability paths proposed in an embodiment of the present application will be described with reference to the accompanying drawings.

[0104] Figure 5 It is a block diagram of a vulnerability path guided fuzzy test seed scheduling device according to an embodiment of the present application.

[0105] like Figure 5 As shown, the vulnerability path guided fuzzy test seed scheduling device 10 includes: an acquisition module 100, a filtering module 200 and a generation module 300.

[0106] Wherein, the acquisition module 100 is used to obtain path recovery information of multiple test cases;

[0107] A filtering module 200 is configured to identify the probability of a vulnerability in each test case in the path recovery information based on a pre-trained vulnerability path identification model, and to send a first test case with a probability greater than a preset threshold to a first preset queue, and a second test case with a probability less than or equal to the preset threshold and triggering edge coverage to a second preset queue;

[0108] The generation module 300 is used to test the first test case in the first preset queue, and when the first test case in the first preset queue meets the test end condition, switch to the second test case in the second preset queue for testing, so as to generate a scheduling method for multiple test cases according to the test results.

[0109] According to one embodiment of the present application, before obtaining the path recovery information of multiple test cases, the obtaining module 100 further includes:

[0110] A construction unit, used to build a vulnerability path identification model based on a preset machine learning technology;

[0111] A path tracking unit is used to obtain the input information of the program execution of each test case and track the input information to obtain the path information of the program execution of each test case;

[0112] A feature extraction unit is used to extract features from the execution path information of each test case program, and collect existing vulnerability path information and non-vulnerability path information based on the extracted path information features, and generate a vulnerability path data set of the existing vulnerability path information and a non-vulnerability path data set of the non-vulnerability path information respectively;

[0113] The training unit is used to train the vulnerability path identification model based on the vulnerability path data set and the non-vulnerability path data set using a preset training algorithm to obtain a pre-trained vulnerability path identification model.

[0114] According to one embodiment of the present application, a path tracking unit includes:

[0115] a storage subunit, configured to set a first number and a second number of a basic block in program execution of each test case, use the first number and the second number as subscripts of the basic block, record the subscripts of the basic block and the basic block codes corresponding to the subscripts, and store the basic block codes in a preset map mapping table in a preset storage method;

[0116] An acquisition subunit is used to obtain the first number map and the second number map of the basic block in the program execution of each test case, and after the program execution of each test case is completed, combine the first number map and the second number map, match the first number map and the second number map with the preset map mapping table, and obtain the program execution instructions and execution times of the basic block in the program execution of each test case, so as to obtain the program execution path information of each test case according to the program execution instructions and execution times of the basic block.

[0117] According to one embodiment of the present application, the feature extraction unit includes:

[0118] The extraction subunit is used to extract features from the program execution path information of each test case based on a preset feature extraction method, wherein the preset feature extraction method includes structural features and statistical features.

[0119] According to one embodiment of the present application, the acquisition module 100 includes:

[0120] A setting unit, configured to store a preset map mapping table in a target memory based on a secondary cache mechanism, and to set a target storage space in the target memory to store the target map mapping table;

[0121] A judgment unit, used to judge whether a basic block is found in the target map mapping table;

[0122] An acquisition unit is used to transfer the search to the preset map mapping table if the basic block is not found in the target map mapping table, so as to add the basic block found in the preset map mapping table to the target map mapping table, and obtain path recovery information of multiple test cases based on the basic blocks in the target map mapping table.

[0123] According to one embodiment of the present application, the filtering module 200 includes:

[0124] a first allocating unit, configured to allocate energy to a first test case in a first preset queue using a first energy allocation score, and increase a first mutation count of the first test case according to the first energy allocation score, so as to increase a probability of discovering a vulnerability in the first test case according to the first mutation count;

[0125] The second allocation unit is used to allocate energy to the second test case in the second preset queue with a second energy allocation score, and increase the second mutation number of the second test case according to the second energy allocation score to increase the probability of discovering new potential vulnerabilities in the second test case according to the second mutation number.

[0126] According to the vulnerability path guided fuzz test seed scheduling device of the embodiment of the present application, the probability of each test case having a vulnerability is identified in the path recovery information of multiple test cases based on a pre-trained vulnerability path identification model, and the first test case with a probability greater than a preset threshold is sent to a first preset queue, and the second test case with a probability less than or equal to the preset threshold and triggering edge coverage is sent to a second preset queue. When the first test case meets the test end condition, the second test case is switched to be tested, so as to generate a scheduling method for multiple test cases based on the test results. In this way, the problem of vulnerabilities being ignored or delayed in discovery in existing coverage-guided fuzz tests is solved. By using the vulnerability path identification model in fuzz testing to identify test cases that may trigger vulnerabilities, and giving priority to testing these test cases, it is ensured that the vulnerabilities can be discovered in a timely manner.

[0127] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:

[0128] A memory 601 , a processor 602 , and a computer program stored in the memory 601 and executable on the processor 602 .

[0129] When the processor 602 executes the program, the vulnerability path guided fuzzy test seed scheduling method provided in the above embodiment is implemented.

[0130] Furthermore, the electronic device further includes:

[0131] The communication interface 603 is used for communication between the memory 601 and the processor 602 .

[0132] The memory 601 is used to store computer programs that can be run on the processor 602 .

[0133] The memory 601 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0134] If the memory 601, processor 602, and communication interface 603 are implemented independently, the communication interface 603, memory 601, and processor 602 can be interconnected via a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0135] Optionally, in a specific implementation, if the memory 601, the processor 602 and the communication interface 603 are integrated on a chip, the memory 601, the processor 602 and the communication interface 603 can communicate with each other through an internal interface.

[0136] The processor 602 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0137] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned vulnerability path-guided fuzzy test seed scheduling method.

[0138] An embodiment of the present invention further provides a computer program product, including a computer program / instruction, which implements the steps of the method of the above embodiment when executed by a processor.

[0139] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0140] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of this application, "N" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0141] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application belong.

[0142] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or N wires (electronic devices), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and a portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or otherwise processing it in a suitable manner if necessary, and then storing it in a computer memory.

[0143] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiment, the N steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used to implement: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0144] Those skilled in the art will understand that all or part of the steps in the method for implementing the above-mentioned embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0145] In addition, the functional units in the various embodiments of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into a module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0146] The storage medium mentioned above may be a read-only memory, a magnetic disk, or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application. Persons skilled in the art may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

Claims

1. A vulnerability path guided fuzzy test seed scheduling method, characterized in that: The following steps are involved: Get path recovery information for multiple test cases; Identify the probability of a vulnerability in each test case in the path recovery information based on a pre-trained vulnerability path identification model, and send a first test case whose probability is greater than a preset threshold to a first preset queue, and send a second test case whose probability is less than or equal to the preset threshold and triggers edge coverage to a second preset queue; The first test case in the first preset queue is tested, and when the first test case in the first preset queue meets the test end condition, switching to the second test case in the second preset queue for testing, so as to generate a scheduling method for the multiple test cases according to the test results.

2. The method according to claim 1, characterized in that Before obtaining the path recovery information of the multiple test cases, the method further includes: Build a vulnerability path identification model based on preset machine learning technology; Acquire input information of program execution of each test case, and track the input information to obtain path information of program execution of each test case; Extract features of the path information of each test case program execution, and collect existing vulnerability path information and non-vulnerability path information based on the extracted path information features, and generate a vulnerability path data set of the existing vulnerability path information and a non-vulnerability path data set of the non-vulnerability path information respectively; Based on the vulnerable path data set and the non-vulnerable path data set, the vulnerable path identification model is trained using a preset training algorithm to obtain the pre-trained vulnerable path identification model.

3. The method according to claim 2, characterized in that The step of obtaining the input information of the program execution of each test case and tracking the input information to obtain the path information of the program execution of each test case includes: Setting a first number and a second number of a basic block in the program execution of each test case, and using the first number and the second number as the subscript of the basic block, recording the subscript of the basic block and the basic block code corresponding to the subscript, and storing the basic block code in a preset map mapping table in a preset storage mode; Obtain the first number map and the second number map of the basic block in the program execution of each test case, and combine the first number map and the second number map after the program execution of each test case is completed, match the first number map and the second number map with the preset map mapping table, and obtain the program execution instructions and execution times of the basic block in the program execution of each test case, so as to obtain the path information of the program execution of each test case according to the program execution instructions of the basic block and the execution times.

4. The method according to claim 2, characterized in that: The feature extraction of the path information of the program execution of each test case includes: Feature extraction is performed on the program execution path information of each test case based on a preset feature extraction method, wherein the preset feature extraction method includes structural features and statistical features.

5. The method according to claim 1, characterized in that The obtaining of the path recovery information of the multiple test cases includes: Based on the secondary cache mechanism, a preset map mapping table is stored in the target memory, and a target storage space is set in the target memory to store the target map mapping table; Determine whether a basic block is found in the target map mapping table; If the basic block is not found in the target map mapping table, the search is transferred to the preset map mapping table to add the basic block found in the preset map mapping table to the target map mapping table, and the path recovery information of the multiple test cases is obtained based on the basic blocks in the target map mapping table.

6. The method according to claim 1, characterized in that The step of sending the first test case whose probability is greater than the preset threshold to a first preset queue, and sending the second test case whose probability is less than or equal to the preset threshold and triggers edge coverage to a second preset queue includes: Allocating energy to a first test case in the first preset queue with a first energy allocation score, and increasing a first mutation number of the first test case according to the first energy allocation score, so as to increase a probability of discovering a vulnerability in the first test case according to the first mutation number; Energy is allocated to the second test case in the second preset queue according to the second energy allocation score, and the second mutation number of the second test case is increased according to the second energy allocation score to increase the probability of discovering new potential vulnerabilities of the second test case according to the second mutation number.

7. A vulnerability path guided fuzzy test seed scheduling device, characterized in that: include: An acquisition module, used to obtain path recovery information of multiple test cases; A filtering module, configured to identify the probability of a vulnerability in each test case in the path recovery information based on a pre-trained vulnerability path identification model, and send a first test case whose probability is greater than a preset threshold to a first preset queue, and send a second test case whose probability is less than or equal to the preset threshold and triggers edge coverage to a second preset queue; A generation module is used to test the first test case in the first preset queue, and when the first test case in the first preset queue meets the test end condition, switch to the second test case in the second preset queue for testing, so as to generate a scheduling method for the multiple test cases according to the test results.

8. The device according to claim 7, characterized in that Before obtaining the path recovery information of the multiple test cases, the obtaining module further includes: A construction unit, used to construct a vulnerability path identification model based on a preset machine learning technology; A path tracking unit, used to obtain input information of program execution of each test case, and track the input information to obtain path information of program execution of each test case; A feature extraction unit is used to extract features from the path information of each test case program execution, and collect existing vulnerability path information and non-vulnerability path information based on the extracted path information features, and generate a vulnerability path data set of the existing vulnerability path information and a non-vulnerability path data set of the non-vulnerability path information respectively; A training unit is used to train the vulnerable path identification model based on the vulnerable path data set and the non-vulnerable path data set using a preset training algorithm to obtain the pre-trained vulnerable path identification model.

9. The device according to claim 8, characterized in that The path tracking unit comprises: a storage subunit, used to set a first number and a second number of a basic block in the program execution of each test case, and use the first number and the second number as the subscript of the basic block, and record the subscript of the basic block and the basic block code corresponding to the subscript, and store the basic block code in a preset map mapping table in a preset storage mode; An acquisition subunit is used to acquire the first number map and the second number map of the basic block in the program execution of each test case, and after the program execution of each test case is completed, combine the first number map and the second number map, match the first number map and the second number map with the preset map mapping table, and obtain the program execution instructions and execution times of the basic block in the program execution of each test case, so as to obtain the path information of the program execution of each test case according to the program execution instructions of the basic block and the execution times.

10. The device according to claim 8, characterized in that The feature extraction unit comprises: The extraction subunit is used to extract features from the program execution path information of each test case based on a preset feature extraction method, wherein the preset feature extraction method includes structural features and statistical features.

11. The device according to claim 7, characterized in that The acquisition module comprises: A setting unit, configured to store a preset map mapping table in a target memory based on a secondary cache mechanism, and to set a target storage space in the target memory to store the target map mapping table; A judging unit, used to judge whether a basic block is found in the target map mapping table; an acquisition unit, for transferring the search to the preset map table if the basic block is not found in the target map table, so as to add the basic block found in the preset map table to the target map table, and obtain the path recovery information of the multiple test cases based on the basic blocks in the target map table.

12. The device according to claim 7, characterized in that The filtering module comprises: A first allocation unit, configured to allocate energy to a first test case in the first preset queue with a first energy allocation score, and increase a first mutation number of the first test case according to the first energy allocation score, so as to increase a probability of discovering a vulnerability in the first test case according to the first mutation number; A second allocation unit is used to allocate energy to the second test case in the second preset queue with a second energy allocation score, and increase the second mutation number of the second test case according to the second energy allocation score, so as to increase the probability of discovering new potential vulnerabilities of the second test case according to the second mutation number.

13. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vulnerability path-guided fuzz testing seed scheduling method as described in any one of claims 1 to 6.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the vulnerability path guided fuzzy test seed scheduling method as described in any one of claims 1-6.

Images