Java deserialization vulnerability detection method

Abstract

The invention provides a method for detecting a Java deserialization vulnerability. Comprising the steps that Java program semantic information is extracted through static analysis, and a code attribute graph is constructed; processing field storage and loading statements by adopting an edge pruning optimization strategy, removing redundant data stream edges, and generating direct connection edges to simplify the topological structure of the call graph; dynamically evaluating pollution propagation weights of method parameters and return values based on a controllability analysis algorithm, and implementing path reachability dynamic pruning; a complete attack chain from a deserialization entrance to a danger method is quickly positioned through a bottom-up reverse traversal mechanism of a graph database. According to the method, the path explosion problem is inhibited through an edge pruning strategy, the call chain tracking precision is improved in combination with context sensitive analysis, the detection efficiency and the path coverage rate are balanced by utilizing controllable dynamic pruning, and the method is suitable for the network threat that serialized data is easy to steal, intercept and tamper in an unsafe network environment. A high-precision and low-false-alarm detection scheme is provided, and collaborative optimization of detection efficiency and reliability is realized.

Description

Technical Field

[0001] This invention relates to a method for detecting Java deserialization vulnerabilities, belonging to the field of vulnerability detection. Background Technology

[0002] In modern software development, open-source software and components play a crucial role. With the rapid iteration of the technology ecosystem, open-source technology has become a significant force driving the efficiency of software development. Its high efficiency, flexibility, and low cost have led to its widespread adoption by enterprises and developers to accelerate the development process, reduce R&D costs, and enhance innovation capabilities. According to a SourceClear survey report, the number of open-source projects worldwide is growing exponentially, and is projected to exceed 300 million by 2026.

[0003] As one of the mainstream programming languages, Java occupies an important position in the open-source ecosystem. Whether it's widely used Java open-source frameworks like Spring and Hibernate, or middleware commonly used in distributed services like Dubbo and Zookeeper, the Java language plays an indispensable role. In modern software development, many applications heavily rely on open-source third-party libraries and frameworks to improve development efficiency and accelerate product delivery. However, the use of open-source components not only improves the development efficiency of Java applications but also increases their security risks. Because the Java language relies on a large number of third-party libraries and toolkits when handling complex business scenarios, if security vulnerabilities exist in these components, the security of the entire system will be seriously threatened. Especially in insecure network environments, attackers may intercept serialized data transmitted in distributed systems and microservice architectures through man-in-the-middle attacks, replacing normal serialized data with a pre-constructed serialized byte stream containing a malicious exploit chain. When the receiving application performs a deserialization operation on this byte stream, the malicious exploit chain will be automatically triggered, leading to malicious purposes such as sensitive data theft, backdoor implantation, and internal network penetration.

[0004] Currently, some work has been carried out on the detection technology of Java deserialization vulnerabilities. For example, the existing patent [1] A Java deserialization vulnerability detection method and system (patent number CN115270131A) combines code attribute graph technology to detect Java deserialization vulnerabilities. However, this method may face the static path explosion problem, making it difficult to balance detection accuracy and efficiency. Therefore, it is necessary to further study Java deserialization vulnerability detection technology, reduce detection overhead while ensuring detection accuracy, so as to cope with the increasingly severe challenges of software supply chain security and network attacks, and strengthen the security of enterprise data and applications in network transmission and processing. Summary of the Invention

[0005] The purpose of this invention is to overcome the challenges of balancing accuracy and efficiency, as well as the static path explosion problem, in detecting Java deserialization vulnerabilities. First, a code attribute graph is constructed based on semantic information in the Java code. Then, edge pruning and expansion optimization strategies are used to handle four types of statements in Java that cause precision loss. A controllability analysis algorithm is combined to prune irrelevant function calls. Finally, based on the controllability analysis results and the search capabilities of the graph database, a bottom-up search strategy is proposed to find all possible call chains.

[0006] This invention provides a method for detecting Java deserialization vulnerabilities, comprising:

[0007] Extract semantic information from the target Java program, including class inheritance relationships, method signatures, and interface implementations, and generate an intermediate representation;

[0008] Based on the semantic information, a code attribute graph is constructed, including: a class relationship graph, representing the subordinate and inheritance relationships between classes and methods; a polymorphic call graph, linking all implementation paths of polymorphic methods; and a context-sensitive method call graph, which uses an edge pruning and expansion optimization algorithm to process field storage and loading statements, remove redundant edges that cause data flow merging, and generate a simplified call graph.

[0009] Perform controllability analysis on the context-sensitive method call graph, evaluate the controllability of method parameters and return values, prune unreachable paths, and generate an optimized code attribute graph. Store the optimized code attribute graph in a graph database, and traverse the call chain from bottom to top based on controllability conditions to identify the exploitable deserialization call chain from the deserialization entry point to the dangerous method.

[0010] Preferably, the extraction of semantic information from the target Java program specifically includes:

[0011] Use static analysis tools to parse Java bytecode and extract class inheritance relationships, method signatures, and interface implementation relationships;

[0012] The extracted semantic information is converted into an intermediate representation, which includes class method call relationships, field access operations, and control flow graphs.

[0013] Preferably, the construction of the code attribute graph based on semantic information specifically includes:

[0014] A class relationship graph is constructed based on the intermediate representation. The class relationship graph represents the subordinate relationship, inheritance relationship and interface implementation relationship between classes and methods through directed edges.

[0015] Identify all polymorphic method declarations in a Java program, including interface methods, abstract class methods, and method overriding scenarios. Traverse class inheritance relationships, dynamically bind and associate polymorphic method declarations with all concrete implementation methods, create call edges for each polymorphic method in the polymorphic call graph, and link parent class or interface method declarations to subclass implementation methods.

[0016] Traverse the method control flow graph, identify all field storage statements and field loading statements, perform edge pruning and expansion optimization, and generate a context-sensitive method call graph.

[0017] Preferably, the edge pruning and expansion optimization of the field storage statement in the method includes:

[0018] The method traverses the control flow graph, identifies operation patterns such as field storage statements i:af=b, and triggers pruning operations when the following conditions are met:

[0019] (1) Both the base object a and the stored value b are directly derived from the call point parameters of method m;

[0020] (2) a and b were not reassigned within method m;

[0021] If the above conditions are met, remove the original edge generated by the stored statement from the pointer flow graph (PFG).

[0022] For each triple in temporary storage<tar,f,src> If any of the following conditions are met, a new direct edge is generated and added to addEdges:

[0023] (1) tar or src is redefined within the method;

[0024] (2) The tar or src is not fully mapped to the call point parameters;

[0025] Preferably, the edge pruning and expansion optimization of the field loading statement in the method includes:

[0026] Traverse the method control flow graph, identify operation patterns such as field loading statements like `i:tar=src.f`, and prune branches when the following conditions are met:

[0027] (1) The base object a is directly derived from the call point parameter of method m and src is not reassigned in method m;

[0028] (2) The target variable tar of the field loading statement comes from the return value variable of method m;

[0029] If the above conditions are met, remove the original edge generated by the loading statement from the pointer flow graph;

[0030] For each triple in the temporary loading<tar,src,f> If the set of objects pointed to by the base object src contains a specific object o i Then generate from o i The direct edge from .f to the target variable tar;

[0031] Preferably, the controllability analysis of the context-sensitive method call graph specifically includes:

[0032] Perform controllability state initialization by assigning controllability weights to variables, the weights being defined as follows:

[0033] (1) Weight = ∞: indicates that the parameter is uncontrollable;

[0034] (2) Weight = 0: This means that it can be directly controlled, and the parameter may come from external input;

[0035] (3) Weight = [1, n]: represents the weight that depends on the nth method parameter;

[0036] Process each statement in the control flow graph. If a variable is directly assigned a value by a controllable variable, it inherits the controllability weight. If a variable is instantiated using the `new` statement and the constructor parameter contains an uncontrollable variable, it is marked as uncontrollable. If a variable receives a method return value, its controllability weight is determined by the controllability of the returned value of the called method. If a variable is assigned a value through field loading or storage operations, it is necessary to verify the controllability of the base object and whether the field access path meets the constraints.

[0037] Preferably, the method further includes:

[0038] A predefined set of security-sensitive endpoints is used to label the corresponding method nodes with the vulnerability trigger tag SINK in the graph database.

[0039] Starting from all SINK nodes, the traversal is based on the context-sensitive code attribute graph after pruning, and backtracks along the call chain to the deserialization entry method. If the variable node in the current path is marked as uncontrollable, i.e., the weight is ∞ or the path depth exceeds the preset threshold, the branch traversal is terminated.

[0040] For the complete path that successfully backtracks to the deserialization entry point, extract its method call sequence to form a complete deserialization call chain.

[0041] Compared with the prior art, the present invention has the following beneficial effects:

[0042] The Java deserialization vulnerability detection method proposed in this invention, based on call graph pruning optimization, can achieve rapid construction of context-sensitive call graphs through edge pruning expansion optimization, and utilizes controllability analysis algorithms to achieve efficient pruning during traversal, providing a solution for improving efficiency while ensuring accuracy in Java deserialization vulnerability detection. Attached Figure Description

[0043] Figure 1 This is a flowchart of the Java deserialization vulnerability detection method in an embodiment of the present invention.

[0044] Figure 2 This is a schematic diagram of code attributes constructed based on Java program semantic information in an embodiment of the present invention. Detailed Implementation

[0045] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments and accompanying drawings. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0046] To overcome the challenges of balancing accuracy and efficiency, as well as the static path explosion problem, in detecting Java deserialization vulnerabilities, this invention provides a Java deserialization vulnerability detection method. First, a code attribute graph is constructed based on semantic information in the Java code. Then, edge pruning and expansion optimization strategies are used to handle four types of statements in Java that cause precision loss. A controllability analysis algorithm is combined to prune irrelevant function calls. Finally, based on the controllability analysis results of the method and combined with the search capabilities of the graph database, a bottom-up search strategy is proposed to find all possible call chains.

[0047] In this embodiment, as Figure 1 As shown, the Java deserialization vulnerability detection method specifically includes the following steps:

[0048] S100 extracts the semantic information of the target Java program and generates an intermediate representation.

[0049] Step S100 includes the following steps S101 and S102:

[0050] S101 uses the static analysis tool Soot to parse Java bytecode and extract class inheritance relationships, method signatures, and interface implementation relationships.

[0051] S102, the extracted semantic information is converted into an intermediate representation (IR), which includes class method call relationships, field access operations and control flow graphs.

[0052] S200, construct a code attribute graph based on the semantic information.

[0053] Step S200 includes the following steps S201, S202, S203, S204, S205, and S206.

[0054] S201: Construct a class relationship graph based on the intermediate representation. The class relationship graph represents the subordinate relationship, inheritance relationship and interface implementation relationship between classes and methods through directed edges.

[0055] S202: Identify all polymorphic method declarations in a Java program, including interface methods, abstract class methods, and method overriding scenarios. Traverse class inheritance relationships, dynamically bind and associate polymorphic method declarations with all concrete implementation methods, create call edges for each polymorphic method in the polymorphic call graph, and link parent class or interface method declarations to subclass implementation methods.

[0056] For example, the `AnnotationInvocationHandler` class contains a `readObject` method, which calls the `setValue` method. This `setValue` method then calls the `setValue` method in `AbstractInputCheckedMapDecorator` via polymorphism. Simultaneously, `setValue` calls the `checkSetValue` method, which in turn calls the `checkSetValue` method in the `TransformedMap` class via polymorphism. `checkSetValue` then calls the `transform` method, which in turn calls the `transform` method in `ChainedTransformer` via polymorphism. This new `transform` method then calls the `transform` method in `InvokerTransformer` via polymorphism, and this new `transform` method calls the `method.invoke` method.

[0057] The code property graph is constructed step by step for the above examples. Figure 2 As shown, all the has edges in the graph are obtained, and a polymorphic call graph is constructed to obtain all the Call edges in the graph.

[0058] S203: Traverse the method control flow graph, identify operation patterns such as field storage statements i:af=b, and trigger pruning operations when the following conditions are met:

[0059] (1) Both the base object a and the stored value b are directly derived from the call point parameters of method m;

[0060] (2) a and b were not reassigned within method m, i.e. and

[0061] If the above conditions are met, the original edge generated by the stored statement is removed from the pointer flow graph, that is, the method call point i is added to the pruning set cutStores, and the analysis of statements in cutStores is skipped during analysis.

[0062] The pruning conditions are defined by the following formula:

[0063]

[0064] Where m pki The k-th formal parameter of method m, i ak This indicates the k-th parameter of the calling point i.

[0065] S204: For each triplet in tempStores<tar,f,src> If any of the following conditions are met, a new direct edge is generated and added to addEdges:

[0066] (1) tar or src is redefined within the method, i.e. )

[0067] (2) tar or src is not fully mapped to the call point parameters, i.e. (k:m pk =tar)∨(k:m pk =src)

[0068] The edge generation rule is defined by the following formula:

[0069]

[0070] Among them o j ∈pt(tar) is the set of objects that tar points to, and addEdges is the set of newly added edges.

[0071] S205: Traverse the method control flow graph, identify operation patterns such as field storage statements i:tar=src.f, and trigger pruning operations when the following conditions are met:

[0072] (1) The base object a directly originates from the call point parameter of method m and src is not reassigned within method m (i.e.

[0073] );

[0074] (2) The target variable tar of the field loading statement comes from the return value variable of method m;

[0075] If the above conditions are met, remove the original edge generated by the loading statement from the pointer flow graph, that is, add the removed return edge to cutReturns, and skip the analysis of statements in cutReturns during analysis.

[0076] The pruning conditions are defined by the following formula:

[0077]

[0078] Where tempLoads represents the temporary loading set, j ak This indicates the k-th parameter of the calling point j.

[0079] S206: For each triplet in tempLoads<tar,src,f> If the set of objects pointed to by the base object src contains a specific object o i Then generate from o i The direct edge from .f to the target variable tar.

[0080] The edge generation rule is defined by the following formula:

[0081]

[0082] For example, the `setB(B b)` method in class A contains the line `this.b = b`, which assigns the passed parameter `b` to the member variable `b` of the current instance of class A. The `getB()` method in class A contains two lines of code: `Br = this.b` and `return r`, which returns the member variable `b` held by the current instance of class A, providing an entry point for external access to this type of object (`B`). In the `main` method, first, an instance of class A `a1` and an instance of class B `b1` are created using the `new` statement. The `b1` object is injected into the member variable `b` of instance `a1` using `a1.setB(b1)`, and the bound `b1` object is retrieved using `a1.getB()` and assigned to `res1`. A second instance of class A `a2` and a second instance of class B `b2` are created. The `b2` object is injected into the member variable `b` of instance `a2` using `a2.getB(b2)`, and the bound `b2` object is retrieved using `a2.getB()` and assigned to `res2`. Based on the above example, pruning and expansion optimizations are performed. According to step S203, if the operation mode this.b = b is identified and the pruning condition is met, then the calls from b to a1.b and from b to a2.b are pruned in the PFG. According to step S204, direct edges from b1 and b2 to the corresponding this.b are added respectively. According to step S205, if the operation mode Br = this.b is identified and the pruning condition is met, then the return edges from r to res1 and r to res2 are pruned in the PFG. According to step S206, direct edges from a1.b to res1 and from a2.b to res2.b are added respectively.

[0083] S300: Perform controllability analysis on the context-sensitive method call graph, evaluate the controllability of method parameters and return values, prune unreachable paths, and generate an optimized code attribute graph.

[0084] Step S300 includes the following steps S301 and S302:

[0085] S301: Perform controllability state initialization, assign controllability weights to variables, and define the weights as follows:

[0086] (1) Weight = ∞: indicates that the parameter is uncontrollable;

[0087] (2) Weight = 0: This means that it can be directly controlled, and the parameter may come from external input;

[0088] (3) Weight = [1, n]: represents the weight that depends on the nth method parameter;

[0089] S302: Process each statement in the control flow graph. If a variable is directly assigned a value by a controllable variable, then the controllability weight is inherited. If a variable is instantiated by a new statement and the constructor parameter contains an uncontrollable variable, then it is marked as uncontrollable. If a variable receives a method return value, then its controllability weight is determined by the controllability of the return value of the called method. If a variable is assigned a value through field loading or storage operations, then the controllability of the base object and whether the field access path meets the constraints must be verified.

[0090] S400: Stores the optimized code attribute graph in a graph database, traverses the call chain from bottom to top based on controllability conditions, and identifies the exploitable deserialization call chain from the deserialization entry point to the dangerous method.

[0091] Step S400 includes S401, S402, and S403:

[0092] S401: A predefined set of security-sensitive endpoints, such as Runtime.exec() and ProcessBuilder.start(), are used to label the corresponding method nodes with vulnerability trigger tags (SINK) in the graph database.

[0093] S402: Starting from all SINK nodes, backtrack along the call chain to the deserialization entry method based on the pruned context-sensitive code attribute graph. If the variable node in the current path is marked as uncontrollable (weight = ∞) or the path depth exceeds the preset threshold, the branch traversal is terminated.

[0094] S403: For the complete path that successfully backtracks to the deserialization entry point, extract its method call sequence and associated data stream to form a complete deserialization call chain.

[0095] In summary, this invention discloses a Java deserialization vulnerability detection method. The method includes: extracting semantic information from the Java program through static analysis and constructing a code attribute graph; combining class inheritance relationships, polymorphic call bindings, and context-sensitive method call graphs to accurately characterize the program structure; employing an edge pruning optimization strategy to process field storage and loading statements, removing redundant data flow edges and generating direct edges to simplify the call graph; dynamically evaluating the controllability weights of method parameters and return values ​​based on a controllability analysis algorithm, and pruning unreachable paths; and finally, quickly locating the complete call chain from the deserialization entry point to the dangerous method through bottom-up reverse traversal of the graph database. This method effectively suppresses path explosion through edge pruning optimization, improves call chain accuracy through context-sensitive analysis, and achieves a balance between efficiency and coverage through a controllable dynamic pruning strategy. It overcomes the limitations of traditional static detection methods in complex polymorphic call scenarios, providing reliable technical support for efficient detection and risk prevention of deserialization vulnerabilities in the Java open-source ecosystem, and has significant application value for improving enterprise-level software security protection capabilities.

Claims

1. A method for detecting Java deserialization vulnerabilities, comprising: Extract semantic information from the target Java program, including class inheritance relationships, method signatures, and interface implementations, and generate an intermediate representation; Based on the semantic information, a code attribute graph is constructed, including: a class relationship graph, representing the subordinate and inheritance relationships between classes and methods; a polymorphic call graph, linking all implementation paths of polymorphic methods; and a context-sensitive method call graph, which uses an edge pruning optimization algorithm to process field storage and loading statements, removes redundant edges that cause data flow merging, and generates a simplified call graph. Perform controllability analysis on the context-sensitive method call graph, evaluate the controllability of method parameters and return values, prune unreachable paths, and generate an optimized code attribute graph. Store the optimized code attribute graph in a graph database, and traverse the call chain from bottom to top based on controllability conditions to identify the exploitable deserialization call chain from the deserialization entry point to the dangerous method.

2. The method according to claim 1, characterized in that, The extraction of semantic information from the target Java program specifically includes: Use static analysis tools to parse Java bytecode and extract class inheritance relationships, method signatures, and interface implementation relationships; The extracted semantic information is converted into an intermediate representation, which includes class method call relationships, field access operations, and control flow graphs.

3. The method according to claim 1, characterized in that, The construction of the code attribute graph based on semantic information specifically includes: A class relationship graph is constructed based on the intermediate representation. The class relationship graph represents the subordinate relationship, inheritance relationship and interface implementation relationship between classes and methods through directed edges. Identify all polymorphic method declarations in a Java program, including interface methods, abstract class methods, and method overriding scenarios. Traverse class inheritance relationships, dynamically bind and associate polymorphic method declarations with all concrete implementation methods, create call edges for each polymorphic method in the polymorphic call graph, and link parent class or interface method declarations to subclass implementation methods. Traverse the method control flow graph, identify all field storage statements and field loading statements, perform edge pruning and expansion optimization, and generate a context-sensitive method call graph.

4. The method according to claim 1, characterized in that, The method includes the following optimizations for edge pruning and expansion of field storage statements: The method traverses the control flow graph, identifies operation patterns such as field storage statements i:af=b, and triggers pruning operations when the following conditions are met: (1) Both the base object a and the stored value b are directly derived from the call point parameters of method m; (2) a and b were not reassigned within method m; If the above conditions are met, remove the original edge generated by the stored statement from the pointer flow graph (PFG). For each triple in temporary storage<tar,f,src> If any of the following conditions are met, a new direct edge is generated and added to addEdges: (1) tar or src is redefined within the method. (2) tar or src is not fully mapped to the call point parameters.

5. The method according to claim 1, characterized in that, The method includes the following edge pruning and expansion optimization for field loading statements: Traverse the method control flow graph, identify operation patterns such as field loading statements like `i:tar=src.f`, and trigger pruning operations when the following conditions are met: (1) The base object a is directly derived from the call point parameter of method m and src is not reassigned in method m; (2) The target variable tar of the field loading statement comes from the return value variable of method m; If the above conditions are met, remove the original edge generated by the loading statement from the pointer flow graph; For each triple in the temporary loading<tar,src,f> If the set of objects pointed to by the base object src contains a specific object o i Then generate from o i The direct edge from .f to the target variable tar.

6. The method according to claim 1, characterized in that, The controllability analysis of the context-sensitive method call graph specifically includes: Perform controllability state initialization by assigning controllability weights to variables, the weights being defined as follows: (1) Weight = ∞: indicates that the parameter is uncontrollable; (2) Weight = 0: This means that it can be directly controlled, and the parameter may come from external input; (3) Weight = [1, n]: represents the weight that depends on the nth method parameter; Process each statement in the control flow graph. If a variable is directly assigned a value by a controllable variable, it inherits the controllability weight. If a variable is instantiated using the `new` statement and the constructor parameter contains an uncontrollable variable, it is marked as uncontrollable. If a variable receives a method return value, its controllability weight is determined by the controllability of the returned value of the called method. If a variable is assigned a value through field loading or storage operations, it is necessary to verify the controllability of the base object and whether the field access path meets the constraints.

7. The method according to claim 1, characterized in that, The method further includes: A predefined set of security-sensitive endpoints is used to label the corresponding method nodes with the vulnerability trigger tag SINK in the graph database. Starting from all SINK nodes, the traversal is based on the context-sensitive code attribute graph after pruning, and backtracks along the call chain to the deserialization entry method. If the variable node in the current path is marked as uncontrollable, i.e., the weight is ∞ or the path depth exceeds the preset threshold, the branch traversal is terminated. For the complete path that successfully backtracks to the deserialization entry point, extract its method call sequence to form a complete deserialization call chain.

Images