A concurrent vulnerability detection method based on code concurrent attribute graph

Abstract

The application provides a concurrent vulnerability detection method based on code concurrent property graph, adopts a vulnerability detection tool CONCODEQL; S1, code property graph is initialized according to source code and key nodes are identified; S2, concurrent relationship is constructed by traversing the initial graph; S3, concurrent violation is detected according to the designed domain-specific language.The application can comprehensively express various relationships and characteristics in the concurrent program source code by introducing CCPG, and overcomes the deficiency that the existing static code detection method based on structured representation is difficult to identify complex concurrent vulnerabilities.The domain-specific language based on CCPG supports detection of different types of concurrent vulnerabilities, and improves the expansibility of the tool.By combining the capability of CCPG, the false positive and false negative rates of the traditional data race detection method are effectively reduced, and the detection capability for complex concurrent problems is enhanced.

Description

TECHNICAL FIELD

[0001] The application provides a concurrent vulnerability detection method based on code concurrent attribute graph, and belongs to the technical field of computer software security. BACKGROUND

[0002] In order to improve the performance of software, more and more concurrent programming models are introduced into modern software applications, and these concurrent programs can make full use of multi-core CPUs to accelerate computation and significantly improve execution speed. However, the interleaved execution of threads in concurrent programs introduces considerable uncertainty, which can lead to many vulnerabilities specific to this environment, and this uncertainty makes it difficult to detect and fix these vulnerabilities. In view of the above background, a large number of research works are devoted to detecting various vulnerabilities in concurrent programs. Researchers have explored the detection of data races, synchronization errors (such as deadlocks and unreleased locks), memory-related vulnerabilities in concurrent scenarios (such as double-free and use-after-free vulnerabilities), etc. Overall, there are great differences in the detection methods for different types of vulnerabilities. Data race detection mainly focuses on unsafe access to shared memory, while synchronization error detection emphasizes the correctness of synchronization logic.

[0003] From a technical point of view, many researchers have focused on dynamic analysis methods, which combine testing with formal reasoning to report concurrent errors by tracking all possible valid reorderings under different program inputs. Due to the limitation of exhaustive computation complexity, many partial order-based techniques have emerged, and many current works are devoted to constructing efficient and computable weak partial orders. Although these methods can accurately detect concurrent bugs, they all have the natural defects of dynamic analysis: significant performance overhead and limited coverage.

[0004] In contrast, there are relatively few static analysis tools available for detecting concurrency errors. Notable tools in this field include RacerD and Coderrect, both of which mainly focus on data races and detect them by analyzing the access patterns of shared variables. The main challenge compared to sequential program analysis is to analyze memory access in concurrent scenarios and determine the parallel relationship between statements. In terms of memory access analysis, traditional methods use data flow analysis to capture the semantics within and between threads, and later, to improve accuracy and reduce overhead, pointer analysis is used for memory access analysis, which is mostly based on value flow graphs. In terms of parallel relationship analysis, it mainly includes lockset-based work and static transitive relationship work. Lockset-based methods, such as Locksmith, detect concurrent vulnerabilities by determining whether all accesses to shared locations are always protected by locks. Static transitive relationship represents the program as an abstract graph of threads to determine the parallel relationship between nodes. The most advanced methods usually combine these two techniques to more accurately determine the parallel relationship between statements.

[0005] Some general-purpose static analysis tools also support concurrent error detection, such as CodeQL and Joern. These tools first convert the source code into a structured representation (i.e., relational data or graphs), save them to a database, and then use domain-specific languages to query the database. This mechanism allows the definition of complex error detection patterns that can be queried in the database.

[0006] CodeQL is an advanced static code analysis tool developed by GitHub, widely used for security checks and vulnerability research. Its core idea is to treat code as data, by converting code repositories into queryable databases, developers can write queries to detect security vulnerabilities, potential bugs, and other quality issues in the code. Although CodeQL performs well in detecting general security vulnerabilities and logical defects, it is not mature in detecting concurrent errors (such as race conditions, deadlocks). The fundamental reason is that the code property graph relied on by CodeQL cannot fully express concurrent relationships. The core data representation of the code property graph mainly focuses on the syntax structure and control / data flow of the code, and cannot directly model threads, locks and their interaction behaviors. The detection of concurrent errors usually needs to model the following problems in depth:

[0007] Synchronization and communication between threads: such as lock acquisition and release, use of semaphores, etc.

[0008] Race condition: multiple threads access shared resources simultaneously and the access order affects the program results.

[0009] Deadlock: different threads enter a mutual waiting state due to resource competition.

[0010] Due to the lack of direct representation of the above concurrent semantics in the code property graph, the analysis ability of CodeQL is limited in this type of problem. Although CodeQL's functionality can be extended through additional logic and rules, its native capabilities are not optimized for concurrent problems. This means that CodeQL's detection ability for concurrent errors is weak, with low recall and accuracy.

[0011] Coderrect is a static analysis tool designed specifically for concurrent program design, aiming to help developers identify concurrent problems in the code, especially data races. It supports mainstream concurrent programming interfaces such as OpenMP, Pthreads and C++ standard thread library, and uses static analysis techniques to quickly find and solve potential problems in the development stage.

[0012] Although Coderrect is very strong in detecting data races, it has limitations in that it only focuses on this type of problem. For other concurrent error types (such as deadlock, livelock, race condition) and concurrent-related vulnerabilities, Coderrect does not provide support. This means that it cannot cover all potential risks in concurrent programming, and developers may need to combine other tools for more comprehensive analysis. SUMMARY

[0013] The present application is directed to the detection of concurrent programs, aiming to propose a concurrent vulnerability detection technology based on code concurrent property graph, aiming to solve the limitations of existing work in poor scalability and low accuracy, realize a more general and mature concurrent vulnerability detection tool, and thus improve the security of software.

[0014] Specifically, the main problems to be solved include:

[0015] (1) The existing static code detection method based on structured representation lacks the representation of the characteristics of concurrent programs, making it difficult to identify complex concurrent vulnerabilities. The present application proposes CCPG (Code Concurrent Property Graph), which can effectively express various relationships and characteristics in the source code of concurrent programs;

[0016] (2) Existing concurrent vulnerability detection tools have poor scalability and can only target specific vulnerabilities or certain vulnerabilities. The present application designs a domain-specific language based on CCPG for detecting different types of vulnerabilities;

[0017] (3) Traditional data race detection methods lack comprehensive analysis of various syntax relationships, memory access patterns, and concurrent mechanisms in source code, resulting in false positives and false negatives. The present application designs a domain-specific language based on CCPG for defining complex concurrent rules, thereby enhancing the identification of subtle concurrent problems that may be overlooked by traditional tools.

[0018] The complete technical solution provided by the present application:

[0019] A concurrent vulnerability detection method based on code concurrent property graph, using the vulnerability detection tool CONCODEQL. Including the following processes: initializing the code property graph and identifying the key nodes according to the source code, traversing the initial graph to build concurrent relationships, and detecting concurrent violations according to the designed domain-specific language.

[0020] S1, initialize the code property graph and identify the key nodes according to the source code. Based on the source code to be tested, initialize the code concurrent property graph CCPG based on the traditional code property graph (CPG) and value flow graph (VFG), and identify the key nodes in the concurrent program in the graph.

[0021] S2, traverse the initial graph to build concurrency relations. Traverse the initialized graph, build context information, and perform flow-sensitive hapeens-before analysis, inter-process lockset analysis, and enhanced concurrent pointer analysis based on the context to build concurrency relations of nodes in the graph.

[0022] S3, detect concurrency violations according to the designed domain-specific language. Design domain-specific language query APIs for different types of concurrency vulnerabilities, query in the graph to detect concurrency violations, and further design domain-specific language queries for some complex judgments. Finally, print the detected concurrency vulnerabilities into a report.

[0023] The details of the above steps are described below.

[0024] S1, initialize the code property graph and identify key nodes according to the source code;

[0025] CONCODEQL first generates a code property graph and a value flow graph according to the source code, identifies concurrent-related APIs from the code property graph, and defines a code concurrency property graph (CCPG) for concurrent programs in combination with the information obtained from the value flow.

[0026] The nodes of the code concurrency property graph include the following three types:

[0027] 1. Memory access nodes: These nodes are used to represent memory access in the code;

[0028] 2. Concurrency behavior nodes: These nodes correspond to concurrency behavior-related APIs in the source code, which are further divided into two subcategories: thread organization nodes, including FORK nodes, JOIN nodes, DETACH nodes, and EXIT nodes; and synchronization logic nodes, including lock acquisition nodes (ACQUIRE) and lock release nodes (RELEASE).

[0029] 3. Other nodes: Nodes representing the basic running logic of the program.

[0030] The edges of the code concurrency property graph are divided into two categories: regular code property graph edges (abstract syntax tree edges, control flow edges, and dependency edges) and concurrency relation edges, which can be divided into two categories:

[0031] 1. Thread lifecycle edges: including edges from FORK nodes to corresponding thread entrances, and edges from thread exits to JOIN nodes.

[0032] May-Happens-Parallel Edges: Connect nodes from different threads that may occur in parallel. To simplify, CONCODEQL only connects nodes that access the same memory location.

[0033] S2, traversing the initial graph to build concurrency relations;

[0034] Perform thread-aware and flow-sensitive analysis.

[0035] Thread-aware context is defined as: for a given node, every path from the main entry to the node including all ancestor threads and the current thread. Thus the thread-aware context along a specific path is denoted as c=[n1, n2,..., n m ], where each element represents a concurrent behavior node, and a node n i All thread-aware contexts are denoted as a two-dimensional matrix k represents the number of paths from the main entry to the current node.

[0036] Then, the flow-sensitive happens-before analysis is performed, i.e. to build happens-before edges based on thread-aware contexts. The main purpose of the analysis is to infer the execution order between two nodes n i and n j . For a given node n i , first construct a fork set for each of its thread-aware contexts The fork set is defined as i.e. only consists of the FORK nodes that the corresponding thread in the current context has not JOINed. To analyze the happens-before relation between n i and n j , CONCODEQL checks whether their fork sets overlap each other. Overlapping fork sets mean that the two nodes n i and n j can occur in parallel. Formally, the hp relation between n i and n j is judged by the following formula:

[0037]

[0038] Then, the inter-procedural lock set analysis is performed. The analysis of happens-before relation is not enough to determine whether two nodes can execute concurrently, because nodes can be protected by locks. Given two nodes n i and n j , the main purpose of the lock set analysis is to infer whether n i and n j are protected by the same lock. To do this, given a node ni CONCODEQL first constructs lock sets for each of its thread-aware contexts A lock set is defined as denotes consists of only the lock acquisition nodes whose corresponding locks have not been released in the current context. Then, CONCODEQL determines whether n i and n j are protected by the same lock by checking whether their lock sets overlap. Formally, the psl relationship between n i and n j is judged by the following formula:

[0039]

[0040] After that, the on-demand pointer analysis for concurrency enhancement is performed:

[0041] (1) Global variables: By analyzing the CCPG and the value flow graph, an accurate analysis of global variables is designed. First, all global variable declarations are identified by traversing the CCPG, resulting in a global variable set. Then the connections between global variables and local variables are reconstructed in the VFG, and global variable aliases are determined by flow-sensitive pointer analysis.

[0042] (2) Structures: For structure s access nodes, the specific attributes accessed by the node are obtained simply by CPG using regular expression judgment. CONCODEQL analyzes CCPG and VFG simultaneously and adjusts the structure representation to specific attributes in pointer analysis.

[0043] The concurrent analysis feature algorithm, i.e., how to implement thread-aware flow-sensitive analysis. The algorithm first needs to traverse the initial CCPG and construct a thread-aware context for each node. Specifically, CONCODEQL first obtains all main entry nodes from the CCPG and initializes their contexts as empty. In the main loop, if the current node with the current context is accessed, CONCODEQL will directly terminate the loop. Otherwise, CONCODEQL will traverse the CCPG along the thread lifecycle edges and control flow edges. If the current node n is a FORK node that creates a new thread, the context of the entry node n' of the new thread will be initialized as each context previously added to node n, and a new thread t newIf the current node n is not a FORK node, it just traverses along the control flow edges and propagates the context of the current node to the successor nodes. The context constructed for each node is then used for the subsequent happens-before relationship and lockset analysis. CONCODEQL then traverses any pair of threads and checks if their memory access nodes can happen in parallel based on the context of each node. Specifically, if two nodes n i and n j satisfy the following conditions: 1) access the same memory location; 2) can happen in parallel; 3) are not protected by the same lock, CONCODEQL adds a HP edge (Happens-ParallelEdge) between the pair of nodes (n i , n j ). Finally, the algorithm generates an updated graph CCPG.

[0044] S3, detecting concurrency violations according to the design;

[0045] Concurrency errors are classified into data races, deadlocks, atomicity errors, and order conflicts.

[0046] A domain-specific language is defined as a syntax L = {V T , V N , P, S}, where V T is a set of terminal symbols, V N is a set of non-terminal symbols, and the set of production rules P constitutes the main structural units of the syntax, each production rule p i is represented as a::=β, which describes the method of combining elements in the set of terminal symbols and the set of non-terminal symbols into a string, and S is the start symbol.

[0047] The domain-specific language is designed by using and extending the query statements used in the CodeQL domain-specific language. In this structure, <query> <condition>Defining constraints in queries; <returns>The specified query returns the value.

[0048] The language's specialization for the concurrent domain is reflected in the structure <built-in type> and <concurrent_relation_condition>. <concurrent_relation_condition> contains <access_condition>, <hb_relationship> and <lock_condition>, which deal with thread-aware pointer analysis, happens-before relationship and lockset analysis, respectively. Specifically, the analysis of locks includes the IS PROTECTED BY and IS AUTOMATICALLY PROTECTED BY methods, the former determines whether two variables are protected by the same lock, and the latter checks whether the operations are within the same critical section to ensure atomicity. These syntax features enhance the language's ability to detect a large number of concurrency errors.

[0049] The present application provides a concurrent vulnerability detection technology based on code concurrent property graph (CCPG), which has remarkable beneficial effects. First, by introducing CCPG, the present application can fully express various relationships and characteristics in the source code of concurrent programs, overcoming the shortcomings of existing static code detection methods based on structured representation in identifying complex concurrency vulnerabilities. Second, the present application designs a domain-specific language based on CCPG, which supports detection of different types of concurrency vulnerabilities, greatly improving the tool's extensibility and enabling it to adapt to a wider range of application scenarios. Finally, by combining the capabilities of CCPG, the domain-specific language of the present application can comprehensively analyze the syntax relationships, memory access patterns and concurrency mechanisms in the source code, effectively reducing the false positive and false negative rates of traditional data race detection methods, and enhancing the detection capability of complex concurrency problems. Overall, the present application provides a technical foundation for developing more general and mature concurrent vulnerability detection tools, significantly improving the security and reliability of software. BRIEF DESCRIPTION OF DRAWINGS

[0050] Figure 1 The overall workflow diagram of CONCODEQL of the present application;

[0051] Figure 2 The thread-aware analysis example of the embodiment

[0052] Figure 3 The thread-aware context construction method flowchart of the embodiment;

[0053] Figure 4 The main framework diagram of the domain-specific language (domain-specific language) of the embodiment

[0054] Figure 5 A screenshot of a concurrency-specific component of a domain-specific language for the embodiment;

[0055] Figure 6 A screenshot of a query example of data race detection for the embodiment. DETAILED DESCRIPTION

[0056] The present application provides a concurrent vulnerability detection method based on code concurrency property graph, which adopts a vulnerability detection tool CONCODEQL. The core workflow framework of the application is shown in Figure 1 CONCODEQL mainly includes three processes: initializing code property graph and identifying key nodes according to source code, traversing the initial graph to build concurrency relationship, and detecting concurrency violations according to the designed domain-specific language.

[0057] S1, initializing code property graph and identifying key nodes according to source code. Based on the source code to be tested, on the basis of traditional code property graph (CPG) and value flow graph (VFG), code concurrency property graph (CCPG) is initialized, and the key nodes in the concurrent program in the graph are identified.

[0058] S2, traversing the initial graph to build concurrency relationship. Traversing the initialized graph, context information is built, and based on the context, flow-sensitive hapeens-before analysis, inter-process lock set analysis, and enhanced concurrent pointer analysis are sequentially performed, and the concurrency relationship of the nodes in the graph is built.

[0059] S3, detecting concurrency violations according to the designed domain-specific language. Domain-specific language query API is designed for different types of concurrent vulnerabilities, and query is performed in the graph to detect concurrency violations, and further, domain-specific language query is designed for some complex judgments, and finally the detected concurrent vulnerabilities are printed into a report.

[0060] The details of the above steps are described in detail below.

[0061] S1, initializing code property graph and identifying key nodes according to source code;

[0062] CONCODEQL first generates code property graph and value flow graph according to source code, identifies concurrent related API from the code property graph, and defines code concurrency property graph (CCPG) for concurrent program in combination with the information obtained from the value flow.

[0063] The nodes of the code concurrency property graph include the following three kinds:

[0064] 4. Memory access nodes: These nodes are used to represent the memory access in the code, which can be used by the concurrency mechanism for thread synchronization, communication, scheduling, etc. These nodes correspond to four behaviors in the source code: address allocation (ALLOC), address release (FREE), read variable (READ), and write variable (WRITE).

[0065] 5. Concurrency behavior nodes: These nodes are the most important nodes in the CCPG and are one of the main differences from the conventional CPG. These nodes correspond to the concurrency behavior related API in the source code, which are further divided into two subcategories: thread organization nodes, including the FORK node, JOIN node, DETACH node, and EXIT node; and synchronization logic nodes, including the lock acquisition node (ACQUIRE) and lock release node (RELEASE).

[0066] 6. Other nodes: These nodes represent the basic running logic of the program, such as assignment nodes, branching nodes, call nodes, function nodes, and return nodes.

[0067] The edges of the code concurrency property graph are divided into two categories: conventional code property graph edges (abstract syntax tree edges, control flow edges, and dependency edges) and concurrency relationship edges, which can be divided into two categories:

[0068] 2. Thread-lifecycle edges: These edges are crucial for establishing the execution order in concurrent operations, including the edges from the FORK node to the corresponding thread entry and the edges from the thread exit to the JOIN node.

[0069] May-happens-parallel edges: These edges connect nodes from different threads that can occur in parallel. To simplify, CONCODEQL only connects nodes that access the same memory location.

[0070] S2. Traverse the initial graph to build concurrency relationships;

[0071] To build the may-happen-parallel edges, the invention performs thread-aware and flow-sensitive analysis. Flow-sensitive analysis is a technique in static program analysis that considers the execution order of statements or instructions in a program. In addition, thread-aware flow-sensitive analysis not only considers the flow but also considers the concurrency aspects of the program, such as thread synchronization, shared resources, and potential race conditions.

[0072] Thread-aware analysis has been applied to pointer analysis in concurrent programs by certain works, but the method of applying thread-aware flow-sensitive analysis to statically determine concurrency relationships has not been studied.

[0073] The present application firstly defines a thread-aware context as: for a given node, each path from the main entry to the node including all ancestor threads and the current thread. Thus the thread-aware context along a specific path can be denoted as c=[n1, n2,..., n m ], where each element represents a concurrent behavior node, a node n i All thread-aware contexts can be denoted as a two-dimensional matrix k represents the number of paths that can be executed from the main entry to the current node. Figure 2 A simplified example of a concurrent program is given, in which x is a global variable, the main function creates two threads t1 and t2, and each of the two threads contains a write(x) statement, then the thread-aware context of t1:write(x) is [fork(t1, call), acquire_lock(1)], and the thread-aware context of t2:write(x) is [fork(t1, call), join(t1), fork(t2, call), acquire_lock(1)].

[0074] Then the flow-sensitive happens-before analysis is performed, that is, the happens-before edges are constructed based on the thread-aware context, and the main purpose of the analysis is to deduce the execution order between two nodes n i and n j . For a given node n i , the present application firstly constructs a fork set for each thread-aware context of it. That is only composed of the FORK nodes that the corresponding thread in the current context has not JOINed. In order to analyze the happens-before relationship between n i and n j , the CONCODEQL checks whether the fork sets of them exist mutual overlap (there is at least one common element), and the overlapable fork sets mean that the two nodes n i and n j may occur in parallel. Formally, the present application uses the following formula to judge the hp (happen in parallel) relationship between n i and n j :

[0075]

[0076] Then inter-procedural lockset analysis is performed, which is insufficient to determine whether two nodes can be executed concurrently because nodes can be protected by locks. Given two nodes n i and n j , the main purpose of lockset analysis is to infer whether n i and n j are protected by the same lock. To this end, given a node n i , CONCODEQL first constructs a lockset L(n ) for each thread-aware context of n . The lockset is defined as which means only consists of nodes acquired by the corresponding lock that has not been released in the current context. Then, CONCODEQL determines whether n i and n j are protected by the same lock by checking whether the locksets overlap each other. Formally, CONCODEQL judges the psl (protected by the same lock) relationship between n i and n j using the following formula:

[0077]

[0078] After that, the on-demand pointer analysis for concurrency enhancement is performed. Pointer analysis is a key aspect of static analysis. Existing methods aim to address the unique challenges brought by concurrent environments, especially a flow-sensitive multithreaded pointer analysis method is proposed based on the Sparse Value Flow (SVF) framework. Although it has made some progress, the present invention observes that existing methods have some limitations in handling global variables and structures, so the present invention makes targeted improvements:

[0079] (1) Global variables: Global variables are an important part of shared memory in concurrent programs. However, when using advanced pointer analysis tools such as SVF-Tool to analyze more complex programs, errors often occur when analyzing global variables, which may be due to the inherent insensitivity of LLVM to global variables. To solve this problem, the present invention designs an accurate analysis of global variables by analyzing CCPG and value flow graphs. First, the present invention identifies all global variable declarations by traversing the CCPG, thereby obtaining a global variable set. Then the present invention reconstructs the connection between global variables and local variables in the VFG, and determines global variable aliases through flow-sensitive pointer analysis. This method uses the information provided by the CPG to significantly enhance the analysis capability of global variables.

[0080] (2) Struct: It is well known that pointer analysis has poor support for accessing struct fields, and existing methods can accurately analyze accesses to struct variable pointers, but they have difficulty determining which specific field of a struct is being accessed. This problem can be effectively solved by using CPGs. For a struct s, the invention can use some regular expressions to determine which field is accessed by a node, such as s->a or s.b, which allows the invention to distinguish between a pointer to s and a pointer to s->a. Therefore, similar to the method for processing global variables, CONCODEQL simultaneously analyzes CCPG and VFG, and adjusts the representation of struct in pointer analysis to the specific field, which helps the invention significantly improve the accuracy of pointer analysis.

[0081] Finally, the overall concurrent analysis feature algorithm of the invention, i.e., how thread-aware flow-sensitive analysis is implemented, is described. The algorithm first needs to traverse the initial CCPG and construct a thread-aware context for each node, as shown in Figure 3 Specifically, CONCODEQL first obtains all the main entry nodes from CCPG and initializes their contexts as empty. In the main loop, if the current node with the current context is accessed (nodes with different contexts can be accessed multiple times), CONCODEQL will directly terminate the loop. Otherwise, CONCODEQL will traverse CCPG along thread lifecycle edges and control flow edges, and if the current node n is a FORK node that creates a new thread, the context of the entry node n' of the new thread will be initialized as each context previously added to node n, and a new thread t new If the current node n is not a FORK node, it only traverses along the control flow edge and propagates the context of the current node to the subsequent node. The context constructed for each node is then used for subsequent happens-before relationship and lock set analysis. Then, based on the context of each node, CONCODEQL traverses any pair of threads and checks whether their memory access nodes can occur in parallel. Specifically, if two nodes n i and n j satisfy the following conditions simultaneously: 1) access the same memory location; 2) can occur in parallel; 3) are not protected by the same lock, CONCODEQL will add a HP edge (May-Happens-ParallelEdge) between the node pair (n i , n j ). Finally, the algorithm generates an updated graph CCPG.

[0082] S3, detecting concurrent violations according to the design;

[0083] Concurrency errors are roughly categorized into data races, deadlocks, atomicity errors, and order violations. While there are many tools to detect data races and deadlocks, there is less work to address atomicity and order violations due to the complex relationships and rules among APIs, which often require extensive pattern mining or document understanding. Domain-specific languages can effectively address these challenges, enabling users to flexibly define atomic operations and relationships among APIs, thus facilitating effective detection of atomicity and order errors. The present invention defines a domain-specific language to provide formalized descriptions for queries on CCPG, aiming to cover all types of concurrency errors.

[0084] The domain-specific language is defined as a grammar L = {V T ,V N , P, S}, where V T is a set of terminal symbols, V N is a set of non-terminal symbols, and the set of production rules P constitutes the main structural units of the grammar. Each production rule p i is represented as a::=β, describing the method of combining elements in the set of terminal symbols and the set of non-terminal symbols into a string, and S is the start symbol.

[0085] The main architecture of the domain-specific language is shown in Figure 4 The domain-specific language is designed by using and extending the query statements used in the CodeQL domain-specific language. In this structure, <query>The starting symbol S in the definition serves as the entry point for the domain-specific language.<var_delcs> This indicates variable declaration, including basic variable types and built-in variable types. <built-intype> ； <condition>Defining constraints in queries; <returns>The specified query returns the value.

[0086] The language's specialization for the concurrency domain is reflected in the structure <built-intype>and <concurrent_relation_condition>. Figure 5 These concurrency component-specific designs are shown. The <concurrent_relation_condition> contains <access_condition>, <hb_relationship> and <lock_condition>, which deal with the thread-aware pointer analysis, happens-before relationship and lockset analysis mentioned above, respectively. Specifically, the lock analysis includes IS_PROTECTED_BY and IS_AUTOMATICALLY_PROTECTED_BY methods, the former determines whether two variables are protected by the same lock, and the latter checks whether the operations are within the same critical section to ensure atomicity. These syntax features enhance the ability of the domain-specific language to detect a large number of concurrency errors.

[0087] The query statement for data race detection is shown in Figure 6 In this example, MEM_ACCESS, CONTEXT and LOCK are built-in classes, MEM_ACCESS corresponds to a memory access node, and CONTEXT and LOCK represent the results of thread-sensitive context analysis and lockset analysis, respectively. The ALIAS operation is used to determine whether two memory access nodes are pointer aliases in the context. In addition, in order to be consistent with the definition of data race, the present application adds a condition that the memory access nodes cannot be of the READ type at the same time. In addition, the use of HAPPENS_BEFORE and PROTECTED_BY can ensure that the two memory access nodes can be executed concurrently, i.e., are not effectively protected by a lock.

[0088] The present application uses Joern version 1.6 as a tool when generating CPG, and this CPG generation tool can be replaced by other versions or other tools according to actual needs.

[0089] The present application uses SVF-Tool as a pointer analysis tool, and this pointer analysis tool can be replaced by other versions or other tools according to actual needs. < / returns> < / condition> < / built-intype> < / query> < / returns> < / condition> ​< / query>

Claims

1. A concurrent vulnerability detection method based on code concurrent property graph, characterized in that, adopting a vulnerability detection tool CONCODEQL; comprising the following process: S1, initializing code property graph and identifying key nodes according to source code; based on the source code to be tested, on the basis of traditional code property graph CPG and value flow graph VFG, initializing code concurrency property graph CCPG, and identifying the key nodes in the concurrent program in the graph; S2, traversing the initial graph to build concurrency relationship; traversing the initialized graph, building context information, and based on the context, sequentially performing flow-sensitive happens-before analysis, inter-process lock set analysis, and enhanced concurrent pointer analysis, to build the concurrency relationship of the nodes in the graph; performing thread awareness and flow-sensitive analysis; performing thread awareness: Firstly, the thread-aware context is defined as: for a given node, every path from the main entry to the node including all ancestor threads and the current thread; thus the thread-aware context along a specific path is denoted as c = [n1, n2,..., n m ], where each element represents a concurrent behavior node, a node n i All thread-aware contexts are denoted as a two-dimensional matrix k represents the number of paths that can be executed from the main entry to the current node; Then, a flow-sensitive happens-before analysis is performed, i.e., the happens-before edges are constructed based on thread-aware contexts. The main purpose of the analysis is to infer the execution order between two nodes n i and n j ; for a given node n i , first, a fork set is constructed for each of its thread-aware contexts A fork set is defined as i.e. only consists of the FORK nodes that the corresponding thread in the current context has not JOINed yet; to analyze the happens-before relationship between n i and n j , CONCODEQL checks whether their fork sets overlap each other. Overlapping fork sets imply that the two nodes n i and n j can occur in parallel; the hp relationship between n i and n j is judged by the following formula:​ Then inter-procedural lockset analysis is performed, which is not sufficient to determine whether two nodes can execute concurrently, because nodes can be protected by locks; given two nodes n i and n j , the main purpose of lockset analysis is to infer whether n i and n j are protected by the same lock; given a node n i , CONCODEQL first constructs a lockset for each thread-aware context of it The lockset is defined as denotes the set of lock acquisition nodes only by the corresponding lock in the current context that has not been released yet; then, CONCODEQL determines whether n i and n j are protected by the same lock by checking whether the locksets overlap each other; the psl relationship of n i and n j is judged by the following formula: then performing concurrent enhanced on-demand pointer analysis: (1) global variables: through analyzing CCPG and value flow graph, an accurate analysis of global variables is designed; first, all global variable declarations are identified by traversing CCPG, so as to obtain the global variable set; then the connection between global variables and local variables is rebuilt in VFG, and the global variable alias is determined through flow-sensitive pointer analysis; (2) structure: for the access node of structure s, the specific attribute accessed by the node is obtained simply through CPG using regular expression judgment, CONCODEQL analyzes CCPG and VFG at the same time, and adjusts the structure representation to the specific attribute in pointer analysis; thread-aware flow-sensitive analysis: first, the initial CCPG needs to be traversed, and the thread-aware context is constructed for each node; CONCODEQL first obtains all main entry nodes from CCPG, and initializes the context of the nodes as empty; In the main loop, if the current node with the current context is accessed, CONCODEQL will directly terminate the loop; otherwise, CONCODEQL will traverse the CCPG along the thread life cycle edges and the control flow edges, and if the current node n is a FORK node that creates a new thread, the context of the entry node n' of the new thread will be initialized as each context that is previously added to the node n, and a new thread t is created new ; if the current node n is not a FORK node, it only traverses along the control flow edge, and propagates the context of the current node to the subsequent node; then the context constructed for each node is used for subsequent happens-before relationship and lock set analysis; Then based on the context of each node, CONCODEQL traverses any pair of threads and checks whether their memory access nodes can happen in parallel; specifically, if two nodes n i and n j satisfy the following three conditions simultaneously: 1) access the same memory location; 2) can happen in parallel; 3) are not protected by the same lock, CONCODEQL will add a HP edge between the pair of nodes (n i ,n j ); finally, the algorithm generates an updated graph CCPG; S3, detecting concurrent violations according to the designed domain-specific language; for different types of concurrent vulnerabilities, a domain-specific language query API is designed, which is used for query in the graph to detect concurrent violations, and finally the detected concurrent vulnerabilities are printed into a report.

2. The method of claim 1, wherein, S1, the specific method is: CONCODEQL first generates code property graph and value flow graph according to source code, identifies concurrent related API from code property graph, and defines code concurrency property graph CCPG for concurrent program in combination with the information obtained from value flow; The nodes of code concurrency property graph include the following three kinds: (1) memory access node: this kind of node is used to represent the access to memory in the code; (2) concurrent behavior node: this kind of node corresponds to the API related to concurrent behavior in the source code, which is further divided into two subcategories: thread organization node, including FORK node, JOIN node, DETACH node and EXIT node; synchronization logic node, including lock acquisition node ACQUIRE and lock release node RELEASE; (3) other nodes: nodes representing the basic running logic of the program; The edges of a code concurrent property graph are divided into two categories, regular code property graph edges and concurrent relation edges, which are further divided into two categories: (1) Thread life cycle edges: edges from a FORK node to the corresponding thread entry and edges from a thread exit to a JOIN node; (2) Possibly parallel edges: edges connecting nodes from different threads that may occur in parallel. CONCODEQL only connects nodes that access the same memory location for simplicity.

3. The method of claim 1, wherein, S3 specifically: A domain-specific language is defined as a grammar L = {V T ,V N ,P,S} where V T is a set of terminal symbols, V N is a set of non-terminal symbols, the set of production rules P constitutes the main structural units of the grammar, each production rule p i is represented as a: : = β, describing a way of combining elements from the set of terminal symbols and the set of non-terminal symbols into a string, and S is the start symbol; Domain-specific languages are designed by using and extending the query statements used in CodeQL domain-specific languages; in this structure, <query>The starting symbol S in the definition serves as the entry point for the domain-specific language.<var_delcs> This indicates variable declaration, including basic variable types and built-in variable types. <built-intype> ； <condition>Defining constraints in queries; <returns>specifies the values returned by the query;< / returns> < / condition> < / built-intype> < / query> The language specificity to the concurrent domain is reflected in the structure <built-intype>and <concurrent_relation_condition> in; <concurrent_relation_condition> contains <access_condition>, <hb_relationship> and <lock_condition>, which deal with thread-aware pointer analysis, happens-before relationship and lock set analysis, respectively;< / built-intype> Lock analysis includes IS_PROTECTED_BY and IS_AUTOMATICALLY_PROTECTED_BY methods, the former determines whether two variables are protected by the same lock, and the latter checks whether the operation is within the same critical section to ensure atomicity.

Images