Vulnerability mining method based on large model and fuzzy test and related device

Abstract

The invention belongs to a vulnerability mining method, and provides a vulnerability mining method based on a large model and a fuzzy test and a related device aiming at the problems that false alarms are frequently sent, vulnerability verification scripts are complex to compile, and single fuzzy test efficiency is low in an existing vulnerability mining method. Obtaining all call paths from the entry function to the vulnerability function, and sorting the call paths according to the complexity of the paths to obtain an ordered call path queue; gradually extracting a call path with the lowest complexity in a current queue, starting from a vulnerability function, firstly inputting a Prompt template in combination with a call scene of a call function in the path into a large model, and generating a driving function capable of running the call function; providing vulnerability verification scripts of a driving function and a vulnerability function for the large model as a reference, and selecting variable input parameters actually required for fuzzy testing; and obtaining a vulnerability verification script of the calling function, and finally mining the vulnerability of the gateway function.

Description

Technical Field

[0001] The present application relates to a vulnerability mining method, and specifically to a vulnerability mining method and related devices based on a large model and fuzzy testing. Background Art

[0002] With the continuous improvement and expansion of the software supply chain ecosystem, the continuous increase in the number of open source component vulnerabilities in the open source software supply chain, and the increasingly complex dependencies between software components, the security issues caused by the open source software supply chain have become more and more concerning. In the process of software development, software developers are gradually introducing a large number of open source third-party components into their own projects in order to avoid redundant development and improve software development efficiency. However, these components are usually a "black box" for developers, and there may be tens of thousands of projects that depend on an open source component. This means that when a component is found to have a vulnerability, the developers of downstream projects cannot predict it in advance, and all software that depends on these components will face the same security threat. Furthermore, the same vulnerability can be easily reproduced in different software, which may lead to large-scale economic losses. In addition, the affected software itself may also be a dependent component of other projects, causing the security issues caused by this to spread exponentially.

[0003] Threats from the open source software supply chain have prompted developers to use methods such as software component analysis to detect vulnerabilities in the software, and to build vulnerability verification scripts using manual writing or fuzz testing to mine vulnerabilities and prove their existence. However, these methods have the following shortcomings: frequent false alarms, complex vulnerability verification script writing, and low efficiency of single fuzz testing. Summary of the invention

[0004] The present application aims to solve the technical problems of existing vulnerability mining methods, such as frequent false alarms, complex vulnerability verification script writing, and low efficiency of single fuzzy testing, and provides a vulnerability mining method and related devices based on a large model and fuzzy testing.

[0005] In order to achieve the above objectives, this application adopts the following technical solutions: In the first aspect, the present application proposes a vulnerability mining method based on a large model and fuzz testing, comprising: S1, statically analyze the target software, combine the entry function information and the vulnerability function information, and forwardly obtain all call paths from the entry function to the vulnerability function; S2, calculating and sorting the complexity of all call paths to obtain a set of call path queues; executing steps S3 to S7 on the call paths in the call path queue one by one according to the complexity of the call paths from low to high; S3, input the prompt template and the calling scenario of the calling function in the calling path into the big model, and guide the generation of a driver function that can run the calling function; S4, if the driving function cannot run the calling function normally, the running result is fed back to the big model within the limited number of optimization times, and the driving function is optimized by the big model; S5, combined with the driver function, input the vulnerability verification script and prompt template information of the existing vulnerability function into the big model, use the big model to analyze the constraints, and select the input parameters that need to be mutated; S6, generating a seed, and based on the input parameters that need to be mutated, performing a directed fuzz test on the calling function, discovering vulnerabilities, and obtaining a vulnerability verification script for the calling function; S7, using the vulnerability verification script of the calling function as a new reference, cyclically and recursively reverse-mines the vulnerability of the calling function on the current calling path until the vulnerability of the entry and exit function is mined.

[0006] Furthermore, the forward acquisition of all call paths from the entry function to the vulnerable function includes: Use static analysis technology to analyze the target software and obtain a call graph. Based on the call graph, take the entry function as the starting point and the vulnerability function as the end point, use the graph traversal algorithm to obtain the set of all function nodes and call edges from the starting point to the end point, and obtain all call paths forward.

[0007] Furthermore, the complexity of all call paths is calculated and sorted to obtain a set of call path queues, including: Traverse each call path and generate the control flow graph of each call function. Starting from the entry function, count the number of nodes, branch paths, loop structures, nested loops, and maximum nested loop depth from the current call function to the next call function on the call path, and record them as inter-function parameters. According to the control flow graph and the parameters between functions, the cyclomatic complexity between two calling functions is calculated by the point-edge calculation method, and the weighted sum is taken together with the complexity generated by the loop structure to obtain the code complexity from the current function to the next calling function. Sum the complexity of all calling functions and calculate the arithmetic mean; The complexity of each call path is calculated by taking the weighted sum of the arithmetic mean and the number of functions in each call path.

[0008] Furthermore, the code complexity from the current function to the next calling function is obtained by the following formula:

[0009] in, For function The complexity of and are the weights of cyclomatic complexity and loop structure, respectively. To control the number of edges in the flow graph, To control the number of nodes in the flow graph, , , They are the number of loop structures, the number of nested loop structures, and the maximum nesting depth.

[0010] Furthermore, the vulnerability mining and obtaining of the vulnerability verification script of the calling function include: Set the parameters that need to be mutated as the input parameters that need to be mutated, and fix the parameters that remain unchanged; Generate an initial seed set, perform a directed fuzzy test on the calling function according to the initial seed set, and obtain a vulnerability verification script for the calling function.

[0011] Further, the method of performing a directed fuzzy test on the calling function according to the initial seed set to obtain a vulnerability verification script of the calling function includes: In fuzz testing, seeds are calculated to cover the distance between nodes and the vulnerable function, and seeds with shorter distances are given higher priority; Continue fuzz testing to discover vulnerabilities until the end condition is met: the running time limit is exceeded or input that can verify the existence of vulnerabilities in the calling function is discovered; Combine the current input with the driving function to obtain the corresponding vulnerability verification script.

[0012] Furthermore, the loop recursive reverse mining of the vulnerability of the calling function on the current calling path until the vulnerability of the entry and exit function is mined includes: Take the vulnerability verification script of the calling function as a new reference and the current calling function as a new vulnerable function; Select the next function from the calling path in reverse order as the calling function, and repeat steps S3 to S6 to generate a corresponding vulnerability verification script; Taking the entry function as the end point, the vulnerability verification scripts of each calling function are continuously and recursively mined until the vulnerability of the entry function is mined.

[0013] In the second aspect, the present application proposes a vulnerability mining system based on a large model and fuzz testing, comprising: Static analysis module, used to perform static analysis on the target software, combine entry function information and vulnerability function information, and forwardly obtain all call paths from the entry function to the vulnerability function; The mining module is used to calculate and sort the complexity of all call paths to obtain a set of call path queues; according to the complexity of the call paths from low to high, the following steps are performed on the call paths in the call path queue one by one: Input the prompt template and the calling scenario of the calling function in the calling path into the big model to guide the generation of a driver function that can run the calling function; If the driver function cannot run the calling function normally, the running result will be fed back to the big model within the limited number of optimizations, and the driver function will be optimized through the big model; Combined with the driver function, the vulnerability verification script and prompt template information of the existing vulnerability function are input into the big model, and the big model is used to analyze the constraints and select the input parameters that need to be mutated; Generate a seed, and perform a directed fuzz test on the calling function based on the input parameters that need to be mutated, discover vulnerabilities, and obtain the vulnerability verification script of the calling function; Use the vulnerability verification script of the calling function as a new reference, and recursively reverse-mine the vulnerabilities of the calling function on the current calling path until the vulnerability of the entry and exit function is discovered.

[0014] In a third aspect, the present application proposes an electronic device, comprising: a memory, and one or more processors; the memory is coupled to the processor; wherein computer program code is stored in the memory, and the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the steps of the above-mentioned vulnerability mining method based on large models and fuzzy testing.

[0015] In a fourth aspect, the present application proposes a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned vulnerability mining method based on large models and fuzzy testing are implemented.

[0016] Compared with the prior art, this application has the following beneficial effects: This application proposes a vulnerability mining method based on a large model and fuzz testing, which introduces a method of calculating and sorting the complexity of call paths using static analysis technology. By calculating and sorting the complexity of the call paths, the paths with the lowest complexity are prioritized, which greatly speeds up the operation of the overall process and significantly improves the efficiency of vulnerability mining. When generating a driver function, a large model and an automated repair mechanism are combined. Even if the generated driver function fails to execute, it can reduce manual intervention through automatic feedback and iterative optimization, thereby improving the automation of the overall vulnerability mining process. By using a large model to analyze the constraints that need to be bypassed to trigger the vulnerability before fuzz testing, and then combining the existing vulnerability verification script to select the parameters that need to be mutated in the fuzz test, and finally using the vulnerability function as the target for directional fuzz testing, it makes up for the defects of fuzz testing that are large in randomness and purposelessness, greatly improves the accuracy of fuzz testing, and improves the success rate of vulnerability mining. Finally, by using the successfully generated vulnerability verification script as a new reference to perform reverse recursive mining on other functions on the calling path, it is possible to gradually mine the vulnerabilities of a large number of related functions on one or several calling paths and generate vulnerability verification scripts. This not only ensures the vulnerability mining of the entry function, but also can further find out the vulnerabilities in other functions, which can improve the coverage of vulnerability mining and fully prove the existence of security issues in the target software.

[0017] The present application also proposes a vulnerability mining system based on a large model and fuzzy testing, an electronic device and a computer storage medium, which have all the advantages of the above-mentioned vulnerability mining method based on a large model and fuzzy testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0019] Figure 1 A flowchart of a vulnerability mining method based on a large model and fuzzy testing for this application; Figure 2 A vulnerability verification script added by the official to verify whether the vulnerability still exists after the vulnerable function is patched; Figure 3 It is the reachable path graph from the entry function to the vulnerability function; Figure 4 This is the control flow graph of the example function SpriteBuilder(); Figure 5This is a schematic diagram of the Prompt template used in the embodiments of the present application; Figure 6 Schematic diagram of the driving function generated for the first time for the large model; Figure 7 This is a schematic diagram of the error reported by the compiler for the driver function generated for the first time; Figure 8 Schematic diagram of the driving function generated by the large model after the first round of feedback optimization; Fig. 9 Schematic diagram of the driving function generated by the large model after the second round of feedback optimization; Fig.10 The source code diagram of the example calling function doNormalize(); Fig.11 Schematic diagram of the constraints analyzed for the large model and the list of parameters that need to be varied; Fig.12 This is the fuzzy driving schematic diagram generated after fixing the parameters; Fig.13 A schematic diagram of a vulnerability mining system based on a large model and fuzzy testing is provided for this application. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0022] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0023] In the description of the embodiments of the present application, it should be noted that if the terms "upper", "lower", "horizontal", "inner", etc. appear, the orientation or position relationship indicated is based on the orientation or position relationship shown in the drawings, or the orientation or position relationship in which the invented product is usually placed when used. It is only for the convenience of describing the present application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first", "second", etc. are only used to distinguish the description, and cannot be understood as indicating or implying relative importance.

[0024] In addition, if the term "horizontal" appears, it does not mean that the component must be absolutely horizontal, but can be slightly tilted. For example, "horizontal" only means that its direction is more horizontal than "vertical", which does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0025] In the description of the embodiments of the present application, it is also necessary to explain that, unless otherwise clearly specified and limited, the terms "set", "install", "connect", and "connect" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal connection of two components. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0026] Threats from the open source software supply chain have prompted developers to use methods such as software component analysis to detect vulnerabilities in the software, and to use manual writing or fuzz testing to build vulnerability verification scripts to discover vulnerabilities and prove the existence of vulnerabilities. However, these methods have the following shortcomings: (1) Frequent false alarms: The analysis granularity of existing tools is relatively coarse and cannot accurately determine whether the vulnerable function actually affects downstream projects. This imprecise analysis will generate a large number of false alarms, which can easily confuse developers' judgment and may prompt them to perform unnecessary dependency upgrades, which in turn may cause other dependency conflicts or incompatibility issues.

[0027] (2) The writing of vulnerability verification scripts is complex: Due to the high false positive rate of vulnerability detection tools, many developers do not trust the reports provided by these tools. They usually need to rely on specific vulnerability verification scripts to prove the actual impact of the vulnerability on their own software, so as to assess the severity of the vulnerability and the necessity of modifying the software. However, manually writing these scripts often requires a deep understanding of the code context, so the process is both complex and time-consuming. In addition, the quality of the script is heavily dependent on the experience and ability of the writer, which makes it difficult to standardize the writing work, thereby increasing the complexity and challenge of vulnerability mining and verification.

[0028] (3) Inefficiency of single fuzz testing: It is inefficient to rely solely on fuzz testing to find vulnerabilities in downstream projects that originate from upstream components. Fuzz testing lacks effective guidance from input to vulnerability triggering. Arbitrary input may not be able to bypass certain specific conditions required to trigger the vulnerability, thereby reducing the efficiency of discovering and verifying vulnerabilities.

[0029] In view of the significant potential of large models in code extraction and generation, the fact that developers of upstream projects often provide vulnerability verification scripts to verify whether the vulnerability exists in the current version when fixing the vulnerable function, and the advantages of fuzz testing in providing a large number of input samples and vulnerability mining, this application proposes a solution that combines large models and fuzz testing. That is, the large model is used to analyze the vulnerability verification script and function call information of the vulnerable function, extract the vulnerability verification input and the constraints that trigger the vulnerability, and then guide the mutation direction of the fuzz test input. Finally, with the entry function as the target, the vulnerabilities of each function on the vulnerability call path are mined and the corresponding vulnerability verification scripts are generated, thereby solving the vulnerability accessibility and exploitability problems in the target software, and achieving the purpose of maintaining and promoting the ecological security of the open source software supply chain.

[0030] The present application is further described in detail below in conjunction with the embodiments and drawings. Figure 1 As shown, it is a first flow chart of a vulnerability mining method based on a large model and fuzzy testing in this application, which may include: S1, statically analyze the target software, combine the entry function information and the vulnerability function information, and forwardly obtain all call paths from the entry function to the vulnerability function.

[0031] In practical applications, static analysis techniques can be used to analyze the target software, such as Clang StaticAnalyzer, Ghidra or Fortify, to scan the target software, combine the entry point and known vulnerable function information, and obtain a call graph. Based on the call graph, the entry function is used as the starting point and the vulnerable function is used as the end point. The graph traversal algorithm is used to obtain the set of function nodes and call edges from the starting point to the end point, thereby obtaining all call paths in a forward direction. This method helps to quickly and accurately find all vulnerable call paths and exclude redundant information that is irrelevant to the actual call relationship.

[0032] S2, calculating and sorting the complexity of all call paths to obtain a set of call path queues; and executing steps S3 to S7 on the call paths in the call path queue one by one according to the complexity of the call paths from low to high.

[0033] In practical applications, we can define path complexity metrics, such as path length, number of function calls involved, number of conditional branches, etc., calculate the complexity of each path, and arrange them in descending order to form a call path queue.

[0034] As an implementation method of the present application, the following method may be used: (1) Traverse each call path and generate the control flow graph of each calling function. Starting from the entry function, count the number of nodes, branch paths, loop structures, nested loops, and maximum nested loop depth from the current calling function to the next calling function on the calling path.

[0035] (2) Based on the number of nodes and the number of branch paths, the cyclomatic complexity between two calling functions is calculated using the point-edge calculation method, and a weighted sum is taken together with the complexity generated by the loop structure to obtain the code complexity from the current function to the next calling function in the call chain. For the sake of convenience, it is referred to as function complexity.

[0036] The calculation formula for function complexity is:

[0037] in, For function The complexity of and are the weights of cyclomatic complexity and loop structure, respectively. To control the number of edges in the flow graph, To control the number of nodes in the flow graph, , , They are the number of loop structures, the number of nested loop structures, and the maximum nesting depth.

[0038] (3) Sum the complexity of all calling functions and calculate the arithmetic mean. The calculation formula is:

[0039] in, is the arithmetic mean of the function complexity, The number of function calls.

[0040] (4) The complexity of each call path is calculated by taking a weighted sum of the number of functions in each call path and arranging them in ascending order.

[0041] The calculation formula of path complexity is:

[0042] in, Call path The complexity of A weight to balance function complexity and path length.

[0043] If there are call paths with the same complexity, the call path with fewer called functions will be ranked first. If the number of called functions in the call paths is the same, any call path will be ranked first. The calculation and sorting of the complexity of the call paths are performed only once.

[0044] The above method combines three main elements: the function cyclomatic complexity metric commonly used in software analysis, the loop-related structural information in the function, and the number of functions in the call path. These three elements take into account the impact of the number of branches and loop structure in the function on the complexity of a single function, as well as the impact of the number of functions on the complexity of the entire path. By calculating the complexity of each call path and sorting them in positive order, in the subsequent steps, the call paths with the lowest complexity in the current ordered queue can be taken out one by one for analysis, which is conducive to greatly improving the efficiency of the overall process and the accuracy of vulnerability mining.

[0045] (5) If the vulnerability verification script of the entry function has not been generated and there are still untraversed call paths in the queue, the frontmost path in the current queue, that is, the path with the lowest complexity, is taken out one by one for subsequent analysis.

[0046] S3, inputs the prompt template and the calling scenario of the calling function in the calling path into the big model, guiding the generation of a driver function that can run the calling function.

[0047] It should be noted that once the call path is determined, all functions that appear on the call path are considered call functions, which may include library functions and custom functions, etc., which together constitute a complete call chain from the entry function to the vulnerable function. In actual applications, the big model can be used to generate a driver function that can trigger a specific function call scenario, design a prompt template that includes the call context and expected behavior of each call function in the call path, input the prompt template and call scenario into the big model, and generate the driver function code.

[0048] In practical applications, the Prompt template can be specially designed to guide the large model to accurately generate the driver function. In this embodiment, the Prompt template follows the basic principles of the Prompt project, such as clear goals, simple and direct, complete information, and clear logic, and combines the design method of the thinking chain. This design pattern imitates the basic thinking of humans when solving the same problem, and divides a large problem into several small steps in sequence, so as to guide the large model to think step by step and improve the generation effect of the model. This design pattern can also clearly output the analysis results of the large model for each small step, thereby reducing the probability of the "hallucination" phenomenon of the large model. In this embodiment, the definition of the calling function is that in the current calling path, the function that explicitly calls the vulnerability function in the method body. The usage scenario of the calling function is defined as: the parameter format and data structure and other information passed in when the calling function is used by other functions in the calling path. By combining the Prompt template with the usage scenario of the calling function, the large model can fully understand the expected goal of the task and the usage of the calling function, and then try to generate a driving function that can run the calling function.

[0049] The information input into the big model includes the usage scenarios of the calling function in the calling path, which can be used as a powerful reference by the big model to help it better build a driver function for running the calling function.

[0050] S4: If the driving function cannot run the calling function normally, the running result will be fed back to the big model within the limited number of optimization times, and the driving function will be optimized through the big model.

[0051] In order to ensure that the driver function can run correctly and call the target function, if the driver function cannot run normally, the runtime error information can be collected and fed back to the big model within a limited number of iterations to guide the big model to correct and optimize the driver function. This automated repair method will help reduce manual intervention and improve the overall process efficiency.

[0052] S5, combined with the driving function, inputs the vulnerability verification script and prompt template information of the existing vulnerability function into the big model, uses the big model to analyze the constraints, and selects the input parameters that need to be mutated.

[0053] It is possible to identify and select input parameters that are critical to exploiting vulnerabilities for mutation. Combined with the driver function and known vulnerability verification scripts, relevant information is input into the large model, the constraint relationship between parameters is analyzed, and it is determined which parameters are potential attack surfaces and need mutation testing.

[0054] In practical applications, we can first collect the vulnerability verification scripts of the driver functions and vulnerable functions generated directly by S3 or after optimization by S4, and design a Prompt template with the same basic idea as the template in S3. The difference is that the main function of this template is to guide the large model to first refer to the calling function, driver function, vulnerability verification script and other information, and then analyze the constraints that need to be met when calling the vulnerable function, and finally select the input parameters that are helpful in triggering the vulnerability and need to be mutated in the subsequent fuzz testing steps, and at the same time select the parameters that are not related to triggering the vulnerability and therefore need to remain unchanged. Then, in the subsequent steps, the vulnerability in the calling function is mined based on the selected parameters.

[0055] S6, generates seeds, and based on the input parameters that need to be mutated, performs directed fuzz testing on the calling function, discovers vulnerabilities, and obtains the vulnerability verification script of the calling function.

[0056] Generate an initial seed (legitimate or distorted input data), use the fuzz testing framework to perform targeted testing on the calling function for the selected mutation parameters, try to trigger the vulnerability, and record the test results to generate a vulnerability verification script.

[0057] In actual applications, the following methods can be used to discover vulnerabilities and obtain vulnerability verification scripts for calling functions: First, the parameters that need to be mutated are set to the specific input parameters selected by the large model in step S5, and the parameters that remain unchanged are fixed. Then an initial seed set is generated, and a directed fuzz test is performed on the calling function. In order to force the mutation to move closer to the vulnerable function, the distance between the seed-coverable node and the vulnerable function will be calculated in the fuzz test, and seeds with shorter distances will be given higher priority. The fuzz test will continue to mine vulnerabilities until the end condition is met: the running time limit is exceeded or the input that can verify the existence of a vulnerability in the calling function has been mined, and then the current input can be combined with the driver function to obtain the corresponding vulnerability verification script.

[0058] In this embodiment, a directed gray box fuzz tester is used to perform fuzz testing on the calling function. By calculating the distance between the seed-coverable node and the vulnerability function, and taking the closer to the vulnerability function as the better standard, the fuzz test can be made to move in the direction of the vulnerability function, and then try to dig out the vulnerability of the calling function. Compared with coverage-based fuzz testing, directed fuzz testing gives priority to retaining seeds whose coverage nodes are closer to the vulnerability function, so the efficiency of vulnerability mining can be guaranteed within a limited time.

[0059] S7, using the vulnerability verification script of the calling function as a new reference, cyclically and recursively reverse-mines the vulnerability of the calling function on the current calling path until the vulnerability of the entry and exit function is mined.

[0060] Vulnerabilities can be mined recursively upstream until the entry function is reached. The newly discovered vulnerability verification script is used as new reference information, and steps S3 to S6 are repeated, but this time for each calling function on the current calling path, reverse mining its potential vulnerabilities until the entry function vulnerability is finally found.

[0061] In actual applications, the loop recursive reverse mining is used to mine the vulnerabilities of the calling functions on the current calling path until the vulnerabilities of the entry and exit functions are mined. Specifically, the following methods can be used: (1) When the vulnerability verification script obtained in step S6 can prove that the calling function has a vulnerability, this script is used as a new reference and the current calling function is regarded as a new vulnerable function.

[0062] (2) Select the next function from the calling path in reverse order as the calling function, and repeat steps S3 to S6 for it to generate a corresponding vulnerability verification script; (3) If the optimization task is not completed in step S4 or the directed fuzz test in step S6 exceeds the limited running time, it means that the vulnerability of the current calling function cannot be discovered. The current calling path needs to be marked as infeasible and re-executed from step S2.

[0063] (4) Repeat (1) to (3) in step S7, taking the entry function as the end point, and continuously and recursively mine the vulnerabilities of each calling function and generate a vulnerability verification script.

[0064] (5) If the vulnerability of the entry function is successfully discovered, it means that the target software has at least one calling path that can trigger the vulnerability at the entry point, thereby verifying the accessibility and exploitability of the vulnerability, and further proving that the target software has a greater security risk.

[0065] In the process of reversely generating vulnerability verification scripts for other functions, when a vulnerability is discovered in a calling function, the generated vulnerability verification script is used as a new reference, the current calling function is regarded as the vulnerable function, and the next function is selected from the calling path as the calling function in reverse and the vulnerability discovery process is repeated. If the vulnerability of a function cannot be discovered, a new path is selected from the calling path queue for traversal, and this process continues until the vulnerability of the entry and exit functions is successfully discovered or the calling path set is empty.

[0066] This application first obtains all call paths from the entry function to the vulnerability function of the target software based on static analysis technology, and sorts them according to the complexity of the path to form an ordered call path queue. Then take out the path with the lowest complexity in the queue one by one for traversal, and use the large model to generate a driver function that runs the vulnerability function for effective fuzz testing. Then the vulnerability verification script and driver function of the vulnerability function are input into the large model, and the calling function constraints are analyzed by it, and then the parameters that need to be mutated and those that do not need to be mutated are selected. After that, this application uses the directional fuzz testing technology to mine the vulnerability of the calling function based on the selected parameters, and uses the distance between the seed-coverable node and the vulnerability function as a standard to guide the parameter mutation process, that is, the closer the distance, the higher the priority of the seed. When the vulnerability of the calling function is successfully mined, the fuzz test input is combined with the driver function to generate a new vulnerability verification reference script, and the vulnerabilities of other calling functions are continuously mined in reverse recursion and the vulnerability verification script is generated until the entry function is reached. This application aims to improve the accuracy and efficiency of vulnerability mining and verify whether the target project is affected by a specific vulnerability, thereby solving the problem of vulnerability accessibility and exploitability, and providing a strong guarantee for the security of the open source software supply chain.

[0067] Figure 2 This is a vulnerability verification script provided by the developers of the Apache Commons IO project for the CVE-2021-29425 vulnerability exposed in the project. This script can run smoothly in the patch version, but will report an error in the vulnerable version. It can be used to explore whether other functions that call the vulnerable function have vulnerabilities.

[0068] Taking Apache Commons IO 2.6 version and the SmartSprites project that uses this vulnerable version as an example, the vulnerability mining method based on large models and fuzz testing technology proposed in this application is explained.

[0069] Step 1: First, use the widely used Soot static analysis framework in Java to perform static analysis on the target project SmartSprites to obtain the function call graph between the project and the vulnerable project Apache Commons IO. Then, perform a depth-first traversal operation starting from the entry function of the target project and ending at the vulnerable function getPrefixLength() in the vulnerable project, and successfully obtain Figure 3 There are two call paths in the figure. Each node in the figure is represented by a Soot signature, and the basic structure is <class name: function return value function name (function input parameter)>.

[0070] Step 2: First, generate the control flow graph of each function, and calculate the complexity of each function based on information such as the number of branches and loop structures between functions. Figure 4 The control flow graph of the third node in the call path starting from the entry function: SpriteBuilder() is shown, and the path from the entry of SpriteBuilder() to reWriteCssFiles() is marked. As can be seen from the figure, the directed maximal connected subgraph between the two functions has 32 edges, 32 nodes, 1 loop structure, 0 nesting layers and a maximum nesting depth of 0. We use the weight in the function complexity calculation formula Take it as 0.7, Taking it as 0.3, we can calculate the complexity of SpriteBuilder() as 1.7 according to the following formula.

[0071]

[0072] Will Figure 3 The left path is set as path 1, and the right path is set as path 2. The complexity of other functions on the two call paths is calculated, and the sum is taken and the arithmetic mean is taken. It is found that the average complexity of the function of path 1 is about 1.35, and the average complexity of the function of path 2 is about 1.7. Then, according to the path complexity calculation formula , taking the weight W as 0.1, calculate the complexity of the two paths respectively. There are 11 functions on path 1, and 12 functions on path 2. The complexity of path 1 is 2.45, and the complexity of path 2 is 2.9. Therefore, the priority of path 1 is higher than that of path 2, thus forming an ordered call path sequence, and then path 1 is taken out first to proceed to the next steps.

[0073] Step 3: Combine a specially designed prompt template with the calling scenario of the function being used by other functions on the path and provide it to the big model. Use the abstraction and summarization capabilities of the big model to try to generate a driver function that can run the calling function. Figure 5 This is a Prompt template displayed in markdown format. Since the big model's ability to understand and analyze English is far greater than that of Chinese, we use English to write the Prompt template. Here we introduce the various elements of the thinking chain in the template. The target function in the template is the calling function that needs to generate the driving function, and the reference function is the corresponding calling scenario: (1) Overall analysis Based on the content provided in the template at the beginning, indicate the tasks that need to be completed; <targetmethod>< / targetmethod> (2) Analysis of the relationship between calling functions and called functions (3) Reference function analysis Indicate which packages should be imported in the driver function to avoid "unable to resolve symbol" errors; indicate which inputs are used in the reference function to call the target function; fully consider how these inputs should be constructed, especially when these inputs are instances of custom classes; (4) Access modifier analysis (5) The large model is required to write a driver function that includes all necessary elements and can be run directly in the original project.

[0074] Figure 6 The driver function is obtained by taking doNormalize() as the target function and calling its normalize() as the reference call scenario, combined with the Prompt template input into the large model. It is not difficult to see from the generated results that the large model fully understands the actual function of the target function, successfully constructs all necessary inputs, and then generates a driver function with a correct structure that calls the target function. Furthermore, the large model also successfully analyzes that the target function is a private function and uses reflection technology to call it.

[0075] Step 4: Test the driver function generated in step 3, such as Figure 7 As shown in the figure, we found that the symbol could not be found error, so we fed the error information back to the big model and asked it to optimize the driving function. The optimization result is as follows Figure 8 As shown in the figure, the large model successfully adds the missing package to the driver function. Although the driver function can already run, the compiler prompts that the package declaration is missing, so we feed the prompt information back to the large model again and finally get Fig. 9 The driver function shown. After verification, the current driver function has no errors and can run normally and call the target function.

[0076] Step 5: Combine the optimized driver function in step 4, the vulnerability verification script of the vulnerable function, and a Prompt template with the same construction idea as the template in step 3, and input them into the large model. It is required to analyze the constraints that the calling function needs to meet when calling the vulnerable function, and then select the input parameters that need to be mutated during the fuzz testing process, as well as the parameters that are not related to vulnerability mining and therefore need to remain unchanged. Fig.10 The source code for calling the function doNormalize() is the vulnerable function getPrefixLength(). The constraints that need to be satisfied, the parameters that need to be mutated, and the parameters that need to remain unchanged extracted by the large model are as follows: Fig.11 shown.

[0077] Step 6: According to the parameters selected by the large model in step 5, they are fixed in the driving function to obtain the fuzzy drive, such as Fig.12As shown. For parameters that need to be mutated, such as filename, if it has a certain variation range, the initial value is randomly generated within the range. Otherwise, we use the dictionary and template to initialize it and generate the initial seed as the initial seed set based on its type.

[0078] After allocating energy to each seed in the seed set, mutate and execute it to generate the corresponding test results and obtain a new seed set. The seed execution path obtained from the test results can be used to calculate the priority of the new seed set. We use an adaptive strategy to sort the priorities of the seeds, and denote v as the corresponding vulnerability path. is the path that does not cover v but is closest to v. The condition for the fork path is c. The fork condition can be the following: true, false, , , , , , , where a and b are variables or constants. We define a distance function to sort the priorities of seeds. The distance function is as follows:

[0079] in, is a constant representing the minimum distance. The smaller the value, the closer the branch path is to the vulnerability path. The distance metric calculation can be used to prioritize the seed set. The seeds whose executed branches are closer to the vulnerability path are given higher priorities. The seeds with high priorities are allocated higher energy when they mutate, and the probability of mutating into seeds that can discover vulnerabilities is greater.

[0080] The fuzz testing process continues until the program meets the termination conditions: the limited running time is reached or input has been generated that can prove that the calling function has a vulnerability. The test ends and the input is combined with the driver script to generate the corresponding vulnerability verification script.

[0081] Step 7: If a verification script that can mine the calling function vulnerability is successfully generated, and the current calling path has not been traversed, then use this script as a new reference, treat the current calling function as the vulnerable function, and take the next function on the calling path as the calling function. Continue to recursively reverse mine the vulnerabilities of other functions and generate vulnerability verification scripts until the vulnerability of the entry and exit functions is mined, thereby proving the accessibility and exploitability of the vulnerability, and then confirming that there is a security problem in the current project.

[0082] Through the above method, this application implements a vulnerability mining method based on large models and fuzz testing technology, providing a faster and more accurate solution to the reach and exploitability issues of vulnerabilities in the open source software supply chain ecosystem.

[0083] like Fig.13 As shown, it is a schematic diagram of a vulnerability mining system based on a large model and fuzzy testing in the present application, which may include: Static analysis module, used to perform static analysis on the target software, combine entry function information and vulnerability function information, and forwardly obtain all call paths from the entry function to the vulnerability function; The mining module is used to calculate and sort the complexity of all call paths to obtain a set of call path queues; according to the complexity of the call paths from low to high, the following steps are performed on the call paths in the call path queue one by one: Input the prompt template and the calling scenario of the calling function in the calling path into the big model to guide the generation of a driver function that can run the calling function; If the driver function cannot run the calling function normally, the running result will be fed back to the big model within the limited number of optimizations, and the driver function will be optimized through the big model; Combined with the driver function, the vulnerability verification script and prompt template information of the existing vulnerability function are input into the big model, and the big model is used to analyze the constraints and select the input parameters that need to be mutated; Generate a seed, and perform a directed fuzz test on the calling function based on the input parameters that need to be mutated, discover vulnerabilities, and obtain the vulnerability verification script of the calling function; Use the vulnerability verification script of the calling function as a new reference, and recursively reverse-mine the vulnerabilities of the calling function on the current calling path until the vulnerability of the entry and exit function is discovered.

[0084] It should be noted that in the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the system embodiments described above are merely schematic. For example, the division of each module is only a logical function division. There may be other division methods in actual implementation. For example, multiple modules can be combined or integrated into another device, or some features can be ignored or not executed. The module described as a separate component may or may not be physically separated. The component displayed as a module may be a physical unit or multiple physical units, that is, it may be located in one place, or it may be distributed in multiple different places. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0085] In addition, each module in each embodiment of the present invention may be integrated into a processing unit, each module may exist physically separately, or two or more modules may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of a software functional unit.

[0086] An embodiment of the present application also provides an electronic device, which may include one or more processors, a memory, and a communication interface.

[0087] The memory, the communication interface and the processor are coupled, for example, the memory, the communication interface and the processor may be coupled together via a bus.

[0088] The communication interface is used to transmit data with other devices. The memory stores computer program code. The computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the steps of the vulnerability mining method based on the large model and fuzzy testing in the embodiment of the present application.

[0089] Wherein, the processor can be a processor or a controller, for example, a central processing unit (CPU), a general processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the present disclosure. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of DSP and microprocessors, and the like. The processor can be used to support electronic devices to execute the method steps provided in the above embodiments.

[0090] The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The above buses can be divided into address buses, data buses, control buses, 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 only one type of bus.

[0091] An embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the vulnerability mining method based on a large model and fuzzy testing as described in any of the above embodiments are implemented.

[0092] The computer-readable storage medium involved in the present application includes random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the technical field.

[0093] For the description of the relevant parts of the vulnerability mining system based on large models and fuzzy testing, electronic device, and computer-readable storage medium provided in the embodiments of the present application, please refer to the detailed description of the corresponding parts in the vulnerability mining method based on large models and fuzzy testing provided in the embodiments of the present application, which will not be repeated here. In addition, the parts of the above-mentioned technical solutions provided in the embodiments of the present application that are consistent with the implementation principles of the corresponding technical solutions in the prior art are not described in detail to avoid excessive elaboration.

[0094] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A vulnerability mining method based on large models and fuzzy testing, characterized in that: include: S1, statically analyze the target software, combine the entry function information and the vulnerability function information, and forwardly obtain all call paths from the entry function to the vulnerability function; S2, calculating and sorting the complexity of all call paths to obtain a set of call path queues; executing steps S3 to S7 on the call paths in the call path queue one by one according to the complexity of the call paths from low to high; S3, input the prompt template and the calling scenario of the calling function in the calling path into the big model, and guide the generation of a driver function that can run the calling function; S4, if the driving function cannot run the calling function normally, the running result is fed back to the big model within the limited number of optimization times, and the driving function is optimized by the big model; S5, combined with the driver function, input the vulnerability verification script and prompt template information of the existing vulnerability function into the big model, use the big model to analyze the constraints, and select the input parameters that need to be mutated; S6, generating a seed, and based on the input parameters that need to be mutated, performing a directed fuzz test on the calling function, discovering vulnerabilities, and obtaining a vulnerability verification script for the calling function; S7, using the vulnerability verification script of the calling function as a new reference, cyclically and recursively reverse-mines the vulnerability of the calling function on the current calling path until the vulnerability of the entry and exit function is mined.

2. According to claim 1, a vulnerability mining method based on a large model and fuzzy testing is characterized in that: The forward acquisition of all call paths from the entry function to the vulnerable function includes: Use static analysis technology to analyze the target software and obtain a call graph. Based on the call graph, take the entry function as the starting point and the vulnerability function as the end point, use the graph traversal algorithm to obtain the set of all function nodes and call edges from the starting point to the end point, and obtain all call paths forward.

3. According to claim 2, a vulnerability mining method based on a large model and fuzzy testing is characterized in that: The complexity of all call paths is calculated and sorted to obtain a set of call path queues, including: Traverse each call path and generate the control flow graph of each call function. Starting from the entry function, count the number of nodes, branch paths, loop structures, nested loops, and maximum nested loop depth from the current call function to the next call function on the call path, and record them as inter-function parameters. According to the control flow graph and the parameters between functions, the cyclomatic complexity between two calling functions is calculated by the point-edge calculation method, and the weighted sum is taken together with the complexity generated by the loop structure to obtain the code complexity from the current function to the next calling function. Sum the complexity of all calling functions and calculate the arithmetic mean; The complexity of each call path is calculated by taking the weighted sum of the arithmetic mean and the number of functions in each call path.

4. According to claim 3, a vulnerability mining method based on a large model and fuzzy testing is characterized in that: The code complexity from the current function to the next calling function is obtained by the following formula: in, For function The complexity of and are the weights of cyclomatic complexity and loop structure, respectively. To control the number of edges in the flow graph, To control the number of nodes in the flow graph, , , They are the number of loop structures, the number of nested loop structures, and the maximum nesting depth.

5. According to claim 4, a vulnerability mining method based on a large model and fuzzy testing is characterized in that: The vulnerability mining and obtaining of the vulnerability verification script of the calling function include: Set the parameters that need to be mutated as the input parameters that need to be mutated, and fix the parameters that remain unchanged; Generate an initial seed set, perform a directed fuzzy test on the calling function according to the initial seed set, and obtain a vulnerability verification script for the calling function.

6. According to claim 5, a vulnerability mining method based on a large model and fuzzy testing is characterized in that: The method of performing a directed fuzzy test on the calling function according to the initial seed set to obtain a vulnerability verification script of the calling function includes: In fuzz testing, seeds are calculated to cover the distance between nodes and the vulnerable function, and seeds with shorter distances are given higher priority; Continue fuzz testing to discover vulnerabilities until the end condition is met: the running time limit is exceeded or input that can verify the existence of vulnerabilities in the calling function is discovered; Combine the current input with the driving function to obtain the corresponding vulnerability verification script.

7. A vulnerability mining method based on a large model and fuzzy testing according to claim 6, characterized in that: The loop recursive reverse mining of the vulnerability of the calling function on the current calling path until the vulnerability of the entry and exit function is mined includes: Take the vulnerability verification script of the calling function as a new reference and the current calling function as a new vulnerable function; Select the next function from the calling path in reverse order as the calling function, and repeat steps S3 to S6 to generate a corresponding vulnerability verification script; Taking the entry function as the end point, the vulnerability verification scripts of each calling function are continuously and recursively mined until the vulnerability of the entry function is mined.

8. A vulnerability mining system based on large models and fuzzy testing, characterized in that: include: Static analysis module, used to perform static analysis on the target software, combine entry function information and vulnerability function information, and forwardly obtain all call paths from the entry function to the vulnerability function; The mining module is used to calculate and sort the complexity of all call paths to obtain a set of call path queues; according to the complexity of the call paths from low to high, the following steps are performed on the call paths in the call path queue one by one: Input the prompt template and the calling scenario of the calling function in the calling path into the big model to guide the generation of a driver function that can run the calling function; If the driver function cannot run the calling function normally, the running result will be fed back to the big model within the limited number of optimizations, and the driver function will be optimized through the big model; Combined with the driver function, the vulnerability verification script and prompt template information of the existing vulnerability function are input into the big model, and the big model is used to analyze the constraints and select the input parameters that need to be mutated; Generate a seed, and perform a directed fuzz test on the calling function based on the input parameters that need to be mutated, discover vulnerabilities, and obtain the vulnerability verification script of the calling function; The vulnerability verification script of the calling function is used as a new reference, and the vulnerability of the calling function on the current calling path is reversely mined in a loop recursively until the vulnerability of the entry and exit function is mined.

9. An electronic device, characterized in that: include: A memory and one or more processors; the memory is coupled to the processor; wherein the memory stores computer program code, the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the steps of the vulnerability mining method based on large models and fuzzy testing as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the vulnerability mining method based on a large model and fuzzy testing as described in any one of claims 1 to 7.

Images