LLM-enhanced project dependency library vulnerability step-by-step exploitation method

Abstract

The present application belongs to the technical field of software engineering, and specifically relates to a project dependency library vulnerability step-by-step exploitation method based on LLM enhancement. The method comprises the following steps: performing lightweight dependency tree and call graph reachability analysis on a project, and identifying all reachable call chains from the project to a vulnerability method; decomposing the fuzz testing on the entire call chain into directional fuzz testing on each step method call in the call chain; combining static analysis and hint engineering technology, and utilizing the semantic understanding of the current test function and the exploitation information generated by the previous step test by using LLM to assist in seed generation. The generated seed is used for directional fuzz testing, and the execution path of the seed is analyzed through an execution feedback mechanism to guide the selection and mutation of the seed, and finally an effective input capable of successfully exploiting the project dependency library vulnerability is generated. The present application can help developers quickly locate and timely repair vulnerabilities, thereby reducing the risk and potential loss brought by dependency vulnerabilities to a project.

Description

Technical Field

[0001] The present invention belongs to the technical field of software engineering, and in particular relates to a method for exploiting a vulnerability in a project dependency library in a step-by-step manner. Background Art

[0002] Open source third-party component libraries play a vital role in modern software development, providing developers with a wealth of basic functions. By declaring these components as dependencies in the project, developers can efficiently reuse the functions in them, thereby significantly reducing development time and labor costs[1][2][3][4][5]. Therefore, more and more developers are widely adopting open source component libraries in their projects. Take Maven as an example. As the most widely used component library repository in the Java ecosystem, its average monthly downloads have reached 3.78 billion times[6]. Among these downloads, about 397 million components have vulnerabilities[6]. Therefore, this practice of relying on open source component libraries may spread vulnerabilities in third-party component libraries to downstream projects through the dependency chain, thereby exposing these projects to security threats brought by the vulnerabilities. Take the Log4Shell vulnerability (CVE-2021-44228) in the Apache Log4j library as an example. As of December 16, 2021, the vulnerability has affected 35,863 Java libraries, accounting for more than 8% of all Maven Central libraries[7]. Furthermore, downstream projects often have difficulty fixing these vulnerabilities in a timely manner because the vulnerabilities may be introduced through transitive dependency chains. The deeper the vulnerability is in the dependency chain, the more steps are required to fix it. For example, among the component libraries affected by the Log4Shell vulnerability, only about 7,000 (19.5%) are direct dependencies [7]. Although the release of new versions of the library can fix these vulnerabilities, developers often neglect to update dependencies in a timely manner for fear of compatibility issues [5][8]. This leaves their projects continuously exposed to security risks that can be exploited.

[0003] In response to the security risks brought by vulnerabilities in component libraries, a variety of analysis and mitigation methods have been proposed. Vulnerability existence analysis uses software component analysis to extract the dependency tree of the project and check whether there is a vulnerable component library [9]

[10]

[11] . However, these methods fail to consider whether the project actually calls the vulnerable function, resulting in a high false positive rate. To address this problem, vulnerability reachability analysis uses call graph generation technology to construct the call graph of the project and check whether there is a call chain leading to the vulnerable method

[12]

[13]

[14]

[15]

[16]

[17] . However, these methods also fail to evaluate whether the project can actually trigger the vulnerability and still produce false positives.

[0004] In response to the above problems, some studies have proposed to analyze the exploitability of vulnerabilities in open source component libraries

[18]

[19]

[20] . Siege

[19] targets the vulnerable code in the vulnerable component library and guides EvoSuite

[21] to generate test cases so that the project can reach the vulnerable code. Transfer

[20] targets the program state when the vulnerable method is called in the vulnerability triggering test case of the vulnerable component library and guides EvoSuite to generate test cases so that the project can call the vulnerable method under the same program state. Vesta

[18] generates test cases for the project through EvoSuite to reach the vulnerable method, and then migrates the parameters of the vulnerability triggering test cases in the vulnerability library to these generated test cases based on predefined rules. The test cases generated by these methods can be considered as means of exploiting the vulnerabilities in the component library triggered by the project side. These methods perform well in simple scenarios (i.e., the project directly calls the vulnerable method). However, in complex scenarios (i.e., the project indirectly calls the vulnerable method through a multi-step call chain), the vulnerability exploitation process becomes more complicated, making it difficult for these methods to generate effective exploits. As reported by Wu et al.

[22] , most call chains leading to vulnerability methods involve multiple steps. However, most experimental validation datasets of these methods only consider simple scenarios and fail to fully evaluate their actual effects in complex scenarios. Summary of the Invention

[0005] The purpose of the present invention is to provide a step-by-step method for exploiting project dependency library vulnerabilities based on a large language model (LLM) enhancement that is easy to operate and can efficiently generate and effectively utilize.

[0006] The present invention provides a step-by-step method for exploiting project dependency library vulnerabilities based on LLM enhancement, including:

[0007] First, we perform lightweight dependency tree analysis and call graph construction on the project to identify all reachable call chains leading to vulnerable methods in the project.

[0008] Next, the fuzz testing process of the entire call chain is refined into targeted fuzz testing for each method call;

[0009] Then, we use context-sensitive static analysis, combined with hint engineering, to deeply understand the semantics of the current test function using LLM to assist in generating seed templates.

[0010] Then, the seed template derived by LLM is used to instantiate the seed parameters and receiving objects to generate the initial seed;

[0011] Finally, the execution path of the seed is analyzed through the execution feedback mechanism to guide the selection and mutation of the seed, and finally generate effective exploit input for the dependency library vulnerability.

[0012] Further, the specific operations of each step are described as follows:

[0013] (1) Perform lightweight analysis of the project's dependency tree and construct a call graph to identify all reachable call chains leading to the vulnerable methods in the project. The specific process is as follows:

[0014] First, the dependency tree of the client project is generated using the Maven command "mvn dependency:tree". The dependencies are filtered to remove dependencies that are only used for testing. Subsequently, the dependency tree is traversed using depth-first search (DFS), recording the path from the project root node to each vulnerable dependency, thereby building a "vulnerability-aware dependency tree". Next, the JAR files corresponding to all dependencies in the vulnerability-aware dependency tree are downloaded, and the Soot

[23] tool is used to generate a call relationship graph between the project and its dependencies. Finally, DFS is performed on the call graph, starting from each public function in the project, to identify the reachable call chain leading to the vulnerable method. This process helps identify dependencies and function call chains related to known vulnerabilities in the project.

[0015] (2) The fuzz testing process of the entire call chain is refined into a targeted fuzz test for each method call; the specific process is: perform LLM-enhanced targeted fuzz testing step by step, first extracting the exploit context of each call step. A complete reachable call chain can be denoted as F i →F i-1 →…→F0, where F0 is the vulnerable method in the project dependency library. For each step of the calling process <F i ,F i-1 >, the called function F is extracted from the known vulnerability exploit test cases in the vulnerability database or the exploit input generated in the previous test step i-1 The use context of F. This context records the use context of F. i-1 →…→F0 to exploit the program state required by vulnerability method F0.

[0016] In order to extract the vulnerability context, ASM

[24] is used to insert code at the beginning of the function body to execute F i-1 Record the parameters passed and the receiving object. i-1 If it is a constructor or static function, the inserted code only records the passed parameters; otherwise, it records both the parameters and the receiving object. Finally, execute F i-1 The exploit input is collected, and the parameters and received objects passed during its execution are collected, thereby successfully extracting the context of vulnerability exploitation.

[0017] (3) Using context-sensitive static analysis, combined with hint engineering, and using LLM to deeply understand the semantics of the current test function, we can assist in generating seed templates. The details are as follows:

[0018] Call at each step <F i ,F i-1 >, use LLM to infer how to set up the call F i The receiving object and the one passed to F i parameters to ensure that the F i Call F i-1 In theory, these receiving objects and parameters can be expressed as expressions on the data flow, called seed templates Since data flow analysis is used in the derivation There are limitations when using fuzzy_test, so LLM is used for approximate deduction. This method designs a prompt to generate fuzz test seed templates; the specific process is as follows:

[0019] By extracting key codes, LLM is prevented from being disturbed by irrelevant codes. First, JD-Core

[25] is used to decompile the JAR file, and JavaParser

[26] is used to extract the code related to calling F i-1 The relevant code section retains the last call to F i-1 Based on this, we use breadth-first search (BFS) to find related functions and fields in the code and generate a key code set. To ensure the relevance of the code and avoid exceeding the token limit of LLM, only the code related to F is retained during the search process. i Classes in the same dependency, and the search depth limit is set to 2. Finally, the key code is pruned, keeping only the functions and fields found during the search, and comparing them with the pruned F i Code splicing to form a complete key code set. Then, use LLM to generate seed templates

[0020] (4) Use the seed template derived from LLM to instantiate the seed parameters and receiving objects to generate the initial seed; specifically, the seed template is represented in JSON format, and it is necessary to parse the symbols in the template and assign values ​​to generate the initial seed.

[0021] Since LLM may have shortcomings when processing received objects, these inference results need to be supplemented by static analysis. Specifically, if the two functions belong to the same class, it is necessary to traverse all fields in the received object and assign non-null fields to corresponding values. If the two functions do not belong to the same class, it is necessary to use context-sensitive reverse taint analysis to determine the source of the received object and correctly assign it to the corresponding fields.

[0022] (5) Analyze the execution path of the seed through the execution feedback mechanism, guide the selection and mutation of the seed, and ultimately generate effective exploit input for the dependency library vulnerability;

[0023] Specifically, we use the synthesized seed as the initial input to conduct directed fuzz testing, aiming to generate exploits for project dependency library vulnerabilities. During this process, we classify the variables in the seed into three categories:

[0024] (1) Vulnerability exploitation-related variables: These variables have data flow relationships with the receiving objects and parameters during execution and may affect vulnerability exploitation;

[0025] (2) Control flow related variables: These variables control the execution path and branch decisions of the program, affecting the reachability of the target function;

[0026] (3) Other variables: These variables are not related to branch conditions and vulnerability exploitation.

[0027] The specific process is:

[0028] Utilize context-sensitive reverse taint analysis to mark and track vulnerability exploitation-related variables and control flow-related variables, and classify them into corresponding categories;

[0029] In order to effectively select and mutate seeds, JaCoCo

[27] is used to perform coverage analysis on the execution path of the seeds. The fitness score is calculated based on the distance between the number of code lines covered during the seed execution process and the distance to the target function. The seeds with smaller fitness scores are closer to the vulnerability method during the execution process, and are selected for execution and mutation first.

[0030] JaCoCo uses different mutation strategies for different categories of variables: control flow-related variables are assigned a higher mutation probability (for example, 0.7-0.9) to explore more execution paths and increase the chance of reaching the target function; vulnerability exploitation-related variables, because these variables usually contain specific vulnerability exploitation information, have a lower mutation probability (for example, 0.1-0.3); other variables, because they are not related to vulnerability exploitation, are not mutated.

[0031] Furthermore, during the seed mutation process, the data structure type of the variable can also be considered. Specifically, there are three types of data structures:

[0032] (1) Basic types: represent basic data types, such as integer, floating-point, character, etc. They contain values ​​directly without referencing external objects;

[0033] (2) Reference type: object type, such as a class instance or interface;

[0034] (3) Array type: a special reference type that represents a collection of elements of the same type. Each element in the array can be accessed through an index.

[0035] When a seed is mutated, specific processing is performed based on the variable's data structure type. For primitive types, a random value is directly generated; for reference types, a subclass object is instantiated or a random value is assigned to the instance's fields; for array types, a new array is created or an element in an existing array is mutated.

[0036] It's important to note that the data structure types of the variables listed above (primitive, reference, and array) are not mutually exclusive with the three aforementioned categories of variables (exploit-related, control-flow-related, and other variables). For example, control-flow-related variables can be primitive, array, or reference types; similarly, exploit-related variables can also belong to one of these data structures. Therefore, the seed mutation process requires comprehensive consideration of both the variable type and its specific data structure.

[0037] The basic process diagram of the present invention is as follows Figure 1 As shown. The present invention uses vulnerability reachability analysis to identify the reachable call chain from the project to the vulnerable method. Then, using step-by-step directed fuzz testing, each function in the call chain is gradually generated for vulnerability exploitation input. Through prompt engineering and combined with static analysis, the LLM is used to infer the input state of the calling function to generate an initial fuzz test seed. Finally, the generated seed is optimized through an execution feedback mechanism to generate an exploit input that can successfully exploit the vulnerability. The method of the present invention can help developers automatically detect and generate exploit input for vulnerabilities in dependent libraries, effectively reducing the risks and losses caused by dependent vulnerabilities in projects.

[0038] The technical features and performance advantages of the present invention mainly include:

[0039] A step-by-step fuzz testing approach is proposed, breaking down the targeted fuzz testing of the entire call chain into independent fuzz testing of each step, gradually resolving vulnerability exploitation issues in complex call chains. This step-by-step approach effectively reduces the difficulty of generating effective vulnerability exploits in multi-step call scenarios. It leverages the semantic understanding of LLM code to generate initial test seeds, thereby improving the success rate of fuzz testing. This LLM-based approach enhances the ability to handle complex code logic and generates more accurate test inputs by introducing semantic understanding. It also employs an execution feedback mechanism, combining static and dynamic analysis, to further improve the efficiency of the fuzz testing process. In particular, when LLM inferences are inaccurate, fuzz testing feedback can be used to correct seeds and parameters, significantly improving the success rate of exploit generation.

[0040] This invention can effectively help developers detect whether their development projects are affected by vulnerabilities in dependent libraries; by generating exploit inputs for project dependent library vulnerabilities, it helps developers quickly locate and promptly fix vulnerabilities, thereby reducing the risks and potential losses brought by dependent vulnerabilities to the project. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is a schematic diagram of the basic process of the present invention.

[0042] Figure 2 Extract vulnerability exploit samples for CVE.

[0043] Figure 3 A reachable call chain affected by the vulnerability.

[0044] Figure 4 A step-by-step example of exploiting a vulnerability in a project's dependency library.

[0045] Figure 5 Generate a Prompt example diagram based on the LLM-enhanced fuzz testing seed template.

[0046] Figure 6 An example diagram of the fuzz testing seed template generation results based on LLM enhancement. DETAILED DESCRIPTION

[0047] The following describes a specific embodiment of the present invention for the automated generation of vulnerability exploits in project dependency libraries. The process is as follows:

[0048] (1) Vulnerability accessibility analysis. Before conducting vulnerability accessibility analysis, it is necessary to build a vulnerability database to support subsequent accessibility analysis and vulnerability exploitation. Here, it is necessary to collect vulnerability data related to open source component libraries. The data sources include vulnerability information publicly available in platforms such as the National Vulnerability Database (NVD), GitHub, and Maven. By screening vulnerabilities with patch links in NVD (such as GitHub submission records), relevant information is extracted, including vulnerability IDs (such as CVE numbers), affected dependent library versions, vulnerability method signatures, and test cases that can exploit the vulnerabilities. To ensure the accuracy of the data, we further verify the patch information and convert the corresponding test cases into JUnit format exploitation samples. Figure 2 This article demonstrates a test case exploiting vulnerability CVE-2019-10086 from the vulnerability database. The vulnerability is triggered when the PropertyUtils.getProperty() method is passed a bean object and the string "class" as input. Because bean objects do not contain a field named "class," an exception should be thrown. However, during actual execution, the method incorrectly returns the bean object's Class bytecode object, successfully exploiting the vulnerability.

[0049] After building the vulnerability database, we perform lightweight dependency tree analysis and call graph analysis on the project to construct the project's dependency tree and its full method call graph. By traversing the call graph and combining it with knowledge from the vulnerability database, we identify all reachable call chains from the project to vulnerable methods in dependent libraries. This step yields several reachable call chains between the project and vulnerable methods in dependent libraries. Figure 3 Shows an identified reachable call chain:

[0050] org.apache.commons.beanutils.PropertyUtils:java.lang.Object;

[0051] getProperty(java.lang.Object,java.lang.String) is the method signature affected by the CVE-2019-10086 vulnerability, while org.apache.commons.validator.util.ValidatorUtils:java.lang.String getValueAsString(java.lang.Object,java.lang.String) is the function that directly calls the vulnerable method in the development project.

[0052] (2) Step-by-step vulnerability exploit generation process. After identifying the reachable call chain, each reachable call chain will be subjected to targeted fuzz testing. Here, the targeted fuzz testing of the entire call chain is decomposed into step-by-step targeted fuzz testing of each function call in the call chain. First, start from the end of the call chain, that is, from the vulnerable method in the dependent library, and gradually analyze to the calling function in the client project.

[0053] Figure 4This document demonstrates the step-by-step exploitation of the CVE-2019-10086 vulnerability. The Form.validate function sequentially calls Field.validate, Field.getIndexedPropertySize, and ultimately the PropertyUtils.getProperty function. To successfully exploit the vulnerability, the second parameter of PropertyUtils.getProperty (i.e., the return value of getIndexedListProperty) must be "class" in the instance object of the getIndexedPropertySize method. This means that the value of the indexedListProperty field must be set to "class" in the instance object of the getIndexedPropertySize method. When this instance object executes getIndexedPropertySize, passing an Object instance triggers the vulnerability. When Field.validate calls Field.getIndexedPropertySize, the parameter bean passed to getIndexedPropertySize comes from the params object in line 43. params is the first parameter of the validate method, a Map object used to retrieve the value of the key "java.lang.Object". Therefore, in order to exploit this vulnerability through the validate method, params must be set to {"java.lang.Object":Object instance}. At the same time, when validate executes and calls the getIndexedPropertySize statement, the program state at this time must remain consistent with the program state when the getIndexedPropertySize vulnerability was exploited.

[0054] (3) Extraction of vulnerability exploit context. The exploit context of the vulnerability method is directly obtained from the vulnerability test cases in the vulnerability database, such as Figure 2 As shown, the bean object and "class" constitute the exploit context for the vulnerable method. This context can be obtained by instrumenting and executing the vulnerability test case. The exploit context for other methods in the call chain is obtained through fuzz testing. The exploit context generated at each step helps synthesize the fuzz test seed for the next step.

[0055] (4) LLM-assisted seed generation. For each function call in the call chain, LLM is used to infer the input state required by the calling function through hint engineering to ensure that the called function can execute correctly. LLM analyzes the code of the calling function to understand its semantics and combines it with the exploit input generated in the previous fuzz testing step to generate the initial fuzz testing seed based on the inference results of LLM. Figure 5 This section shows the prompt used during LLM seed template inference. It includes key code snippets [%CODE%], the caller function code [%CALLER%], the called function code [%CALLEE%], as well as the required parameters [%ARGS%] and the receiver object [%RO%]. It primarily describes the function call process and parameter passing. It symbolically illustrates the target function's receiver object and input parameters, aiming to ensure the correct execution of the called target function by setting the receiver object's field properties and function parameters. This prompt accurately captures the data flow and control flow relationships within the code, facilitating code analysis and semantic understanding of function calls. Figure 6 The example shows the result of LLM inference seed template, which is in JSON format and contains key-value mapping of field properties (FieldProperties) and function parameters (Arguments), which specifies the structure of field types and parameters in detail. And the symbols in the template (such as <0> ) will also be replaced with the corresponding object in the vulnerability call context.

[0056] (5) Execution feedback-based directed fuzz testing. Using an execution feedback mechanism, we analyze the execution path of each seed to guide seed selection and mutation, thereby generating exploit inputs that can successfully exploit the vulnerability method. By introducing a fitness scoring mechanism, we prioritize the execution and mutation of seeds that are most likely to be successfully exploited, thereby improving the efficiency and success rate of fuzz testing.

[0057] Through these five steps, the method of the present invention can efficiently generate exploit inputs for project dependency library vulnerabilities, thereby helping developers identify and repair dependency library vulnerabilities in the project, effectively reducing the risks and potential losses caused by the vulnerabilities.

[0058] The test case set of this invention covers open source software vulnerabilities in NVD between 2015 and 2023, including 32 Java vulnerabilities, involving 45 vulnerable functions, distributed in 21 libraries, and covering 17 different vulnerability categories. Furthermore, the experiment constructed 84 combinations of vulnerability-dependent libraries and development projects, containing 182 exploitable call chains, with an average of 2.36 methods per call chain, and the longest call chain containing 8 methods. The experiment compared three project-dependent library vulnerability exploitation tools. Table 1 shows the test case results of different tools, where Magneto is the name of the tool implemented by this invention.

[0059] Table 1 Test results of different tools on test cases

[0060]

[0061] EPN (Exploited Pairs Number) indicates the number of vulnerability exploitation pairs successfully generated by the tool in the vulnerability dependency library-exploitation project combination; ECN (Exploited Call Chains Number) indicates the number of exploitable call chains successfully generated by the tool; MEL (Maximum Exploited Length) indicates the maximum length of the vulnerability exploit call chains successfully generated by the tool; AEL (Average Exploited Length) indicates the average length of the vulnerability exploit call chains successfully generated by the tool.

[0062] In a test case evaluation, our method significantly outperformed the current state-of-the-art methods in terms of effectiveness and efficiency in generating exploits. Across 79 project-vulnerability pairs, our method successfully generated 135 exploitable call chain exploits, achieving a 75.6% improvement in success rate and a 154.7% improvement in exploitable call chains over the best existing method.

[0063] References

[0064] [1].Kaifeng Huang,Bihuan Chen,Linghao Pan,Shuai Wu,and XinPeng.2021.REPFINDER:Finding replacements for missing APIs in libraryupdate.In Proceedings of the 2021IEEE / ACM 36th International Conference onAutomated Software Engineering.266–278.

[0065] [2].Dhanushka Jayasuriya,Valerio Terragni,Jens Dietrich,Samuel Ou,andKelly Blincoe.2023.Understanding Breaking Changes in the Wild.In Proceedingsof the 32nd ACM SIGSOFT International Symposium on Software Testing andAnalysis.1433–1444.

[0066] [3].Wenke Li,Feng Wu,Cai Fu,and Fan Zhou.2023.A Large-Scale EmpiricalStudy on Semantic Versioning in Golang Ecosystem.In Proceedings of the 2023IEEE / ACM 38th International Conference on Automated SoftwareEngineering.1604–1614.

[0067] [4].César Soto-Valero,Deepika Tiwari,Tim Toady,and BenoitBaudry.2023.Automatic specialization of third-party java dependencies.IEEETransactions on Software Engineering 49,11(2023),5027–5045.

[0068] [5].Ying Wang,Bihuan Chen,Kaifeng Huang,Bowen Shi,Congying Xu,XinPeng,Yijian Wu,and Yang Liu.2020.An empirical study of usages,updates andrisks of third-party libraries in java projects.In Proceedings of the 2020IEEE International Conference on Software Maintenance and Evolution.35–45.

[0069] [6].Sonatype.2023.9th Annual State of the Software SupplyChain.Retrieved May 25,2024,from https: / / www.sonatype.com / state-of-the-software-supply-chain / introduction.

[0070] [7].Google.2024.Understanding the Impact of Apache Log4jVulnerability.Retrieved May 26,2024,from https: / / security.googleblog.com / 2021 / 12 / understanding-impact-of-apache-log4j.html.

[0071] [8].Samim Mirhosseini and Chris Parnin.2017.Can automated pullrequests encourage software developers to upgrade out-of-date dependencies?.In Proceedings of the 32nd IEEE / ACM international conference on AutomatedSoftware Engineering.84–94.

[0072] [9].Jinchang Hu,Lyuye Zhang,Chengwei Liu,Sen Yang,Song Huang,and YangLiu.2024.Empirical Analysis of Vulnerabilities Life Cycle in GolangEcosystem.In Proceedings of the IEEE / ACM 46th International Conference onSoftware Engineering.1–13.

[0073]

[10] .Chengwei Liu,Sen Chen,Lingling Fan,Bihuan Chen,Yang Liu,and XinPeng.2022.Demystifying the vulnerability propagation and its evolution viadependency trees in the npm ecosystem.In Proceedings of the 44thInternational Conference on Software Engineering.672–684.

[0074]

[11] .Xian Zhan,Lingling Fan,Sen Chen,Feng We,Tianming Liu,Xiapu Luo,and Yang Liu.2021.Atvhunter:Reliable version detection of third-partylibraries for vulnerability identification in android applications.InProceedings of the 2021 IEEE / ACM 43rd International Conference on SoftwareEngineering.1695–1707.

[0075]

[12] .Kaifeng Huang,Bihuan Chen,Congying Xu,Ying Wang,Bowen Shi,XinPeng,Yijian Wu,and Yang Liu.2022.Characterizing usages,updates and risks ofthird-party libraries in Java projects.Empirical Software Engineering 27,4(2022),90.

[0076]

[13] .Benjamin Barslev Nielsen,Martin Toldam Torp,and Anders 2021.Modular call graph construction for security scanning of Node.jsapplications.In Proceedings of the 30th ACM SIGSOFT International Symposiumon Software Testing and Analysis.29–41.

[0077]

[14] .Serena Elisa Ponta,Henrik Plate,and Antonino Sabetta.2018.BeyondMetadata:Code-Centric and Usage-Based Analysis of Known Vulnerabilities inOpen-Source Software.In Proceedings of the IEEE International Conference onSoftware Maintenance and Evolution.449–460.

[0078]

[15] .Yulun Wu,Zeliang Yu,Ming Wen,Qiang Li,Deqing Zou,and HaiJin.2023.Understanding the threats of upstream vulnerabilities to downstreamprojects in the maven ecosystem.In Proceedings of the 2023 IEEE / ACM 45thInternational Conference on Software Engineering.1046–1058.

[0079]

[16] .Meiqiu Xu,Ying Wang,Shing-Chi Cheung,Hai Yu,and ZhiliangZhu.2022.Insight:Exploring Cross-Ecosystem Vulnerability Impacts.InProceedings of the 37th IEEE / ACM International Conference on AutomatedSoftware Engineering.1–13.

[0080]

[17] .Lyuye Zhang,Chengwei Liu,Sen Chen,Zhengzi Xu,Lingling Fan,LidaZhao,Yiran Zhang,and Yang Liu.2023.Mitigating persistence of open-sourcevulnerabilities in Maven ecosystem.In Proceedings of the 2023 IEEE / ACM 38thInternational Conference on Automated Software Engineering.191–203.

[0081]

[18] .Zirui Chen,Xing Hu,Xin Xia,Yi Gao,Tongtong Xu,David Lo,andXiaohu Yang.2024.Exploiting Library Vulnerability via Migration BasedAutomating Test Generation.In Proceedings of the IEEE / ACM 46th InternationalConference on Software Engineering.1–12.

[0082]

[19] .Emanuele Iannone,Dario Di Nucci,Antonino Sabetta,and Andrea DeLucia.2021.Toward automated exploit generation for known vulnerabilities inopen-source libraries.In Proceedings of 2021 IEEE / ACM 29th InternationalConference on Program Comprehension.396–400.

[0083]

[20] .Hong Jin Kang,Truong Giang Nguyen,Bach Le,Corina S andDavid Lo.2022.Test mimicry to assess the exploitability of libraryvulnerabilities.In Proceedings of the 31st ACM SIGSOFT InternationalSymposium on Software Testing and Analysis.276–288.

[0084]

[21] .Gordon Fraser and Andrea Arcuri.2011.Evosuite:automatic testsuite generation for object-oriented software.In Proceedings of the 19th ACMSIGSOFT symposium and the 13th European conference on Foundations of softwareengineering.416–419.

[0085]

[22] .Yulun Wu,Zeliang Yu,Ming Wen,Qiang Li,Deqing Zou,and HaiJin.2023.Understanding the threats of upstream vulnerabilities to downstreamprojects in the maven ecosystem.In Proceedings of the 2023 IEEE / ACM 45thInternational Conference on Software Engineering.1046–1058.

[0086]

[23] .Github.2024.Soot-A Java optimization framework.Retrieved May 29,2024,from https: / / github.com / soot-oss / soot.

[0087]

[24] .ASM.2024.ASM.Retrieved May 30,2024,from https: / / asm.ow2.io / .

[0088]

[25] .Github.2024.jd-core.Retrieved May 30,2024,from https: / / github.com / java-decompiler / jd-core.

[0089]

[26] .JavaParser.2024.JavaParser Home.Retrieved May 30,2024,fromhttps: / / javaparser.org / .

[0090]

[27] .Github.2024.Java Code Coverage Library.Retrieved May 28,2024,from https: / / github.com / jacoco / jacoco。

Claims

1. A step-by-step method for exploiting project dependency library vulnerabilities based on LLM enhancement, characterized in that: The specific steps are: (1) Perform lightweight dependency tree analysis and call graph construction on the project to identify all reachable call chains leading to vulnerable methods in the project; (2) Refine the fuzz testing process of the entire call chain into targeted fuzz testing for each method call; (3) Using context-sensitive static analysis, combined with hint engineering, and using LLM to deeply understand the semantics of the current test function, to assist in generating seed templates; (4) using the seed template derived from the LLM to instantiate the seed parameters and receiving objects, thereby generating the initial seed; (5) Analyze the execution path of the seed through the execution feedback mechanism, guide the selection and mutation of the seed, and finally generate effective exploit input for the dependency library vulnerability.

2. The method for exploiting a vulnerability in a project dependency library according to claim 1, wherein: In step (1), lightweight dependency tree analysis and call graph construction are performed on the project to identify all reachable call chains leading to the vulnerable methods in the project. The specific process is as follows: (1) Generate the dependency tree of the client project through the Maven command "mvn dependency:tree" and filter the dependencies to filter out the dependencies used only for testing; (2) Using Depth-First Search (DFS) to traverse the dependency tree, record the path from the project root node to each vulnerable dependency, and thus build a "vulnerability-aware dependency tree"; (3) Download all the JAR files corresponding to the dependencies in the vulnerability-aware dependency tree and use the Soot tool to generate a call relationship graph between the project and its dependencies; (4) Perform DFS on the call graph, starting from each public function in the project, and identify the reachable call chain leading to the vulnerable method.

3. The method for exploiting a vulnerability in a project dependency library according to claim 2, wherein: Step (2) of the present invention refines the fuzz testing process of the entire call chain into a targeted fuzz test for each method call; specifically, the LLM-enhanced targeted fuzz test is performed step by step. In the targeted fuzz test process, the utilization context of each call step is first extracted; a complete reachable call chain is denoted as F i →F i-1 →…→F0, where F0 is the vulnerable method in the project dependency library. For each step of the calling process <F i ,F i-1 >, extract the called function F from the known vulnerability exploit test cases in the vulnerability database or the exploit input generated in the previous test step i-1 The use context of the call chain F i-1 →…→F0 to exploit the program state required by vulnerability method F0; In order to extract the vulnerability context, ASM is used to insert code at the beginning of the function body to execute F i-1 Record the parameters passed and the receiving object; if F i-1 If it is a constructor or static function, the inserted code only records the passed parameters; otherwise, it records both the parameters and the receiving object; finally, execute F i-1 The exploit input is collected, and the parameters and received objects passed during its execution are collected, thereby successfully extracting the context of vulnerability exploitation.

4. The method for exploiting a vulnerability in a project dependency library according to claim 3, wherein: Step (3) uses context-sensitive static analysis, combined with hint engineering, and LLM to deeply understand the semantics of the current test function to assist in generating a seed template; the details are as follows: Call at each step <F i ,F i-1 >, use LLM to infer how to set up the call F i The receiving object and the one passed to F i parameters to ensure that the F i Call F i-1 ; In theory, these receiving objects and parameters can be expressed as expressions on the data flow, called seed templates Since data flow analysis is used in the derivation There are limitations when using fuzzy test, so LLM is used for approximate deduction. This method designs a prompt to generate fuzz test seed templates. The specific process is as follows: By extracting key codes, LLM is prevented from being disturbed by irrelevant codes. First, the JAR file is decompiled using JD-Core[25], and the code that is used to call F is extracted using JavaParser[26]. i-1 The relevant code section retains the last call to F i-1 Based on this, we use breadth-first search (BFS) to find related functions and fields in the code and generate a key code set. To ensure the relevance of the code and avoid exceeding the token limit of LLM, only the functions related to F are retained during the search process. i Classes in the same dependency, and the search depth limit is set to 2; Finally, the key code is pruned, only the functions and fields found during the search are retained, and they are compared with the pruned F i Code splicing to form a complete key code set; then, use LLM to generate seed templates 5. The method for exploiting a vulnerability in a project dependency library according to claim 4, wherein: In step (iv), the seed template derived from the LLM is used to instantiate the seed parameters and the receiving object, thereby generating an initial seed; specifically, the seed template is represented in JSON format, and the initial seed is generated by parsing the symbols in the template and assigning values; To address the shortcomings of LLM in processing received objects, static analysis is used to supplement these inference results. Specifically, if the two functions belong to the same class, all fields in the received object are traversed and non-null fields are assigned to corresponding values. If the two functions do not belong to the same class, context-sensitive reverse taint analysis is used to determine the source of the received object and correctly assign it to the corresponding fields.

6. The method for exploiting a vulnerability in a project dependency library according to claim 5, wherein: In step (5), the execution path of the seed is analyzed through the execution feedback mechanism to guide the selection and mutation of the seed, and ultimately generate effective exploit input for the dependency library vulnerability. Specifically, the synthesized seed is used as the initial input to perform directed fuzz testing, with the goal of generating an exploit for the project dependency library vulnerability. In this process, the variables in the seed are divided into three categories: (1) Vulnerability exploitation-related variables: These variables have data flow relationships with the receiving objects and parameters during execution and may affect vulnerability exploitation; (2) Control flow related variables: These variables control the execution path and branch decisions of the program, affecting the reachability of the target function; (3) Other variables: These variables are not related to branch conditions and vulnerability exploitation; The specific process is: Utilize context-sensitive reverse taint analysis to mark and track vulnerability exploitation-related variables and control flow-related variables, and classify them into corresponding categories; To effectively select and mutate seeds, we use JaCoCo to perform coverage analysis on the execution paths of the seeds. We calculate the fitness score based on the distance between the number of lines of code covered during the seed execution and the distance to the target function. Seeds with smaller fitness scores are closer to the vulnerable method during execution and are therefore selected for execution and mutation first. JaCoCo uses different mutation strategies for different categories of variables: control flow related variables are given a higher mutation probability to explore more execution paths and increase the chance of reaching the target function; vulnerability exploitation related variables are given a lower mutation probability; Other variables are not mutated because they are not related to vulnerability exploitation.

7. The method for exploiting a vulnerability in a project dependency library according to claim 6, wherein: During the seed mutation process, the data structure type of the variable is also considered, specifically three types: (1) Basic types: represent basic data types, including integer, floating-point, and character types. They contain values ​​directly without referencing external objects. (2) Reference type: object type, including class instance or interface; (3) Array type: a special reference type that represents a collection of elements of the same type. Each element in the array can be accessed through an index; The seed mutation operation is specifically handled according to the data structure type of the variable: for basic types, random values ​​are directly generated; for reference types, subclass objects are instantiated or random values ​​are assigned to the fields of their instances; for array types, a new array is created or an element in an existing array is mutated.

Images