Software supply chain vulnerability verification code generation method based on guided fuzz testing

Abstract

The present invention discloses a software supply chain vulnerability verification code generation method based on guided fuzz testing, which includes the following steps: s1: generating a three-party library dependency graph with a binary program as the starting node; s2: performing static component analysis on the target application software component to form a component dependency graph; performing layer-by-layer analysis on the component dependency graph to construct an overall function call graph; s3: matching all existing vulnerable functions in the three-party components based on CVE information, and calculating the vulnerable function layer distance, predecessor function, and function priority based on the overall function call graph to perform directed utility calculation for fuzz testing energy allocation; s4: identifying key nodes and calculating vulnerability distance for critical functions in the three-party libraries in the overall function call graph; and s5: transmitting the binary static analysis results from s1 to s4 to a fuzz testing tool for directed fuzz testing. The present invention has the advantages of simple principle, easy implementation, stronger testing capability, and better applicability.

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:

[0008] A method for generating software supply chain vulnerability verification code based on guided fuzz testing, comprising:

[0009] Step s1: Generate a tripartite library dependency graph starting with the binary program;

[0010] 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;

[0011] 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;

[0012] Step s4: Identify key nodes and calculate vulnerability distances for the critical functions of the tripartite library in the overall function call graph;

[0013] Step s5: Pass the binary static analysis results from steps s1 to s4 to the fuzz testing tool for directed fuzz testing.

[0014] 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.

[0015] As a further improvement of the present invention: step s2 includes:

[0016] 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;

[0017] 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;

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] As a further improvement of the present invention: the step s3 includes:

[0023] (1) Function layer distance: The function layer distance refers to the distance from the program function to all vulnerable functions;

[0024] (2) Predecessor functions: The predecessor functions refer to all functions in the program that have paths to the vulnerable function. For each function in the program, determine whether there is a path to a vulnerable function. If there is a path, mark the function as a predecessor function.

[0025] (3) Function priority: The function priority refers to the inverse of the distance from a program function to all vulnerable functions.

[0026] As a further improvement of the present invention: step s4 includes:

[0027] In the overall function call graph construction, 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. If it is a predecessor function, it is recorded as a key point.

[0028] 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;

[0029] Based on the third-party library dependency graph, calculate the average distance between the third-party library to which the key point belongs and the third-party libraries to which all vulnerable functions belong and use this distance as the distance of the key point;

[0030] Get all the key points of the program and the distances between them.

[0031] As a further improvement of the present invention: step s5 includes: seed selection; in fuzz testing, a seed queue refers to a set of initial inputs or seeds used to generate test cases; after each execution of the program, the execution trajectory of the program is recorded, and the execution function call path of the function is obtained; all priorities of the seed queue are obtained, and in each round of fuzz testing, seeds with high priorities and that have not been selected are preferentially selected for energy allocation and seed mutation.

[0032] As a further improvement of the present invention: the step s5 includes: energy allocation; three input indicators, function layer distance, pre-function and function priority, are obtained through directed utility calculation; the execution path of any seed is , perform priority calculation; 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, then the seed should get more energy.

[0033] Compared with the prior art, the advantages of the present invention are:

[0034] The present invention's method for generating software supply chain vulnerability verification code based on guided fuzz testing offers a simple principle, ease of implementation, enhanced testing capabilities, and improved applicability. By generating verification code based on supply chain vulnerability information based on guided fuzz testing, the method focuses testing on vulnerability-related code paths based on provided vulnerability location information, conducting targeted fuzz testing exploration. This method improves the ability to detect security flaws in software binary files caused by supply chain vulnerabilities.

[0035] 2. In view of the shortcomings of existing fuzz testing technology in binary file vulnerability detection, the present invention designs a software supply chain vulnerability verification code generation method based on guided fuzz testing. The present invention can further improve the fuzz testing efficiency of binary file vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 It is a schematic diagram of the process of the present invention in a specific embodiment.

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

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

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

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

[0041] Figure 6 It is a schematic diagram of the directional fuzzy test results of the Tiffcrop program in a specific embodiment of the present invention.

[0042] Figure 7 It is a schematic diagram of the crash test results of the program Tiffcrop in a specific embodiment of the present invention. DETAILED DESCRIPTION

[0043] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0044] like Figure 1 As shown, the present invention provides a method for generating software supply chain vulnerability verification code based on guided fuzz testing, which includes:

[0045] Step s1: Generate a tripartite library dependency graph starting with the binary program;

[0046] 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 ;

[0047] 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;

[0048] Step s4: Identify key nodes and calculate vulnerability distances for the critical functions of the tripartite library in the overall function call graph;

[0049] Step s5: passing the binary static analysis results of steps s1 to s4 to the fuzz testing tool for directed fuzz testing; the directed fuzz testing is to perform seed selection, energy allocation, seed and program execution based on the static analysis results to perform a round of fuzz testing.

[0050] In a specific application example, in 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.

[0051] See also Figure 2 、 Figure 3 and Figure 4 In a specific application example, step s2 may include the following process according to actual needs:

[0052] 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;

[0053] 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;

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] As a preferred embodiment, step s3 includes:

[0059] (1) Function layer distance;

[0060] The function layer distance refers to the distance from a program function to all vulnerability functions.

[0061] 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).

[0062] (1)

[0063] 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.

[0064] (2) Prefix function;

[0065] 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.

[0066] (3) Function priority;

[0067] The function priority refers to the inverse of the distance between a program function and all vulnerability functions.

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

[0069] (2)

[0070] For function The set of reachable vulnerable functions; For function n to the vulnerable function This gives the priority of each function in the program.

[0071] In a specific application example, in step s4, key points and key point distances are obtained through key point identification. The key points are critical functions in the program that can reach the vulnerability function. The process includes:

[0072] In the overall function call graph construction, 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. If it is a predecessor function, it is recorded as a key point;

[0073] 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;

[0074] Based on the third-party library dependency graph, calculate the average distance between the third-party library to which the key point belongs and the third-party libraries to which all vulnerable functions belong and use this distance as the distance of the key point;

[0075] Get all the key points of the program and the distances between them.

[0076] In specific applications, such as Figure 5 As shown, the function TIFFWriteTile has a function layer distance of 3.0 and a function priority of 0.333. It is also a predecessor function and a keypoint, and its keypoint distance is 1.0. The function writeBufferToSeparateTiles has a function layer distance of 4.0 and a function priority of 0.25, making it a predecessor function but not a keypoint. Similarly, the function TIFFWriteEncodedTile has a function layer distance of 2.0 and a function priority of 0.5, making it a predecessor function but not a keypoint. The function TIFFFillStrip is not a predecessor function and is not a keypoint.

[0077] In a specific application example, in step s5, after a full static analysis of the binary program, a directed fuzz test is started. The directed fuzz test includes the following main modules: seed selection, energy allocation, seed mutation, and program execution.

[0078] (1) Seed selection;

[0079] In fuzz testing, a seed queue refers to a set of initial inputs or seeds used to generate test cases. A good seed selection strategy can significantly improve fuzzing efficiency. The present invention prioritizes seeds that contain more key points, and those that are closer to the target.

[0080] Specifically, after each execution of the program, the execution trace of the program is recorded and the execution function call path of the function is obtained. Assume that the seed queue is , for any seed , and its function call path is , the key point of the function call path is , any key point The distance is ,in .

[0081] So, the seeds The priority calculation formula is shown in (3)

[0082] (3)

[0083] Through the above formula, we can get all the priorities of the seed queue, which is In each round of fuzz testing, seeds with high priority and not yet selected are selected for energy allocation and seed mutation.

[0084] (2) Energy distribution;

[0085] The three input indicators of function layer distance, preceding function and function priority are obtained in the directed utility calculation. The execution path of any seed is , whose function call set is , the corresponding set of pre-functions is , the function layer distance corresponding to the pre-function is , the function priority corresponding to the function call set is ,in Then, the execution path The function layer distance calculation formula is shown in (4), and the number of pre-functions is , the execution path is The corresponding priority calculation formula is shown in (5).

[0086] (4)

[0087] (5)

[0088] The function layer distance, number of preceding functions and priority of the execution path s are normalized respectively, as shown in formulas (6), (7) and (8).

[0089] (6)

[0090] (7)

[0091] (8)

[0092] The energy allocation process 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, the seed should receive more energy. The calculation formula for energy distribution is shown in (9). The higher it is, the more energy is distributed.

[0093] (9)

[0094] Finally, the program tiffcrop was subjected to a directional fuzz test for more than 24 hours. The test results are as follows: Figure 6 As shown in the figure, there are 114 uniq crashes. For one of the crash tests, Figure 7 As 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.

[0095] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions based on the principles of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A software supply chain vulnerability verification code generation method based on guided fuzz testing, characterized in that: include: 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; Analyze the component dependency graph layer by layer to build the overall function call graph; Step s3: Match all vulnerable functions in the third-party components based on CVE information, and calculate the vulnerable function layer distance, predecessor function and function priority according to the overall function call graph for directed utility calculation for fuzz test energy allocation; based on the vulnerability CVE-2023-3618 information, obtain all vulnerable functions and know that they affect the Fax3Encode function in the third-party library libtiff; calculate the function layer distance, predecessor function and function priority according to the overall function call graph for the energy allocation stage of directed fuzz testing; the function layer distance refers to the distance from the program function to all vulnerable functions; the predecessor function refers to all functions in the program that have a path to the vulnerable function; for each function of the program, determine whether there is a path to a vulnerable function. If there is a path, mark the function as a predecessor function; the function priority refers to the inverse of the distance from the program function to all vulnerable functions; 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.

2. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 1, characterized in that: In step s1, the binary program tiffcrop is selected, and the directly 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.

3. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 1, characterized in that: The step s2 comprises: 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.

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 calling relationship between the main program and each library, and the calling process between the library and the dynamic link library it depends on.

5. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 3, characterized in that: 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.

6. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to claim 1, characterized in that: The step s4 comprises: In the overall function call graph construction, 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. If it is a predecessor 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, calculate the average distance between the third-party library to which the key point belongs and the third-party libraries to which all vulnerable functions belong and use this distance as the distance of the key point; Get all the key points of the program and the distances between them.

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

8. The method for generating software supply chain vulnerability verification code based on guided fuzz testing according to any one of claims 1 to 6, characterized in that: The step s5 includes: energy allocation; obtaining three input indicators, namely, function layer distance, pre-function and function priority, through directed utility calculation; the execution path of any seed is , perform priority calculation; 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, the seed will obtain more energy.

Images