LLM enhancement-based step-by-step utilization method for project dependent library vulnerabilities

Abstract

The invention belongs to the technical field of software engineering, and particularly relates to a project dependency library vulnerability step-by-step utilization method based on LLM enhancement. The method comprises the following steps: carrying out lightweight dependency tree and call graph reachability analysis on a project, and identifying all reachability call chains from the project to a vulnerability method; decomposing the fuzz test on the whole call chain into a directional fuzz test on each step of method call in the call chain; in combination with static analysis and prompt engineering technologies, seed generation is assisted by semantic understanding of LLM on a current test function and utilization information generated by a previous test. And performing directional fuzzy testing by utilizing the generated seeds, analyzing execution paths of the seeds through an execution feedback mechanism, guiding selection and variation of the seeds, and finally generating effective input capable of successfully utilizing the project dependent library vulnerabilities. According to the method, developers can be helped to quickly position and timely repair vulnerabilities, so that risks and potential loss of projects caused by dependency on the vulnerabilities are reduced.

Description

Technical Field

[0001] The 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 steps. 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 download volume has 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 dependency chains, thereby exposing these projects to security threats brought by 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]. In addition, 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 extracts the dependency tree of the project through software component analysis methods and checks 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 build a call graph for 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 perform exploitability analysis on 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. 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 vulnerable 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, which is easy to operate and can efficiently generate and effectively utilize.

[0006] The method for exploiting a project dependency library vulnerability based on LLM enhancement provided by the present invention comprises:

[0007] First, we perform lightweight analysis of the project's dependency tree and build a call graph to identify all reachable call chains leading to the 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 adopt context-sensitive static analysis, combined with hint engineering, and use LLM to deeply understand the semantics of the current test function 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 seeds is analyzed through the execution feedback mechanism to guide the selection and mutation of seeds, and finally generate effective exploit input for dependent library vulnerabilities.

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

[0013] (I) Perform lightweight analysis of the project's dependency tree and build 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 through the Maven command "mvn dependency:tree", and the dependencies are filtered to filter out the dependencies that are only used for testing. Then, the dependency tree is traversed using depth-first search (DFS) to record 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 call relationship graph between the project and its dependencies is generated with the help of the Soot

[23] tool. 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] (II) 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 extract 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 of 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 the vulnerability exploit.

[0017] (III) Using context-sensitive static analysis, combined with hint engineering, and using LLM to deeply understand the semantics of the current test function, assist in generating seed templates; the specific instructions are as follows:

[0018] At each step call <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 stream, called seed templates Since data flow analysis is used in the derivation There are limitations when using fuzzy testing, so LLM is used for approximate deduction. This method designs a prompt to generate a fuzzy test seed template; 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 critical 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 set of key codes. Then, use LLM to generate seed templates

[0020] (iv) using the seed template derived from LLM to instantiate the seed parameters and receiving objects, thereby generating an initial seed; specifically, the seed template is represented in JSON format, and the initial seed needs to be generated by parsing the symbols in the template and assigning values.

[0021] Since LLM may have deficiencies in processing receiving objects, static analysis is needed to supplement these inference results. Specifically, if the two functions belong to the same class, it is necessary to traverse all fields in the receiving object and assign non-empty fields to corresponding values. If the two functions do not belong to the same class, context-sensitive reverse taint analysis is needed to determine the source of the receiving object and correctly assign it to the corresponding fields.

[0022] (V) 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 seeds as the initial input to conduct directed fuzz testing, with the goal of generating exploits for project dependency library vulnerabilities. In this process, we divide the variables in the seeds 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] Using context-sensitive reverse taint analysis, we 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 of the number of lines of code covered during the seed execution process and the distance to the target function. The seeds with smaller fitness scores are closer to the vulnerable method during the execution process, and they are selected for execution and mutation first.

[0030] JaCoCo uses different mutation strategies for different categories of variables: control flow related variables are given 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, including 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 the seed is mutated, specific processing is performed 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.

[0036] It should be noted that the data structure types of the above variables (basic type, reference type, array type) are not mutually exclusive with the three categories of variables (exploit-related variables, control flow-related variables, and other variables). For example, control flow-related variables can be basic types, arrays, or reference types; similarly, exploit-related variables can also belong to one of these data structures. Therefore, the seed mutation process needs to comprehensively consider the category of the variable and its specific data structure.

[0037] The basic process schematic diagram of the present invention is as follows Figure 1 As shown. The present invention identifies the reachable call chain from the project to the vulnerable method through vulnerability reachability analysis; then, using step-by-step directed fuzz testing, each function in the call chain is gradually generated for vulnerability exploitation input; through prompt engineering, combined with static analysis, the input state of the calling function is inferred using LLM to generate the initial fuzz test seed; finally, the generated seed is optimized through the execution feedback mechanism to generate the exploit input that can successfully exploit the vulnerability. The method of the present invention can help developers automatically detect and generate exploit inputs 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 method is proposed, which decomposes the directional fuzz testing of the entire call chain into independent fuzz testing for each step, and gradually solves the vulnerability exploitation problem in the complex call chain. This step-by-step method can effectively reduce the difficulty of generating effective vulnerability exploitation tools in multi-step call scenarios; the code semantic understanding ability of LLM is used to generate initial test seeds, thereby improving the success rate of fuzz testing. This LLM-based method enhances the processing ability of complex code logic and generates more accurate test inputs by introducing semantic understanding; an execution feedback mechanism is used to combine static and dynamic analysis to further improve the efficiency of the fuzz testing process, especially when LLM inference is inaccurate, the seeds and parameters are corrected through fuzz testing feedback, thereby significantly improving the success rate of vulnerability exploit generation.

[0040] The present 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 repair 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 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 dependency library.

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

[0046] Figure 6 An example of the results of generating a fuzz test seed template based on LLM enhancement. DETAILED DESCRIPTION

[0047] The following describes a specific implementation of the present invention for the automatic generation of vulnerability exploits in a project dependency library, and the process is as follows:

[0048] (1) Vulnerability accessibility analysis. Before performing 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 disclosed 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 dependency 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 The test case for exploiting the vulnerability CVE-2019-10086 in the vulnerability database is shown. The vulnerability is triggered when a bean object and a string "class" are input to the PropertyUtils.getProperty() method respectively. Since the bean object does not contain a field named "class", an exception is expected to be thrown. However, during the actual execution, the method mistakenly returns the Class bytecode object of the bean object, thereby successfully exploiting the vulnerability.

[0049] After building the vulnerability database, perform lightweight dependency tree analysis and call graph analysis on the project to build the project's dependency tree and its full method call graph. By traversing the call graph and combining the knowledge in the vulnerability database, identify all reachable call chains from the project to the vulnerable methods in the dependent library. Through this step, you can get several reachable call chains between the project and the vulnerable methods in the dependent library. 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 the reachable call chain is identified, 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 4The step-by-step exploitation process of the CVE-2019-10086 vulnerability is shown, in which the Form.validate function calls Field.validate, Field.getIndexedPropertySize, and finally calls the PropertyUtils.getProperty function. In the process of Field.getIndexedPropertySize calling PropertyUtils.getProperty, to successfully exploit the vulnerability, the second parameter of PropertyUtils.getProperty (that is, the return value of getIndexedListProperty) must be "class". This means that in the instance object of the getIndexedPropertySize method, the value of the indexedListProperty field must be set to "class". When the instance object executes getIndexedPropertySize, passing an Object instance can trigger the vulnerability. In the process of Field.validate calling Field.getIndexedPropertySize, the parameter bean passed to getIndexedPropertySize comes from the params object in line 43 of the code. params is the first parameter of the validate method, which is a Map object used to retrieve the value of the key "java.lang.Object". Therefore, in order to exploit the vulnerability through the validate method, params must be set to {"java.lang.Object":Object instance}, and when validate executes to call the getIndexedPropertySize statement, the program state at this time should be kept consistent with the program state when getIndexedPropertySize exploits the vulnerability.

[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 in the figure, the bean object and "class" constitute the exploit context of the vulnerable method. This context can be obtained by instrumenting and executing the vulnerability test case. The exploit context of other methods in the call chain is obtained through fuzz testing. The exploit context generated at each step can help synthesize the fuzz test seed in 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 prompt engineering to ensure that the called function can be executed correctly. LLM analyzes the code of the calling function for semantic understanding, 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 The prompt used in the LLM seed template inference process is shown. It includes key code snippets [%CODE%], caller function code [%CALLER%], called function code [%CALLEE%], and parameters required for calling [%ARGS%] and receiving objects [%RO%]. Its content mainly describes the function calling process and parameter passing method. The receiver object and input parameters of the target function are explained in a symbolic way, aiming to ensure that the called target function can be executed correctly by setting the field attributes and function parameters of the receiver object. Through this prompt, the data flow and control flow relationship in the code can be accurately captured for 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 mappings 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 calling context.

[0056] (5) Directed fuzz testing with execution feedback. Using the execution feedback mechanism, the execution path of each seed is analyzed to guide the selection and mutation of the seed, thereby generating the exploit input that can successfully exploit the vulnerability method. By introducing a fitness scoring mechanism, the seeds that are most likely to be successfully exploited are executed and mutated first, 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, and effectively reducing the risks and potential losses caused by the vulnerabilities.

[0058] The test case set of the present invention covers open source software vulnerabilities in NVD from 2015 to 2023, including 32 Java vulnerabilities, involving 45 vulnerable functions, distributed in 21 libraries, and covering 17 different types of vulnerabilities. In addition, the experiment constructed 84 sets of combinations of vulnerability dependency libraries and development projects, including 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 dependency library vulnerability exploitation tools. Table 1 shows the test results of the use cases of different tools, where Magneto is the name of the tool implemented by the present invention.

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

[0060]

[0061] EPN (Exploited Pairs Number) indicates the number of exploit pairs that the tool successfully generates in the vulnerability dependency library-development 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 the test case evaluation, the effectiveness and efficiency of the invention in generating vulnerability exploits far exceeded the current state-of-the-art methods. In 79 pairs of project and vulnerability combinations, the invention successfully generated 135 exploitable call chain vulnerability tools, which increased the success rate by 75.6% over the best existing method and achieved a 154.7% improvement in the exploitable call chain.

[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 analysis of the project's dependency tree and build a call graph to identify all reachable call chains leading to the vulnerable methods in the project; (2) Refine the fuzz testing process of the entire call chain into targeted fuzz testing for each method call; (iii) Using context-sensitive static analysis, combined with hint engineering, and using LLM to deeply understand the semantics of the current test function, assist in generating seed templates; (iv) using the seed template derived from LLM to instantiate the seed parameters and receiving objects, thereby generating an initial seed; (V) Analyze the execution path of the seeds through the execution feedback mechanism, guide the selection and mutation of the seeds, 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, characterized in that: Step (1) performs lightweight analysis of the dependency tree and construction of the call graph of 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 that are only used for testing; (2) Use depth-first search (DFS) to traverse the dependency tree and record the path from the project root node to each vulnerable dependency, thereby building a "vulnerability-aware dependency tree"; (3) Download the JAR files corresponding to all 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, characterized in that: Step (ii) refines the fuzz testing process of the entire call chain into a directional fuzz test for each method call; specifically, the LLM-enhanced directional fuzz test is performed step by step. In the directional 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 utilization context of 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 passed parameters and receiving objects; 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 the vulnerability exploit.

4. The method for exploiting a vulnerability in a project dependency library according to claim 3, characterized in that: Step (iii) 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 stream, 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: The key code is extracted to prevent LLM from being disturbed by irrelevant code. First, the JAR file is decompiled using JD-Core[25], and the code that calls 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, we only keep the code related to F in the search process. i Classes in the same dependency, with the search depth limit set to 2; finally, the critical 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 set of key codes; then, use LLM to generate seed templates 5. The method for exploiting a vulnerability in a project dependency library according to claim 4, characterized in that: In step (iv), the seed template derived from LLM is used to instantiate the parameters and receiving objects of the seed, 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 make up for the shortcomings of LLM in processing receiving objects, static analysis is used to supplement these inference results. Specifically, if the two functions belong to the same class, all fields in the receiving object are traversed and the non-empty 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 receiving object and correctly assign it to the corresponding field.

6. The method for exploiting a vulnerability in a project dependency library according to claim 5, characterized in that: In step (V), the execution path of the seed is analyzed by executing the feedback mechanism to guide the selection and mutation of the seed, and finally generate an effective exploit input for the dependency library vulnerability. Specifically, the synthesized seed is used as the initial input to perform a directed fuzz test, the goal of which is to generate 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: Using context-sensitive reverse taint analysis, we mark and track vulnerability exploitation-related variables and control flow-related variables and classify them into corresponding categories. In order to effectively select and mutate seeds, JaCoCo is used to perform coverage analysis on the execution path of the seeds. The fitness score is calculated based on the distance of the number of lines of code covered during the seed execution process and the distance of the target function. The seeds with smaller fitness scores are closer to the vulnerability method during the execution process, and they are 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 exploit related variables are given a lower mutation probability; Other variables are not mutated because they are not related to the vulnerability exploitation.

7. The method for exploiting a vulnerability in a project dependency library according to claim 6, characterized in that: In the process of seed mutation, 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 processed 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