Software supply chain vulnerability verification code generation method based on guide fuzzy testing

Abstract

The invention discloses a software supply chain vulnerability verification code generation method based on guiding fuzzy testing. The method comprises the steps that s1, a tripartite library dependency graph with a binary program as a starting node is generated; s2, performing static component analysis on the target application software component to form a component dependency graph; analyzing the component dependency graph layer by layer, and constructing an overall function call graph; s3, matching all vulnerability functions existing in the three-party component based on CVE information, calculating vulnerability function layer distance according to an overall function call graph, and performing directed utility calculation on a prepositioned function and a function priority for fuzzy test energy distribution; s4, performing key node identification and vulnerability distance calculation on a tripartite library critical function in the overall function call graph; and s5: transmitting binary static analysis results of s1 to s4 to a fuzzy test tool for directional fuzzy test. The method has the advantages of being simple in principle, easy to implement, higher in testing capacity, better in applicability and the like.

Description

Technical Field

[0001] The present invention mainly relates to the technical field of software security testing, and in particular to a method for generating software supply chain vulnerability verification code based on guided fuzz testing. Background Art

[0002] In existing technologies, third-party components are often referenced during software development. This process can lead to vulnerabilities in these third-party components being introduced to downstream components and ultimately into downstream applications, ultimately creating software supply chain vulnerabilities.

[0003] For example, in typical supply chain scenarios like IoT firmware, software and third-party components often exist in binary form without source code. The software's source code (i.e., the code readable by the people who wrote it) is typically not disclosed to end users or customers. Instead, the software is provided in compiled binary form. In this case, detecting vulnerabilities in software binaries due to supply chain vulnerabilities becomes crucial.

[0004] Currently, fuzz testing technology is highly effective in discovering vulnerabilities in binary software. However, existing fuzz testing methods are typically coverage-based, aiming to reach a set of predetermined locations in the code and spending most of their time budget on reaching the target locations. As a result, their detection efficiency for binary vulnerabilities is low.

[0005] Furthermore, traditional fuzz testing techniques don't consider components (such as third-party components) when analyzing software, effectively ignoring the impact of component vulnerabilities on the software. However, using known supply chain vulnerability information to guide fuzz testing requires only the vulnerability location, significantly improving fuzz testing's vulnerability detection efficiency. Summary of the Invention

[0006] The technical problem to be solved by the present invention is: in response to the technical problems existing in the prior art, the present invention provides a software supply chain vulnerability verification code generation method based on guided fuzz testing, which has a simple principle, is easy to implement, has stronger testing capabilities, and is better applicability.

[0007] In order to solve the above technical problems, the present invention adopts the following technical solutions: A method for generating software supply chain vulnerability verification code based on guided fuzz testing, comprising: Step s1: Generate a tripartite library dependency graph starting with the binary program; Step s2: Perform static component analysis on the target application software components to form a component dependency graph; perform layer-by-layer analysis on the component dependency graph to construct an overall function call graph; Step s3: Match all vulnerable functions in the three-party components based on CVE information, and calculate the vulnerability function layer distance, predecessor function, and function priority according to the overall function call graph to perform directed utility calculation for fuzz testing energy allocation; Step s4: Identify key nodes and calculate vulnerability distances for the critical functions of the tripartite library in the overall function call graph; Step s5: Pass the binary static analysis results from steps s1 to s4 to the fuzz testing tool for directed fuzz testing. As a further improvement of the present invention: in the step s1, the binary program tiffcrop is selected, and the directly dependent and indirectly dependent third-party libraries are analyzed layer by layer based on existing tools to form a third-party library dependency graph with the binary program as the starting node. Each node in the graph represents a unique program or third-party library and is stored using NetworkX.

[0008] As a further improvement of the present invention: step s2 includes: Step s21: For the binary program in the third-party library dependency graph and each directly or indirectly dependent third-party library, use the binary analysis tool Angr to analyze their respective function call graphs; Step s22: Use the binary analysis tool nm to analyze the binary program and the dynamic symbol tables of all three-party libraries, and filter out the dynamic link library functions called by each of them as the critical functions of each three-party library; Step s23: Based on the function call graph generated by Angr and the obtained critical functions, the overall function call graph of the binary program is constructed layer by layer.

[0009] As a further improvement of the present invention: the overall function call graph includes the calling relationship between the main program and each library, and the calling process between the library and the dynamic link library it depends on.

[0010] As a further improvement of the present invention: each node of the overall function call graph represents a unique function, which includes three attributes: function name, function address, and the name of the binary program or tripartite library to which it belongs, and is stored using NetworkX.

[0011] As a further improvement of the present invention: in the step s3, all vulnerable functions are obtained based on the vulnerability CVE-2023-3618 information, and it is known that they affect the Fax3Encode function in the third-party library libtiff; according to the overall function call graph, the three input indicators of function layer distance, predecessor function and function priority are calculated for the energy allocation stage of the directed fuzz test.

[0012] As a further improvement of the present invention: the step s3 includes: (1) Function layer distance; the function layer distance refers to the distance from the functions of the program to all vulnerable functions. (2) Predecessor functions; the predecessor functions refer to all functions in the program that have paths leading to vulnerable functions; for each function in the program, determine whether there is a path leading to a certain vulnerable function, and if there is a path, mark this function as a predecessor function. (3) Function priority; the function priority refers to the reciprocal of the distance from the functions of the program to all vulnerable functions.

[0013] As a further improvement of the present invention: the step s4 includes: In the construction of the overall function call graph, the critical functions of the program and the third-party libraries have been obtained; for each critical function, determine whether it is a predecessor function, and if it is a predecessor function, then mark it as a key point. For each key point, obtain the name of the third-party library to which the key point belongs through the overall function call graph. Calculate the average distance from the third-party library to which the key point belongs to the third-party libraries of all vulnerable functions based on the third-party library dependency graph and use it as the distance of the key point. Obtain all the key points of the program and the distances of the key points.

[0014] As a further improvement of the present invention: the step s5 includes: seed selection; in fuzz testing, the seed queue refers to a set of initial inputs or seeds used to generate test cases; after each execution of the program, record the execution trace of the program and obtain the function call path of the executed functions; obtain all the priorities of the seed queue, and preferentially select the seeds with large priorities and not yet selected for energy allocation and seed mutation in each round of fuzz testing.

[0015] As a further improvement of the present invention: the step s5 includes: energy allocation; three input metrics, namely function layer distance, predecessor function, and function priority, have been obtained through directed utility calculation; the execution path of any one seed is , perform priority calculation; then, the energy allocation link is responsible for allocating more computing energy to seeds with high efficiency; if the execution path of the current seed is closer to the vulnerable functions in the program, more energy should be obtained on this seed.

[0016] Compared with the prior art, the advantages of the present invention are: 1. The method for generating verification code for software supply chain vulnerabilities based on guided fuzz testing of the present invention has a simple principle, is easy to implement, has stronger testing capabilities, and better applicability. The present invention generates verification code by using supply chain vulnerability information based on guided fuzz testing. According to the provided vulnerability location information, the testing focus is concentrated on the code paths related to the vulnerabilities, and targeted fuzz testing exploration is carried out. The present invention improves the ability to detect security defects caused by supply chain vulnerabilities in software binary files.

[0017] 2. In view of the deficiencies of existing fuzz testing technologies in detecting binary file vulnerabilities, the present invention designs a method for generating verification code for software supply chain vulnerabilities based on guided fuzz testing. The present invention can further improve the fuzz testing efficiency for detecting binary file vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a schematic flowchart of the present invention in a specific embodiment.

[0019] Figure 2 is a schematic diagram of the overall function call in a specific embodiment of the present invention.

[0020] Figure 3 is a schematic diagram of the nodes of the overall function call graph of Tiffcrop in a specific embodiment of the present invention.

[0021] Figure 4 is a schematic diagram of the edges of the overall function call graph of Tiffcrop in a specific embodiment of the present invention.

[0022] Figure 5 is a schematic diagram of the function layer distance, pre-function, function priority, and key points of the Tiffcrop program in a specific embodiment of the present invention.

[0023] Figure 6 is a schematic diagram of the directed fuzz testing results of the Tiffcrop program in a specific embodiment of the present invention.

[0024] Figure 7 is a schematic diagram of the crash testing results of the Tiffcrop program in a specific embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0025] The following will further elaborate on the present invention in detail with reference to the accompanying drawings of the specification and specific embodiments.

[0026] [[ID=!41]]As Figure 1 shown, the present invention provides a method for generating verification code for software supply chain vulnerabilities based on guided fuzz testing, which includes: Step s1: Generate a three-party library dependency graph with the binary program as the starting node; Step s2: Perform static component analysis on the target application software components to form a component dependency graph; perform layer-by-layer analysis on the component dependency graph to construct an overall function call graph, see Figure 2 ; Step s3: Match all existing vulnerable functions in the third-party components based on CVE information, and calculate the vulnerable function layer distance, pre-function, and function priority according to the overall function call graph for directed utility calculation, which is used for fuzz testing energy allocation; Step s4: Identify key nodes and calculate vulnerability distances for the critical functions of the third-party libraries in the overall function call graph; Step s5: Pass the binary static analysis results of Step s1 to Step s4 to a fuzz testing tool for directed fuzz testing; the directed fuzz testing is to perform seed selection, energy allocation, seed and program execution according to the static analysis results, and conduct one round of fuzz testing.

[0027] In a specific application example, in Step s1, select the binary program tiffcrop, analyze the directly and indirectly dependent third-party libraries layer by layer based on existing tools, form a third-party library dependency graph with the binary program as the starting node, each node in the graph represents a unique program or third-party library, and store it using networkx.

[0028] See Figure 2 、 Figure 3 and Figure 4 In a specific application example, in Step s2, it may include the following processes according to actual needs: Step s21: For the binary program of the third-party library dependency graph and each directly or indirectly dependent third-party library, use the binary analysis tool Angr to analyze their respective function call graphs; Step s22: Use the binary analysis tool nm to analyze the dynamic symbol tables of the binary program and all third-party libraries, and filter to obtain the dynamically linked library functions called by each as the critical functions of each third-party library; Step s23: Based on the function call graphs generated by Angr and the obtained critical functions, construct the overall function call graph of the binary program layer by layer.

[0029] Among them, the overall function call graph includes the call relationship between the main program and each library, and the call process between the library and its dependent dynamically linked libraries.

[0030] Furthermore, each node of the overall function call graph represents a unique function, which includes three attributes: function name, function address, and the name of the binary program or third-party library to which it belongs, and is stored using networkx.

[0031] In a specific application example, in step s3, all vulnerable functions are obtained based on the vulnerability CVE-2023-3618 information, and it can be known that they affect the Fax3Encode function in the third-party library libtiff; according to the overall function call graph, the three input indicators of function layer distance, predecessor function and function priority are calculated for the energy allocation stage of directed fuzz testing.

[0032] As a preferred embodiment, step s3 includes: (1) Function layer distance; The function layer distance refers to the distance from a program function to all vulnerability functions.

[0033] Assume that the set of vulnerable functions is , for any function in the program , its distance to the vulnerability function The calculation formula is shown in (1).

[0034] (1) For function The set of reachable vulnerable functions; For function n to the vulnerable function The number of nodes in the shortest path, in particular, when For a vulnerable function, is 1. In this way, the function layer distance of each function in the program can be obtained.

[0035] (2) Prefix function; The predecessor functions are all functions in the program that have a path to the vulnerable function. For each function in the program, we determine whether there is a path to the vulnerable function. If there is a path, we mark that function as a predecessor function. This way, we can find the predecessor functions in the program.

[0036] (3) Function priority; The function priority refers to the inverse of the distance between a program function and all vulnerability functions.

[0037] Assume that the set of vulnerable functions is , for any function of the program , and its function priority calculation formula is shown in (2).

[0038] (2) For function The set of reachable vulnerable functions; For function n to the vulnerable function The number of nodes in the shortest path. In this way, the priority of each function in the program can be obtained.

[0039] In a specific application example, in step s4, through key point recognition, key points and the distances of key points are obtained. The key points are critical functions in the program that can reach the vulnerability function, and its process includes: In the construction of the overall function call graph, the critical functions of the program and the third-party libraries have been obtained. For each critical function, determine whether it is a pre-function. If it is a pre-function, then mark it as a key point; For each key point, obtain the name of the third-party library to which the key point belongs through the overall function call graph; Based on the third-party library dependency graph, calculate the average distance from the third-party library to which the key point belongs to all the third-party libraries to which the vulnerability functions belong and use it as the distance of the key point; Obtain all the key points of the program and the distances of the key points.

[0040] In specific applications, such as Figure 5 shown, the function layer distance of the function TIFFWriteTile is 3.0, the function priority is 0.333, and it is a pre-function and a key point, and the key point distance is 1.0; the function layer distance of the function writeBufferToSeparateTiles is 4.0, the function priority is 0.25, it is a pre-function but not a key point. Similarly, the function layer distance of the function TIFFWriteEncodedTile is 2.0, the function priority is 0.5, it is a pre-function but not a key point. And the function TIFFFillStrip is not a pre-function and not a key point.

[0041] In a specific application example, in step s5, after sufficient static analysis of the binary program, directed fuzz testing is started. The directed fuzz testing includes main modules such as seed selection, energy allocation, seed mutation, and program execution. Among them: (1) Seed selection; In fuzz testing, the seed queue refers to a set of initial inputs or seeds used to generate test cases. A good seed selection strategy can significantly improve the fuzzing efficiency. The present invention preferentially selects seeds that contain more key points and the key points are closer to the target.

[0042] Specifically, after each execution of the program, record the execution trace of the program and obtain the function call path of the function. Assume the seed queue is , for any seed , its function call path is , the key points of this function call path are , and the distance of any key point is , where .

[0043] Then, for the seed the priority calculation formula is as shown in (3) (3) Through the above formula, all priorities of the seed queue can be obtained, which are . In each round of fuzz testing, seeds with high priority and not yet selected are preferentially selected for energy allocation and seed mutation.

[0044] (2) Energy allocation; In the directed utility calculation, three input metrics of function layer distance, pre-function, and function priority are obtained. The execution path of any one seed is , its function call set is , the corresponding pre-function set is , the function layer distance corresponding to the pre-function is , the function priority corresponding to the function call set is , where . Then, the function layer distance calculation formula for the execution path is as shown in (4), the number of pre-functions is , and the priority calculation formula corresponding to the execution path is as shown in (5).

[0045] (4) (5) Normalize the function layer distance, the number of pre-functions, and the priority of the execution path s respectively, as shown in formulas (6), (7), and (8).

[0046] (6) (7) (8) The energy allocation link is responsible for allocating more computing energy to seeds with high efficiency. If the execution path of the current seed is closer to the vulnerable function in the program, more energy should be obtained on this seed. For the seed the energy allocation calculation formula is as shown in (9). The higher

[0047] (9) Finally, conduct directed fuzz testing on the program tiffcrop for more than 24 hours. The test results are as Figure 6As shown, there are a total of 114 uniq crashes. For one of the crash tests, such as Figure 7 shown, the execution path passes through the vulnerable function Fax3Encode, proving that the cause of the tiffcrop crash is a segmentation fault caused by the CVE-2023-3618 vulnerability.

[0048] The above are only the preferred embodiments of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions within the idea of the present invention belong to the protection scope of the present invention. It should be pointed out that for those of ordinary skill in the art, several improvements and refinements made without departing from the principle of the present invention should be regarded as within the protection scope of the present invention.

Claims

1. A method for generating verification code for software supply chain vulnerabilities based on guided fuzz testing, characterized in that Including: Step s1: Generate a three-party library dependency graph with the binary program as the starting node; Step s2: Perform static component analysis on the target application software component to form a component dependency graph; Analyze the component dependency graph layer by layer to construct an overall function call graph; Step s3: Match all vulnerable functions existing in the three-party components based on CVE information, and calculate the layer distance, pre-function, and function priority of the vulnerable functions according to the overall function call graph for directed utility calculation, which is used for fuzz testing energy allocation; Step s4: Identify critical nodes and calculate vulnerability distances for the three-party library critical functions in the overall function call graph; Step s5: Pass the binary static analysis results of steps s1 to s4 to the fuzz testing tool for directed fuzz testing.

2. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 1, wherein In step s1, select the binary program tiffcrop, analyze the directly and indirectly dependent three-party libraries layer by layer based on the existing tools, form a three-party library dependency graph with the binary program as the starting node, each node in the graph represents a unique program or three-party library, and store it using networkx.

3. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 1, wherein, The said step s2 includes: Step s21: For the binary program of the three-party library dependency graph and each directly or indirectly dependent three-party library, use the binary analysis tool Angr to analyze their respective function call graphs; Step s22: Use the binary analysis tool nm to analyze the dynamic symbol tables of the binary program and all three-party libraries, and filter out the dynamically linked library functions called by each as the critical functions of each three-party library; Step s23: Based on the function call graph generated by Angr and the obtained critical functions, construct the overall function call graph of the binary program layer by layer.

4. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 3, characterized in that The overall function call graph includes the call relationship between the main program and each library, and the call process between the library and its dependent dynamically linked libraries.

5. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 3, wherein Each node of the overall function call graph represents a unique function, which includes three attributes: function name, function address, and the name of the binary program or three-party library to which it belongs, and is stored using networkx.

6. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 1, wherein In step s3, based on the vulnerability CVE-2023-3618 information, obtain all vulnerable functions, and learn that it affects the Fax3Encode function in the three-party library libtiff; calculate three input metrics: function layer distance, pre-function, and function priority according to the overall function call graph for the energy allocation stage of directed fuzz testing.

7. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 6, wherein The said step s3 includes: (1) Function layer distance; The function layer distance refers to the distance from the function of the program to all vulnerable functions; (2) Pre-function; The pre-function refers to all functions in the program that have a path to reach the vulnerable function; for each function in the program, judge whether there is a path to reach a certain vulnerable function, if there is a path, mark this function as a pre-function; (3) Function priority; The function priority refers to the reciprocal of the distance from the function of the program to all vulnerable functions.

8. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 1, wherein The said step s4 includes: In the construction of the overall function call graph, the critical functions of the program and the third-party libraries have been obtained; for each critical function, it is judged whether it is a pre-function, and if it is a pre-function, it is recorded as a key point; For each key point, the name of the third-party library to which the key point belongs is obtained through the overall function call graph; Based on the third-party library dependency graph, the average distance from the third-party library to which the key point belongs to all the third-party libraries to which the vulnerability functions belong is calculated and used as the distance of the key point; All the key points of the program and the distances of the key points are obtained.

9. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to any one of claims 1-8, characterized in that, The step s5 includes: seed selection; in fuzz testing, the seed queue refers to a set of initial inputs or seeds used to generate test cases; after each execution of the program, the execution trace of the program is recorded, and the function call path of the function is obtained; all the priorities of the seed queue are obtained, and in each round of fuzz testing, the seeds with large priorities and not yet selected are preferentially selected for energy allocation and seed mutation.

10. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to any one of claims 1-8, characterized in that The step s5 includes: energy allocation; three input metrics, namely, the function layer distance, the pre-function, and the function priority, are obtained through directed utility calculation; the execution path of any seed is , and priority calculation is performed; then, the energy allocation link is responsible for allocating more computing energy to seeds with high efficiency; if the current seed execution path is closer to the vulnerable function in the program, more energy should be obtained on this seed.

Images