Method and system for judging availability of open source component vulnerabilities based on dynamic taint analysis and related equipment
By combining dynamic taint analysis of the system runtime environment in open-source components, the propagation path of external inputs is tracked in real time, and the call characteristics of known vulnerable functions are combined, which solves the problem of inaccurate exploitability determination of open-source component vulnerabilities in existing technologies, and realizes high-precision vulnerability detection and automated determination.
Patent Information
- Application Number
- CN202511766359.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-27
- Publication Date
- 2026-02-24
AI Technical Summary
Existing dynamic taint analysis techniques cannot accurately determine the exploitability of vulnerabilities in open-source components, resulting in a high false positive rate and making it difficult to provide effective support for security decisions.
By combining dynamic taint analysis of the system's operating environment, and by tracking the propagation path of external input in the program in real time, we can identify whether vulnerable functions are triggered by externally controlled input. We use instrumentation techniques to dynamically monitor the application system, track the propagation path of tainted variables, and make judgments based on the calling characteristics of known vulnerable functions.
It enables accurate identification of vulnerabilities in open-source components, significantly improving the accuracy and practicality of vulnerability detection, and can automatically determine the exploitability of vulnerabilities without affecting the system's business logic.
Smart Images

Figure CN121561925A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software security technology, specifically to a method for determining the exploitability of vulnerabilities in open-source components based on Dynamic Taint Analysis. This method belongs to the field of software supply chain security detection and vulnerability exploitation analysis, and is applicable to the research and implementation of software security testing, open-source component security management, and software supply chain security protection systems. Background Technology
[0002] In recent years, scholars at home and abroad have conducted a great deal of research on open source component vulnerability identification, vulnerability impact analysis, and taint propagation path construction, forming a series of representative technology and tool systems.
[0003] In open-source component vulnerability detection, mainstream methods can be divided into two categories: Software Composition Analysis (SCA) and code comparison-based vulnerability localization. SCA can expose third-party components in a software project and identify publicly disclosed vulnerabilities introduced into the project by these components, affecting the project itself. This type of method has the advantages of low implementation cost and broad coverage, but it cannot determine whether a vulnerability is truly accessible and exploitable in the current system, resulting in a high false positive rate. To address this, researchers have proposed introducing context-sensitive information, such as constructing function call graphs and dependency graphs, to enhance the accuracy of vulnerability localization. Tools like VulDeePecker and VulDeeLocator use machine learning and graph neural networks to semantically model code, improving vulnerability identification accuracy to some extent. However, existing technologies mostly remain at the level of vulnerability existence detection, struggling to distinguish whether a vulnerability is truly exploitable, leading to a high false positive rate and failing to provide effective support for security decisions.
[0004] Dynamic taint analysis, as a technical approach that more closely reflects real-world execution behavior, has received increasing attention in recent years. This technology is based on a dynamic analysis method of information flow; that is, during program execution, it tracks tainted data flowing into the program, records the propagation path of the data flow within the program, detects tainted data, and records the dependencies between taints. Early research, such as the TaintCheck system proposed by Newsome and Song, achieved the detection of memory vulnerabilities such as buffer overflows by marking and tracing the propagation of taints in input data. Subsequently, the BitBlaze platform proposed by Cheng et al., combining symbolic execution and taint analysis, demonstrated strong capabilities in vulnerability detection and malware analysis. In recent years, research has gradually moved towards efficiency and scalability; for example, TaintDroid ported dynamic taint analysis to mobile terminal platforms for data flow tracking in Android applications, effectively solving privacy and security issues in the mobile ecosystem.
[0005] However, existing dynamic taint analysis techniques can only record the propagation path of tainted data within the program when implementing data flow tracing. Due to the special application and operation characteristics of open source components, existing dynamic taint analysis techniques cannot achieve semantic interpretation capabilities and exploitability determination for vulnerability scenarios of open source components. Summary of the Invention
[0006] To address the issue of inaccurate exploitability determination in existing open-source component vulnerability detection, the present invention aims to provide a dynamic taint analysis scheme that integrates with the system's operating environment. By tracking the propagation path of external input in the program in real time, it identifies whether a vulnerable function is triggered by controllable external input, thereby accurately determining whether a vulnerability can be exploited and improving the accuracy and practicality of vulnerability detection.
[0007] To achieve the above objectives, the present invention provides a method for determining the exploitability of vulnerabilities in open-source components based on dynamic taint analysis. When the system receives an external request or input event, the method automatically assigns a taint identifier to the taint source and marks it as a potential controllable source. Next, during system operation, instrumentation technology is used to dynamically monitor the application system and track the propagation path of marked tainted variables during function calls; Finally, based on the calling characteristics of known vulnerable functions, it is determined whether tainted variables are passed to the vulnerability point, and vulnerability exploitability analysis results are generated.
[0008] Furthermore, when automatically assigning taint identifiers to taint sources, the method instrumentes the request entry functions involved in the system operation, dynamically extracts the received parameter content, and marks them with unique taint IDs.
[0009] Furthermore, when tracking tainted variables, the method dynamically injects monitoring code into methods in all user code and open-source component code during system runtime through instrumentation. This code is used to execute taint tracking logic and records the input parameter values and return values of the instrumented methods when they are called. It also records the method name, class name, and package name that receive these parameters, and records them according to the parameter passing order, thereby constructing a taint propagation path chain.
[0010] Furthermore, when tracking tainted variables, the method employs a stack-based path record structure to perform refined modeling of the transmission process of tainted variables.
[0011] Furthermore, during taint analysis, the method determines whether a vulnerability is exploitable by judging whether the tainted variable actually flows into the vulnerability function and by combining parameter control capabilities.
[0012] To achieve the above objectives, this invention provides an open-source component vulnerability exploitability assessment system based on dynamic taint analysis, the system comprising: A taint marking module is configured to recognize when the system receives an external request or input event, and to automatically assign a taint identifier to the taint source and mark it as a potential controllable source. The taint tracking module is configured to dynamically monitor the application system during system operation using instrumentation technology, and track the propagation path of tainted variables marked by the taint marking module during function calls. The taint analysis module is configured to determine whether a taint variable has been passed to a vulnerability point based on the propagation path of the taint variable tracked by the taint tracking module and the call characteristics of the known vulnerable function, and generate vulnerability exploitability analysis results.
[0013] Furthermore, when automatically assigning taint identifiers to taint sources, the taint marking module instrumentes the request entry functions involved in the system operation, dynamically extracts the received parameter content, and marks them with unique taint IDs.
[0014] Furthermore, the taint tracking module is configured to dynamically inject monitoring code into methods in all user code and open-source component code during system operation via instrumentation. This code is used to execute taint tracking logic and record the input parameter values and return values of the instrumented methods when they are called. It also records the method name, class name, and package name that receive these parameters, and records them in the order of parameter passing, thereby constructing a taint propagation path chain.
[0015] Furthermore, the taint tracking module is configured to use a stack-based path recording structure to perform refined modeling of the taint variable transmission process.
[0016] Furthermore, the taint analysis module is configured to determine whether a vulnerability is exploitable by judging whether a tainted variable actually flows into a vulnerable function and by combining this with parameter control capabilities.
[0017] To achieve the above objectives, the present invention also provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the steps of the above-described open-source component vulnerability exploitability determination method.
[0018] To achieve the above objectives, the present invention also provides a processor for running a program, wherein the program executes the steps of the above-described open-source component vulnerability exploitability determination method during runtime.
[0019] To achieve the above objectives, the present invention also provides a terminal device, the device including a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program code is loaded and executed by the processor to implement the steps of the above-described open-source component vulnerability exploitability determination method.
[0020] To achieve the above objectives, the present invention also provides a computer program product that, when executed on a data processing device, is adapted to perform the steps of the above-described open-source component vulnerability exploitability assessment method.
[0021] The open-source component vulnerability exploitability assessment scheme based on dynamic taint analysis provided by this invention instrumentes key functions and component interfaces during program runtime to achieve real-time tracking of the propagation path of external input data. It can automatically determine vulnerability exploitability without affecting the system's business logic, significantly improving the accuracy and practicality of vulnerability detection.
[0022] The open-source component vulnerability exploitability assessment scheme based on dynamic taint analysis provided by this invention accurately tracks data flow and control flow at runtime, dynamically marks the propagation path of potentially dangerous data, and combines contextual semantic information to determine whether a vulnerability can actually be triggered and exploited. This method can reflect the attack conditions and exploitation chain of vulnerabilities in real-world scenarios, achieving a technological leap from "detecting vulnerabilities" to "assessing exploitability," and can significantly improve the accuracy and practicality of vulnerability risk assessment.
[0023] The open-source component vulnerability exploitability assessment scheme based on dynamic taint analysis provided by this invention can construct a cross-language implementation mechanism and event-triggered analysis framework in practical applications and implementations. This framework is not limited to a specific language environment and can be implemented in any programming language that supports instrumentation mechanisms (including but not limited to Java, Python, Go, C / C++, PHP, etc.). Furthermore, for different language environments, runtime tracing can be performed using methods such as bytecode instrumentation, AST hooking, LLVM IR instrumentation, or eBPF probes. The system dynamically initiates the taint analysis process only when external input events are present to reduce performance overhead and can combine static context information for result verification, thus forming a closed-loop analysis mechanism of "static prediction - dynamic verification," providing a unified technical implementation path for open-source component vulnerability exploitability assessment and software supply chain security testing. Attached Figure Description
[0024] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.
[0025] Figure 1 This is a flowchart of the process for determining the exploitability of open-source component vulnerabilities using dynamic taint analysis in Example 1 of the present invention.
[0026] Figure 2 This is a flowchart of the exploitability determination of open-source component vulnerabilities for a Web application instance in Example 2 of the present invention. Detailed Implementation
[0027] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to specific illustrations.
[0028] For vulnerabilities in open-source components disclosed in the CVE vulnerability database, they can usually be located to specific functions in a file within a specific project. If this function is called in an actual software system and its critical parameters can be controlled by external input, the vulnerability may be exploited by remote attackers, thus posing a security threat. Conversely, if the parameter source is a fixed value or uncontrollable input, although the vulnerability exists in the component, its actual risk is low.
[0029] Based on this, the present invention proposes an open-source component vulnerability exploitability judgment method based on dynamic taint analysis. This method marks external request parameters with taints during system runtime and dynamically tracks their propagation path within the system. When the tainted variable eventually flows into the vulnerable function or other sensitive operation function, it determines that the vulnerability is exploitable in the current system.
[0030] Furthermore, to adapt dynamic taint analysis technology to the needs of exploitability analysis of open-source component vulnerabilities, this invention provides customized enhancements in areas such as taint entry point identification, component boundary identification, cross-library function propagation semantic modeling, and vulnerability reach condition determination. First, traditional taint analysis typically uses user input as the sole taint source. However, in open-source component scenarios, parameter passing between components, framework auto-assembly, and reflection calls can also create new taint entry points. This solution supplements controllable parameter identification rules based on the call characteristics of open-source components. Second, due to the deep encapsulation layers and cross-library links of open-source components, the shallow propagation semantics in existing technologies cannot fully depict the fine-grained data flow of cross-component functions. This solution expands propagation rules and enhances stack-based path recording capabilities to support multi-level inter-library calls, adapter code, and framework-level callback mechanisms. Finally, exploitability determination of open-source component vulnerabilities requires further identification of vulnerability triggering conditions based on taint propagation, such as the location of sensitive parameters, key function calls within the component, parameter transformations, and filtering. Therefore, this solution extends the dynamic analysis framework to automatically determine whether data reaches the vulnerable function in a truly controllable manner based on the taint propagation chain.
[0031] Specifically, the open-source component vulnerability exploitability assessment method based on dynamic taint analysis provided in this invention mainly consists of the following steps (in combination with...). Figure 1 (as shown) Step S1: When the identification system receives an external request or input event, it automatically assigns a taint identifier to the taint source and marks it as a potential controllable source; Step S2: During system operation, the application system is dynamically monitored using instrumentation techniques to track the propagation path of marked tainted variables during function calls; Step S3: Based on the propagation path traced in step S2, determine whether the tainted variable has been passed to the vulnerability point according to the call characteristics of the known vulnerable function, and generate vulnerability exploitability analysis results.
[0032] The following section provides further explanation of the specific implementation schemes for each step in this method.
[0033] Step S1 in this judgment method is mainly used to complete the taint marking. As the starting step of the whole method, it is used to identify all inputs in the system that may be subject to external control and assign a "taint" label to the identified input parameters.
[0034] As an example, common sources of taint in web systems include, but are not limited to: Query parameters, POST parameters, Header fields, Cookie information, file upload content, and WebSocket input in HTTP requests.
[0035] In its implementation, this method preferentially uses JavaAgent and bytecode instrumentation techniques to instrument request entry functions involved in system operation, such as doPost(), doGet(), and methods annotated with @RequestBody. This dynamically extracts the parameter content received by these methods that can receive external parameters, and marks the parameter names and content of these methods with unique taint IDs. This unique identification of tainted parameters, using taint IDs, allows for continuous tracking of the target during subsequent processing, thus avoiding potential name duplication issues and problems caused by parameter names changing during program flow.
[0036] As an example, this method, in its specific implementation of taint marking, constructs a unified instrumentation mechanism for request entry functions in web systems. First, using JavaAgent technology, it connects to the class loader during system startup. Then, using bytecode modification frameworks (such as ASM and Javassist), it matches and enhances common request entry functions in server frameworks, including the `doGet()` and `doPost()` methods in the Servlet specification, methods annotated with `@RequestMapping`, `@PostMapping`, and `@RequestBody` in the SpringMVC framework, and other controller methods capable of receiving externally controllable input. For example, this invention identifies such entry methods by scanning the bytecode structure and method signatures of classes, and inserts data collection logic at the beginning of their method bodies to ensure that all external input parameters are obtained before the application's business code is executed.
[0037] Secondly, in the inserted bytecode logic, this method accesses the request object (HttpServletRequest or framework-level RequestWrapper) through reflection and the framework abstract interface, and reads the original parameter values from the Query parameters, POST parameters, Header fields, Cookies, uploaded file content, WebSocket message body, etc.; and generates a globally unique taint ID for each parsed parameter object, and maintains the mapping relationship between "parameter object and taint ID" at runtime.
[0038] The taint ID generated here is a combination of a timestamp, a high-order random number, and a hash value of the request context, ensuring global uniqueness across requests and threads. At the same time, this taint ID is attached as an attribute to the parameter object (e.g., through ThreadLocal, WeakHashMap, or object enhancement fields), thereby binding the parameter to the taint identifier so that subsequent propagation tracing can reliably identify it.
[0039] Furthermore, the instrumentation logic in this method adopts lightweight trigger-based injection, which extracts parameters and assigns IDs only when a request entry point is detected, without making intrusive modifications to the main business logic, thus significantly reducing performance overhead.
[0040] Therefore, all tainted variables (i.e., all parameters and their contents that are marked as tainted) will be included in the subsequent tracing process as the starting point for potential attack vectors.
[0041] It should be noted that the method used in this paper to instrument the request entry function is not limited to JavaAgent and bytecode instrumentation techniques. Other techniques such as AST Hook, LLVM IR instrumentation, or eBPF probes can also be used.
[0042] Step S2 in this judgment method is mainly used to perform taint tracking based on the taint marking completed in step S1, that is, to record the propagation process of tainted data (i.e., taint variables marked with taint identifier ID) in the system and construct the propagation path chain from the input source point (Source) to the sensitive operation point (Sink).
[0043] In an object-oriented programming environment, taint propagation paths may span multiple method calls, dependencies between classes, and even involve reflection mechanisms at the framework layer.
[0044] Accordingly, this method employs bytecode instrumentation to dynamically inject monitoring code into methods of all user code and open-source component code during system runtime. This monitoring code is used to execute taint tracking logic. Specifically, it is injected into the entry and exit points of methods in the target system's user code and the open-source component code it references. This enables real-time monitoring of runtime method calls, parameter passing, and data propagation behavior, dynamically tracking the propagation path of tainted data within the program and identifying whether it flows to vulnerable functions. Based on this, the method's input parameter values and return values are recorded during the method call, along with the method name, class name, and package name receiving these parameters, recorded in the order of parameter passing. This constructs a taint propagation path chain to identify the direction and scope of tainted variables' propagation in the real execution environment and whether it flows to a predefined set of vulnerable functions, thus automating vulnerability exploitation.
[0045] Furthermore, the tracing process adopts a stack-based path recording structure to perform fine-grained modeling of the transmission process of all tainted variables (i.e., all parameters and parameter contents marked as tainted, that is, parameters and parameter contents from external user requests, such as parameters and parameter contents from methods like doPost(), doGet(), @RequestBody, etc.), supporting nested calls and recursive processing.
[0046] Specifically, this solution uses a stack-based path recording structure to track the propagation path of tainted variables during function calls. It uses a dynamic instrumentation mechanism to intercept key events such as method entry, method exit, assignment operations, and object field writing during system operation. It also performs unified modeling for parameter objects that may carry tainted values, such as method input parameters, return values, local variables, and object fields.
[0047] When a method enters, the system pushes the call context, including the method name, class name, package name, call depth, and current taint state, onto the path stack. During method execution, it updates the taint label in real time based on propagation rules such as assignment semantics, reference relationships, and encoding conversions. When the method exits, it records the taint changes in the return value and pops the node from the stack, thus forming a complete taint propagation chain. This path recording structure supports nested and recursive calls, maintaining accurate taint flow characterization even under multi-level function calls, object passing, and complex reference relationships.
[0048] This tracing mechanism makes the solution applicable to technology environments such as Java, Python, PHP, and Go. This method not only accurately depicts the actual propagation path of user-controlled input from the entry point to the vulnerable function, but also significantly reduces the false positive rate through fine-grained propagation semantics at the value level. It can distinguish between controllable taints, uncontrollable internal variables, and partially controllable data after intermediate transformations, ultimately achieving high-precision determination of the exploitability of open-source component vulnerabilities and supporting the reproduction and interpretation of real attack paths in complex systems.
[0049] As further explanation, when this method implements a stack-based path record structure for taint tracing, when instrumentation intercepts a method entry at runtime, a call frame is created in memory and pushed onto the path stack. The created call frame contains the method signature (method name / class name / package name), call depth, tainted references to the input parameter slots, tainted snapshots of local variables, and timestamps.
[0050] Based on this, it is further configured so that events such as assignment, field writing, method calling and return within the method body are all triggered by instrumentation, updating the taint references of each slot in the current frame according to the event semantics, and generating or merging taint tags TaintTag in TaintMap when necessary; When a method returns or an exception propagates, the taint information of the return value is read at the return point and merged back into the upper frame. Then, the current frame is popped and the path segment represented by that frame is appended to the global PathChain.
[0051] Thus, when taint marking is performed in step S1, the external input has been established as the starting TaintTag at the entry point and referenced in the first frame input parameter slot; Then, during the final labeling in step S2, PathStack will continuously expand, merge, and backtrack downwards from these initial labels as the root. Finally, in step S3, if a matched vulnerable function node is encountered, the current PathStack / PathChain snapshot is read as evidence for exploitability assessment. Therefore, the stack structure not only ensures taint isolation and backtracking consistency of each call level in nested and recursive scenarios, but also provides the judgment module with complete and reproducible call segment evidence.
[0052] Building upon the above approach, this method uses a call chain tracing mechanism to progressively construct the function path traversed by the tainted variable and matches it against whether it contains the vulnerability function disclosed in the CVE.
[0053] Specifically, this method uses call chain tracing to identify whether tainted variables have reached the vulnerable function, which can be achieved through the following approach: (1) Intercept all critical method call events during runtime and construct a call chain record containing method name, class name, package name, input parameter taint status and return value taint status according to the call order; (2) Based on the taint identifier ID established in step S1, the tainted parameter object is continuously traced down in the call chain of step (1) to identify whether it is further propagated, derived or merged in each method frame; (3) Compare each node of the constructed call chain to identify whether there is a method signature or sensitive call point corresponding to the CVE-disclosed vulnerability function; (4) If the call chain contains the target vulnerable function, and the input parameter slot of the function still contains a taint identifier ID that can be traced back to external input, then the call chain is confirmed as a candidate chain that needs further analysis and is used for subsequent exploitability determination.
[0054] The taint propagation path tracing scheme based on the above approach specifically expands upon the taint identifier ID generated in step S1. First, it instrumentes external input request parameters (such as Query parameters, POST parameters, Headers, Cookies, etc.) at the entry function, generating a unique taint ID for each input parameter. Subsequently, during system runtime, this taint ID is attached to the initial parameter object and transferred along with the object during subsequent propagation. For the tracing object, this scheme processes all parameter objects that may carry data, including method input parameters, return values, local variables, object fields, collection and array elements, etc. The instrumentation mechanism performs minimal data flow checks at method call points, return points, assignment operations, and field access points: if a parameter object contains a taint ID, that taint ID is copied to a new object according to the propagation rules, derives a sub-taint, or continues to be retained in the return value. In this way, the system can continuously identify the path nodes traversed by external input during system execution based on the taint ID.
[0055] Therefore, this solution marks only external request parameters as taint sources, without fully tracking internal system variables and fixed configurations, thus significantly reducing runtime overhead. Furthermore, this solution only collects taint propagation events at the method input and return value levels, rather than tracking all instruction-level data streams, ensuring acceptable overhead in production environments. Moreover, this solution uses taint IDs as a unified index to construct a minimum necessary propagation chain through key function nodes (such as user code functions, open-source component functions, and target vulnerability functions), avoiding interference from invalid paths. This allows the system to obtain a complete propagation chain from external input to the vulnerable function with extremely low performance overhead, significantly improving the accuracy of vulnerability exploitability assessment while avoiding false positives, path bloat, and impracticality issues associated with traditional full taint analysis.
[0056] Step S3 in this judgment method is mainly used to perform taint analysis based on the taint variable propagation path traced in step S2. Specifically, it determines whether the traced taint variable actually flows into the vulnerable function, and combines parameter control capabilities to determine whether the vulnerability is exploitable.
[0057] Specifically, this step, in analyzing and judging taint variables, mainly involves the following two aspects: Path determination: Compare whether the taint propagation path matches the call path of the vulnerable function to determine whether there is an actual data flow path into the vulnerable function; Controllability analysis: Determine whether tainted variables are cleaned, overwritten, or replaced during propagation, and whether they still maintain the controllability of the original external input; if the taint remains under effective control before entering the vulnerable function, then the vulnerable function is considered to be exploitable.
[0058] As a supplementary explanation, the taint analysis process also needs to be supplemented by information such as the number of parameters, parameter types, and usage of the vulnerable function to avoid misjudgments caused by function overloading or parameter conversion.
[0059] Specifically, in conjunction with the scheme in step S2 above that uses the call chain tracing mechanism to identify whether tainted variables have reached the vulnerable function, when the target vulnerable function is identified in the call chain, the input parameters of the function will be formatted and checked, including whether the number of parameters is consistent with the definition of the vulnerable function, whether the parameter types meet the prerequisites for exploitation, and how the parameters are used in the function, such as whether they are directly involved in string concatenation, command construction, deserialization input, etc.
[0060] This judgment process is mainly based on a one-to-one comparison between the statically obtainable function signature and the actual parameter types at runtime. If the tainted variable remains controllable when entering the vulnerable function and meets the requirements of parameter format and usage, the vulnerability can be determined to be exploitable in the current system; if it is cleaned up, overwritten, or converted into uncontrollable data during the propagation path, it is determined to be unexploitable.
[0061] The method for assessing the exploitability of open-source components based on dynamic taint analysis presented in this example can be adapted into a software program to form a corresponding system for assessing the exploitability of open-source components based on dynamic taint analysis. During runtime, this software program executes the aforementioned method for assessing the exploitability of open-source components and stores the results in a suitable storage medium for the processor to retrieve and execute.
[0062] The resulting open-source component vulnerability exploitability assessment system based on dynamic taint analysis mainly includes: a taint marking module, a taint tracking module, and a taint analysis module.
[0063] The taint marking module is configured to recognize external requests or input events received by the application system, and automatically assign taint identifiers to taint sources and mark them as potential controllable sources.
[0064] The taint tracking module is configured to interact with the taint marking module, enabling dynamic monitoring of the application system during its operation via instrumentation techniques, and tracking the propagation path of tainted variables marked by the taint marking module during function calls.
[0065] The taint analysis module is configured to interact with the taint tracking module. Based on the propagation path of tainted variables tracked by the taint tracking module and the call characteristics of known vulnerable functions, it can determine whether tainted variables have been passed to the vulnerability point and generate vulnerability exploitability analysis results.
[0066] As a further explanation, the taint marking module in this system is configured to instrument request entry functions involved in the application system's operation, such as `doPost()`, `doGet()`, and methods annotated with `@RequestBody`. It dynamically extracts the parameter content received by these methods that can receive external parameters and marks the parameter names and content of these methods with unique taint IDs. This unique identification of tainted parameters, using taint IDs, allows for continuous tracking of the target during subsequent processing, thus avoiding potential name duplication issues and problems caused by parameter names changing during program flow when using parameter names for marking.
[0067] As further explanation, the taint tracking module in this system is configured to dynamically inject monitoring code into methods in all user code and open-source component code during system runtime via instrumentation. This monitoring code is used to execute taint tracking logic. Here, the monitoring code is injected into the entry and exit points of each method in the target system's user code and the open-source component code it references. This enables real-time monitoring of runtime method calls, parameter passing, and data propagation behavior, thereby dynamically tracking the propagation path of tainted data in the program and identifying whether it flows to vulnerable functions.
[0068] Based on this, the values of the parameters passed to the instrumented method during invocation and the return value after execution are recorded. The method name, class name, and package name that receive these parameters are also recorded in the order of parameter passing. This is used to construct a taint propagation path chain to identify the direction and scope of taint variables in the real execution environment and whether they flow to a predefined set of vulnerable functions, thereby enabling automated determination of vulnerability exploitability.
[0069] Furthermore, this taint tracking module is configured to use a stack-based path recording structure to perform fine-grained modeling of the taint value transmission process, supporting nested calls and recursive processing. On this basis, through the call chain tracing mechanism, the function path traversed by the taint variable can be constructed step by step, and whether it contains the vulnerable functions disclosed in the CVE.
[0070] As further explanation, the taint analysis module in this system is configured to determine whether a tainted variable actually flows into a vulnerable function, and to determine whether a vulnerability is exploitable by combining parameter control capabilities.
[0071] The exploitability assessment scheme for open-source components based on dynamic taint analysis, developed based on the above approach, achieves real-time tracking of the propagation path of external input data by instrumenting key functions and component interfaces during program runtime.
[0072] This approach automatically assigns taint identifiers to input parameters and marks them as potential controllable sources when the system receives external requests or input events. During program execution, it continuously records method call contexts and constructs taint propagation paths. When tainted data is detected flowing into a set of known vulnerable functions, exploitability determination logic is automatically triggered. Based on the cleansing or transformation of input data in the propagation chain, the vulnerability is determined to be "exploitable," "partially controllable," or "unexploitable," and the complete propagation chain and exploitability result are output. This method can automatically determine vulnerability exploitability without affecting the system's business logic, significantly improving the accuracy and practicality of vulnerability detection.
[0073] As a further explanation, the exploitability assessment scheme for open-source component vulnerabilities based on dynamic taint analysis proposed in this invention can be implemented in multiple language environments by introducing cross-language adaptability and event-triggered dynamic analysis framework in the architecture design and operation mechanism.
[0074] As a further example, firstly, in terms of cross-language implementation, the core logic of this solution, such as "taint propagation modeling, function call interception, parameter value collection, and path stack recording," can be abstracted into a unified execution model, and the collection end and analysis end can be decoupled. The collection end can select different instrumentation methods according to the running mechanism of the target programming language. For example, JavaAgent bytecode instrumentation can be used in the Java environment, AST Hook can be used in Python, LLVM IR Pass can be used in Go / C / C++, and function calls can be intercepted through eBPF probes at the operating system layer. This ensures that the solution of this invention can achieve real-time tracking of function entry, exit, and parameter objects in all language environments that support instrumentation mechanisms.
[0075] Secondly, regarding event-triggered dynamic analysis, the present invention uses monitoring of controllable external input events (such as HTTP requests, command-line parameters, RPC calls, message queue inputs, etc.) as the analysis initiation condition. It only starts recording the taint propagation chain when external input is detected and automatically releases the analysis context after the request ends. This mechanism avoids the high load associated with traditional continuous monitoring and significantly reduces runtime performance consumption.
[0076] Furthermore, during the vulnerability exploitability assessment process, the present invention's solution can collaboratively utilize runtime-collected data with pre-defined static context information (such as vulnerability function signatures, parameter sensitivity, filter function lists, open-source component call graphs, etc.). By comparing the literal changes, semantic changes, and cleanup behaviors of parameters in the taint chain, dynamic verification of the vulnerability's true controllability can be achieved. Ultimately, this forms a closed-loop analysis path combining static prediction and dynamic verification, making the assessment results more accurate and reliable.
[0077] This invention provides a scheme for determining the exploitability of vulnerabilities in open-source components based on dynamic taint analysis. The following examples further illustrate its implementation process.
[0078] Example 1 See Figure 1 As shown in the example, the implementation scheme for determining the exploitability of open-source component vulnerabilities based on dynamic taint analysis is adopted. It adopts an event-triggered mechanism, with the input being the CVE vulnerability function set VulnFuncs and external HTTP request parameters, and the output being the vulnerability exploitability result and the taint propagation path.
[0079] The JavaAgent is loaded at system startup and bytecode instrumentation is performed on target classes and methods to support runtime data tracing.
[0080] Upon receiving an HTTP request, extract the request parameters and assign a unique taint identifier to mark it as a potential controllable input (Source).
[0081] During request processing, instrumentation records the context information of method calls and dynamically maintains the taint propagation chain PathChain. If taint data flows into any function in VulnFuncs, it is considered a sink and an append record is added.
[0082] Then, the changes in the input and Sink parameters are compared: if no purification is performed, it is determined to be usable; if there is a partial change, it is determined to be partially controllable; if there is no external input, it is unusable.
[0083] The final output shows the propagation path and judgment result, enabling real-time, low-overhead identification of vulnerability exploitability.
[0084] As a further explanation, the solution in this example can be implemented through the following algorithm:
[0085] Example 2 To further verify the effectiveness of the present invention, this example demonstrates the construction of a web application instance, as follows: Figure 2 As shown.
[0086] The client submits the parameter 'content' via an HTTP POST request. The server first calls 'addContent()' in 'processContent()' to process it and generate 'newContent', and then passes 'newContent' to the known vulnerable function 'vulFuc()'.
[0087] During runtime, dynamic taint analysis marks content as a controllable input (Source) and tracks its propagation process: content is added to the taint mark set TaintSet as an external controllable input; the content parameter is processed by the addContent function and becomes the newContent parameter, which contains the complete original content value and is added to TaintSet; when newContent is passed to vulFuc(), vulFuc is recorded as a taint sink.
[0088] Analysis results show that the request path forms a complete taint propagation chain from Source to Sink, indicating that the vulnerability can be exploited in the current system.
[0089] Example 3 To further verify the effectiveness and accuracy of the open-source component vulnerability exploitability determination scheme based on dynamic taint analysis proposed in this invention in a real software environment, this example constructs an experimental system containing typical open-source component vulnerabilities, simulates attack scenarios, observes whether the taint tracing path can identify the vulnerability exploitation path, and evaluates the effect of this method in real-world exploitation determination.
[0090] (1) Experimental setup: The experimental environment and components are as follows: The experimental target range is implemented based on Spring Boot + Maven + OpenJDK, reproducing the CVE-2017-18349 (Fastjson deserialization) vulnerability; a JavaAgent is implemented according to the method proposed in this paper, which is used to perform taint marking and propagation tracking on method parameters at runtime, and can output a complete "path trace" and warning level (ALERT / WARN / NONE) when a dangerous function is called. The Fastjson component information is shown in the table below.
[0091]
[0092] The target range design includes three scenarios: Scenario 1 (Completely Controllable Path): The server receives the user's POST request body (input) and directly passes it to JSON.parseObject(input). In this scenario, the parameter entering the dangerous function parseObject() comes from the user's request and is directly introduced into the dangerous function without modification.
[0093] Scenario 2 (Uncontrollable path): There is no external input, but a fixed string inside the server is used (e.g., String fixed = "{\"msg\": \"hello\"}";), and the fixed value is passed to JSON.parseObject(fixed).
[0094] Scenario 3 (Partially Controllable Path): The server receives a user's POST body (input), but before passing it to JSON.parseObject, it calls the local function modifiedFunction(input). This function uses regular expression replacement replaceAll("\"@type\"\\s*:\\s*\"[^\"]*\",?", "") to try to remove the @type field from the JSON, and then passes the modified modified string to JSON.parseObject(modified) for parsing.
[0095] (2) Experimental design: The experiment was conducted according to the following steps: 1. Vulnerable environment setup: Build components containing known vulnerable versions and import them into the test system; 2. Request parameter construction: Construct a request using Postman to simulate external attack input; 3. Taint Instrumentation Tracing: Enables dynamic taint analysis agent to automatically tag all request parameters and trace their propagation path; 4. Path matching and controllability assessment: Match the taint propagation path with the target vulnerable function to determine whether there is an actual exploitation path.
[0096] (3) Analysis of experimental results 1. Experimental Results Through dynamic taint analysis experiments on three typical scenarios, it can be found that the method proposed in this invention can effectively distinguish different types of parameter propagation paths and their impact on vulnerability exploitability, as shown in Table 1.
[0097] In a fully controllable scenario, external input parameters enter the dangerous function directly without any processing. Dynamic taint analysis fully reconstructs the propagation chain from user request to vulnerable function and accurately provides high-risk alerts. In uncontrollable scenarios, since the parameters are entirely derived from fixed values within the system, taint analysis did not trigger any alarms, effectively avoiding false alarms; In some controllable scenarios, although the tainted parameters are passed to dangerous functions, they undergo code logic transformations during propagation. Dynamic taint analysis correctly records the transformation path and provides a medium-level alarm, indicating that further manual review is required.
[0098] Experimental results show that the method proposed in this invention can automate and differentiate the assessment of vulnerability exploitability, thereby discovering high-risk exploitable vulnerabilities and reducing unnecessary false positives and false negatives.
[0099] Table 1:
[0100] 2. Path tracing examples and significance: (1) Scenario 1 (Fully Controllable Path) Tracking Information Summary:
[0101] The sequence is concise and direct; the taint is not overwritten after being passed in, thus the dynamic taint system directly triggers a high-level alarm. This result verifies that the method can identify high-risk exploitation conditions where "directly controllable parameters are passed into dangerous functions."
[0102] (2) No tracking record was found in Scenario 2 (uncontrollable path), indicating that the Agent correctly distinguished the source of the taint and did not mistakenly label the fixed value inside the system as a taint, thus avoiding false alarms. This behavior is one of the keys to evaluating the accuracy of the dynamic taint system.
[0103] (3) Summary of tracking information for scenario 3 (partially controllable path):
[0104] This tracing not only records the propagation path of the taint but also records snapshots of the input and output parameters of the modifiedFunction, allowing analysts to directly observe that the sensitive field (@type) is removed before reaching the dangerous function. Based on this fact, the agent sets the alert level to WARN and displays a "parameter partially controllable (modified)" message in the logs.
[0105] Based on the above-mentioned vulnerability exploitability determination scheme based on dynamic taint analysis, this embodiment of the invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the steps of the above-mentioned open-source component vulnerability exploitability determination method.
[0106] This invention also provides a processor for running a program, wherein the program executes the steps of the above-described open-source component vulnerability exploitability determination method during runtime.
[0107] This invention also provides a terminal device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. The program code is loaded and executed by the processor to implement the steps of the above-described open-source component vulnerability exploitability determination method.
[0108] The present invention also provides a computer program product that, when executed on a data processing device, is adapted to perform the steps of the above-described open-source component vulnerability exploitability determination method.
[0109] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0111] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0112] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0113] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0114] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0115] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0116] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0117] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.
[0118] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0119] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0120] The method, specific system unit, or part thereof of the present invention described above is a pure software architecture. It can be deployed via program code on physical media, such as hard disks, optical discs, or any electronic device (such as smartphones or computer-readable storage media). When a machine loads and executes the program code (e.g., a smartphone loads and executes it), the machine becomes a device for implementing the present invention. The method and device of the present invention can also be transmitted in program code form via transmission media, such as cables, optical fibers, or any other transmission method. When the program code is received, loaded, and executed by a machine (e.g., a smartphone), the machine becomes a device for implementing the present invention.
[0121] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.
Claims
1. A method for determining the exploitability of vulnerabilities in open-source components based on dynamic taint analysis, characterized in that, The method automatically assigns taint identifiers to taint sources and marks them as potential controllable sources when the system receives external requests or input events. Next, during system operation, instrumentation technology is used to dynamically monitor the application system and track the propagation path of marked tainted variables during function calls; Finally, based on the calling characteristics of known vulnerable functions, it is determined whether tainted variables are passed to the vulnerability point, and vulnerability exploitability analysis results are generated.
2. The method for determining the exploitability of open-source component vulnerabilities according to claim 1, characterized in that, The method automatically assigns taint identifiers to taint sources, instrumentes the request entry functions involved in the system operation, dynamically extracts the received parameter content, and marks them with unique taint IDs.
3. The method for determining the exploitability of open-source component vulnerabilities according to claim 1, characterized in that, When tracking tainted variables, the method described above dynamically injects monitoring code into methods in all user code and open-source component code during system runtime through instrumentation. This code is used to execute taint tracking logic and records the input parameter values and return values of the instrumented methods when they are called. It also records the method name, class name, and package name that receive these parameters, and records them in the order of parameter passing, thereby constructing a taint propagation path chain.
4. The method for determining the exploitability of open-source component vulnerabilities according to claim 2, characterized in that, When tracking tainted variables, the method employs a stack-based path record structure to perform refined modeling of the transmission process of tainted variables.
5. The method for determining the exploitability of open-source component vulnerabilities according to claim 1, characterized in that, During taint analysis, the method determines whether a vulnerability is exploitable by judging whether the tainted variable actually flows into the vulnerability function and by combining parameter control capabilities.
6. An open-source component vulnerability exploitability assessment system based on dynamic taint analysis, characterized in that, The system includes: A taint marking module is configured to recognize when the system receives an external request or input event, and to automatically assign a taint identifier to the taint source and mark it as a potential controllable source. The taint tracking module is configured to dynamically monitor the application system during system operation using instrumentation technology, and track the propagation path of tainted variables marked by the taint marking module during function calls. The taint analysis module is configured to determine whether a taint variable has been passed to a vulnerability point based on the propagation path of the taint variable tracked by the taint tracking module and the call characteristics of the known vulnerable function, and generate vulnerability exploitability analysis results.
7. The open-source component vulnerability exploitability assessment system according to claim 6, characterized in that, When automatically assigning taint identifiers to taint sources, the taint marking module instrumentes the request entry functions involved in the system operation, dynamically extracts the received parameter content, and marks them with unique taint IDs.
8. The open-source component vulnerability exploitability assessment system according to claim 6, characterized in that, The taint tracking module is configured to dynamically inject monitoring code into methods in all user code and open-source component code during system operation via instrumentation. This code is used to execute taint tracking logic and records the input parameter values and return values of the instrumented methods when they are called. It also records the method name, class name, and package name that receive these parameters, and records them in the order of parameter passing, thereby constructing a taint propagation path chain.
9. The open-source component vulnerability exploitability assessment system according to claim 8, characterized in that, The taint tracking module is configured to use a stack-based path recording structure to perform refined modeling of the taint variable transmission process.
10. A computer program product, characterized in that, When executed on a data processing device, it is suitable for performing the steps of the open-source component vulnerability exploitability determination method according to any one of claims 1-5.
Citation Information
Cited By
Third-party library vulnerability verification method and device based on reachability analysis
CN122133158A