A concurrent program vulnerability detection method based on fuzz testing and static analysis

Abstract

The application discloses a concurrent program vulnerability detection method based on fuzzy testing and static analysis, and comprises the following steps: compiling a to-be-detected program source code, obtaining a bytecode file according to the compiling, then performing static analysis to obtain a concurrent vulnerability pair; performing program insertion on the concurrent vulnerability pair to obtain a program binary file with inserted code; taking the program binary file with inserted code as a test program, adding an initial input file in an input queue, adding a concurrent vulnerability-oriented mechanism in AFL and adding a judgment mode of whether an input is interesting, and pruning unfeasible paths; performing fuzzy testing to realize vulnerability detection. The application can not only utilize the characteristics of concurrent program vulnerabilities, use an optimized redundant node static analysis technology to reduce the number of concurrent vulnerability detections, but also use a fuzzy testing technology to efficiently reproduce the occurrence process of the concurrent program vulnerabilities, so that more efficient and more intuitive concurrent vulnerability detection is realized.

Description

Technical Field

[0001] This invention relates to the field of concurrent memory vulnerability detection, specifically to a concurrent program vulnerability detection method based on fuzzing and static analysis. Background Technology

[0002] Multithreading has always been popular in modern software systems because it fully utilizes hardware resources to improve software performance. To enhance computational efficiency, most software systems employ multithreading techniques. However, compared to sequential programs, multithreaded programs are also more prone to serious software failures. On one hand, the non-deterministic interweaving of threads creates concurrency vulnerabilities, such as data races and deadlocks. These errors can lead to abnormal program results or unexpected suspensions. On the other hand, errors occurring under specific inputs and interactions can cause concurrency vulnerabilities, such as User-Avoidance-Definition (UAF) and Memory Failure-Definition (DF), ultimately resulting in memory corruption and information leakage. Memory vulnerabilities not only affect the normal functioning of software but can also compromise the security of the operating system.

[0003] Currently, the main multithreaded program analysis tools use detection methods that construct partial order relationships. This method is based on prediction. By predicting the execution order of code in different threads and representing all possible execution sequences, it provides the event occurrence sequence to the detection module to analyze whether vulnerabilities exist. This method detects concurrency vulnerabilities by predicting possible execution paths and cannot simulate actual vulnerability triggering.

[0004] Currently, there is no good lightweight tool for detecting concurrent memory vulnerabilities in static analysis of concurrent programs. Many static analysis efforts can only simply find concurrent regions between two threads, or the low-level static analysis techniques have poor scalability, making it difficult to extend concurrent program analysis to large programs. Therefore, it is difficult to find true concurrent memory vulnerabilities in multi-file programs.

[0005] In dynamic analysis, current mainstream methods include prediction methods based on partial order relations and fuzzy execution methods. Prediction methods based on partial order relations can analyze possible execution sequences based on the commutativity of events in a partially ordered set, thereby detecting concurrent vulnerabilities. However, these concurrent vulnerability detection methods are prediction-based and cannot reproduce the vulnerability occurrence process. As for fuzzy execution methods, current research mainly focuses on detecting memory vulnerabilities in sequential programs, and suffers from low detection efficiency and weak targeting of concurrent program memory vulnerabilities. Therefore, developing an efficient concurrent vulnerability detection technology capable of reproducing vulnerabilities is meaningful. Summary of the Invention

[0006] To overcome the problems in the prior art, the purpose of this invention is to provide a concurrent program vulnerability detection method based on fuzzing and static analysis, which can detect vulnerabilities and is highly efficient.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A concurrent program vulnerability detection method based on fuzzing and static analysis includes the following steps:

[0009] 1) Compile the source code of the program to be detected to obtain the compiled bytecode file; based on the compiled bytecode file, obtain the optimized thread-aware value flow graph;

[0010] 2) Based on the optimized thread-aware value flow graph, perform static analysis to identify concurrency vulnerability pairs;

[0011] 3) Instrument the concurrent vulnerability pairs to obtain the binary file of the program containing the instrumented code;

[0012] 4) Use the binary file containing the stub code as the test program, add an initial input file to the input queue, add a concurrent vulnerability guidance mechanism and a method to determine whether the input is interesting in AFL, and prune infeasible paths; then perform fuzz testing to achieve vulnerability detection.

[0013] Furthermore, based on the compiled bytecode file, an optimized thread-aware value flow graph is obtained, including the following process:

[0014] a) Static Anderson pointer analysis is used to perform pointer analysis on the compiled bytecode file to obtain the pointer information within the program;

[0015] b) Based on the pointer information within the program and the compiled bytecode file, analyze the statements in each thread to obtain a set of concurrent instruction pairs;

[0016] By analyzing the pointer information within the program, a value flow graph of the sequential execution version of the program is obtained;

[0017] c) Based on the characteristics of concurrent instruction pairs and concurrent vulnerabilities, perform thread-aware def-use chain analysis on the value flow graph of the sequential execution version of the program to obtain a thread-aware value flow graph;

[0018] d) Based on the pointer information in the program, delete irrelevant value flow regions that have a thread-aware value flow graph to obtain an optimized thread-aware value flow graph;

[0019] Furthermore, the specific process of step c) is as follows: based on the thread relationships and the basic semantics of the program, perform forward data flow analysis to obtain the set of each concurrent thread.

[0020] Furthermore, thread relationships include parent-child relationships, intersection relationships, and sibling threads.

[0021] Furthermore, based on the pointer information within the program, irrelevant value flow regions in the thread-aware value flow graph are deleted to obtain an optimized thread-aware value flow graph. This process includes the following steps: For program segments in the thread-aware value flow graph that do not contain statements for releasing nodes and null nodes, deletion is performed to obtain an optimized thread-aware value flow graph.

[0022] Furthermore, the specific process of step 2) is as follows: identify the read and write instruction nodes contained in the optimized thread-aware value flow graph, identify the key events that trigger program vulnerabilities, release events and null events, and obtain the concurrent vulnerability pairs.

[0023] Further, the specific process of step 3) is as follows: collect the source file path, line number, and column number from the concurrent vulnerability information, use the source file path, line number, and column number as identifiers, determine whether the position of the instrumented content has been marked by the identifiers, if it has been marked, proceed to step 4), if it has not been marked, mark it, obtain the binary file of the instrumented code, and proceed to step 4).

[0024] Furthermore, step 4) specifically involves the following process: First, when the program binary file that inserts the stub code reaches the location of the inserted stub code, the execution order of the thread where the current event is located is adjusted according to the characteristics of the concurrency vulnerability, so that the thread of the free event executes the corresponding release operation first, thereby achieving fuzzy execution guided by the concurrency vulnerability.

[0025] Furthermore, the specific characteristics of concurrency vulnerabilities are as follows: Concurrency vulnerabilities include concurrent Use-After-Flight (UAF) vulnerabilities, concurrent Defender (DF) vulnerabilities, and concurrent Non-Destructive (NPD) vulnerabilities. The characteristic of concurrent UAF vulnerabilities is that memory release events and memory usage events pointing to the same memory address can be executed concurrently under concurrency control conditions, and...<free,use> Presented in a way that allows concurrent NPD vulnerabilities to be exploited.<null,*ptr> Concurrent presentation in form, concurrent DF vulnerability can be...<free,free> It is presented concurrently in the form of [the following].

[0026] Furthermore, the specific process of pruning infeasible paths is as follows: perform graph reachability analysis based on the control flow graph (ICFG) of the multi-threaded program, prune the basic blocks of the target code that cannot be reached, use reverse analysis to find the conditional constraint paths that can reach free or null nodes, and prune some unreachable paths based on the path branch information.

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

[0028] This invention proposes a statically assisted dynamic fuzzing method for detecting concurrent memory vulnerabilities. This method uses statically analyzed pairs of suspected concurrent vulnerabilities to insert stub code into the code, guiding the dynamic fuzzer to perform tests and optimizing its detection speed to reproduce memory vulnerabilities. This method uses thread interleaving as a novel fuzzing guidance mechanism and path coverage as an auxiliary mechanism to guide the execution of fuzzing tests, enabling the fuzzing method to detect concurrent program vulnerabilities. Ultimately, it can detect most concurrent program vulnerabilities on a single test set. By reverse-analyzing the branch paths that trigger critical events of vulnerabilities and pruning unreachable paths of these critical events, it avoids excessive flow to paths that cannot trigger vulnerabilities during multiple executions, thus improving the efficiency of fuzzing.

[0029] Furthermore, this invention, based on Anderson pointer analysis, obtains program pointer information and adds thread-aware value flow edges between threads with different thread relationships in the value flow graph. It analyzes concurrency control locks to eliminate false def-use value flow edges. Finally, it identifies potentially concurrency vulnerability-sensitive operations through static analysis techniques and determines their locations in the program, thereby generating a set of suspected concurrency vulnerability pairs. Attached Figure Description

[0030] Figure 1 This is a system process diagram of the present invention;

[0031] Figure 2 This is a state machine diagram of a memory vulnerability occurrence;

[0032] Figure 3 It is the definition of a fork-join multithreaded program that uses a side graph. Detailed Implementation

[0033] To enable those skilled in the art to more clearly understand the content of this invention, the invention will now be described in detail with reference to the accompanying drawings.

[0034] See Figure 1 This invention is a method for detecting multi-threaded program vulnerabilities based on a combination of dynamic and static analysis. It primarily targets three types of vulnerabilities: use-after-free, double-free, and null pointer-deference (UAF, DF, NPD). The detection method includes the following steps:

[0035] 1) Analyze the characteristics of three types of concurrent vulnerabilities: UAF, DF, and NPD.

[0036] Based on the characteristics of the three types of concurrent vulnerabilities, the specific situations in which concurrent vulnerabilities occur are summarized as follows: Figure 2As shown, the purpose is to collect events related to concurrency vulnerabilities and multi-threaded concurrency control events. All memory operation statements, such as malloc, free, and load / store, can affect the state transitions of the program path. Using already freed dead memory will trigger a Use-After-Free (UAF) vulnerability. A Defender (DF) vulnerability can be handled as a special case of a UAF vulnerability, allowing for a second free of dead memory in subsequent operations. An NPD vulnerability involves accessing the value of a freed and null pointer (nullptr) by following the control flow path to its dereference point. The characteristic of concurrent UAF vulnerabilities is that memory freeing and memory usage events pointing to the same memory address can execute concurrently under concurrency control conditions, and can...<free,use> Similarly, concurrent NPD vulnerabilities can be presented in the same way.<null,*ptr> Concurrent presentation in form, concurrent DF vulnerability can be...<free,free> The data is presented concurrently. For concurrent DF vulnerabilities, the order of presentation is not important; it is sufficient to present the data concurrently.

[0037] 2) Compile the source code of the program to be tested to obtain the compiled bytecode file, which is used as input for static analysis;

[0038] The static analysis tool of this invention is implemented on the LLVM framework, using LLVM's clang tool, or clang wrappers such as WLLVM and GLLVM to compile the program source code. The input for static analysis is the program's bytecode, therefore source code conversion is necessary. For a single program, adding compilation directives such as `-emit-llvm` when using clang is sufficient. For large programs, an additional build system is generally used, requiring the use of GLLVM and WLLVM compilation tools to obtain the program's bytecode. This process only requires setting the compiler to gclang or WLLVM during compilation to extract the bytecode files of the entire project, ultimately generating LL or BC files, both common LLVM bytecode file formats.

[0039] 3) Use the Andersen (static Andersen) pointer analysis method to perform pointer analysis on the compiled bytecode file to obtain the pointer information within the program; the specific process is as follows:

[0040] Andersen pointer analysis targets the compiled bytecode file from step 2), mining memory objects to obtain the pointer information of all pointers. This pointer information is then converted into a pointer analysis graph, serving as the initial pointer analysis for the program. This is a data flow and context-insensitive pointer analysis method used to approximate the detection of pointer information within the program. Andersen pointer analysis is a constraint-based or subset-based method, establishing constraint relationships between variables or between variables and memory based on statements in the program. Andersen pointer analysis consists of two steps: constraint collection (or constraint generation) and constraint resolution. Andersen constraint types are mainly divided into three categories: basic constraints, simple constraints, and complex constraints. Andersen constraint statements are also a key focus of concurrent program vulnerabilities (see Table 1).

[0041] Table 1. Andersen constraint types

[0042]

[0043] 4) Analyzing the pointer information within the program in step 3) yields the value flow graph of the sequential execution version of the program. The current value flow graph is formed by value flow analysis of a single sequential execution version of the concurrent program. How to perform this analysis to obtain the value flow graph of the sequential execution version of the program is a well-known technique in the art.

[0044] 5) Analyze the set of concurrent instruction pairs:

[0045] Based on the pointer information obtained in step 3) and the compiled bytecode file obtained in step 2), analyze the statement s in each thread to obtain the set of concurrent instruction pairs. Specifically, for a statement s in thread t, find its set of concurrent instruction pairs I(t,c,s'), where t represents the thread, c represents the thread function call context, and s' represents its set of concurrent thread statements. Taking the use-after-free vulnerability as an example, it is necessary to find all memory release events and memory usage events, and find their concurrent set I(t,c,s'). use ) and I(t,c,s free ), s use For use of the statement, s freeThis method releases statements, but because it's used before constructing the def-use chain of the multi-threaded value stream, it cannot directly find operations related to the memory objects pointed to by the same memory objects in concurrent threads. Instead, it searches for the concurrent set of instructions appearing in the concurrent execution segment of the program. The threads in this method's code are abstract threads. When collecting concurrent call pairs, it primarily focuses on thread creation (fork), thread joining, and the concurrency relationships between threads, such as... Figure 3 As shown in the figure, the solid lines are the def-use edges obtained from the sequential execution of version analysis in step 4). Then, by analyzing the relationships between threads, def-use edges are added from statement S1 to statement S2, and from statement S4 to statement S3. This method ultimately obtains a set of concurrent instruction pairs for memory-related events.

[0046] 6) Thread-aware stream-sensitive pointer analysis:

[0047] Based on the set of concurrent instruction pairs obtained in step 5) and the characteristics of the three concurrency vulnerabilities summarized in step 1), thread-aware def-use chain analysis is performed on the value flow graph obtained in step 4) to obtain a thread-aware value flow graph. Specifically, to determine whether two statements are executed concurrently, their concurrent thread set I needs to be calculated. Based on the three thread relationships (fork, join, sibling) and the basic semantics of the program, the set of each concurrent thread can be obtained using forward data flow analysis. To calculate the definition-use edge of a variable, the read-write or write-write statement pairs of the variable need to be considered.

[0048] Three types of relationships that exist between different threads:

[0049] 1. Father-son relationship

[0050]

[0051] In the formula, fork i c' is the function that creates the child thread t', c' is the calling context of the function that creates the thread t', and fork i′ This is the function to create the child thread t", t′ is the child thread created by thread t, and t″ is the thread created by thread t”.

[0052] Formula 4-1 indicates that two threads have a creation relationship. For t and t', t is in the context position (c, fork) i A thread t' was created, and the thread creation relationship is transitive.

[0053] 2. Intersection relationship

[0054]

[0055] In the formula, join i The join operation is the intersection of thread t' and thread t. i′ The intersection operation between thread "t" and thread "t'".

[0056] Two threads, t and t', have an intersection operation. Thread t waits for t' to execute and eventually intersects with t'. This is said to satisfy an intersection relationship. An intersection relationship is only satisfied if all paths in t' can intersect with the main thread t.

[0057] 3. Sibling threads

[0058] If the relationship between two threads does not satisfy either of the above two conditions, and they were created by the same parent thread, they can be called sibling threads, denoted as .

[0059]

[0060] This method can identify the missing thread-aware edges in the value flow graph in step 4), thus enabling the value flow graph to have thread-aware capabilities.

[0061] 7) Optimize thread-aware value flow graph

[0062] Based on the pointer information within the program obtained in step 3), irrelevant value flow regions in the thread-aware value flow graph obtained in step 6) are deleted, resulting in an optimized thread-aware value flow graph. Because this method targets three types of memory vulnerabilities, it removes vulnerability-irrelevant value flow regions when constructing concurrent memory value flows. Program segments lacking statements for releasing nodes and null nodes are deleted to ensure a simplified value flow graph. Even if a program segment does not operate on the type of related pointers, this method does not concern itself with the impact of the execution result on vulnerability analysis, reducing analysis time and making static analysis more targeted, ultimately resulting in an optimized thread-aware value flow graph.

[0063] 8) Collection of concurrent vulnerability pairs:

[0064] The optimized thread-aware value flow graph contains read / write instruction (load, store) nodes, and the critical events that trigger program vulnerabilities, free events, and NULL events are identified to obtain concurrent vulnerability pairs. Specifically, for any two read / write instructions, if they point to the same memory object, analysis shows that the two memory operations can be executed concurrently, and they are added to set M. Hash tables are a commonly used data structure; here, a hash table is used to store the collected concurrent vulnerability pairs and related concurrent instructions. For ease of processing, this method uses the memory address of each instruction as an identifier, because numerical lookup operations are relatively easy to implement. Finally, the concurrent vulnerability pairs are obtained.

[0065] 9) Program instrumentation:

[0066] Based on the concurrent vulnerability pairs obtained from the static analysis in step 8), the source file paths, line numbers, and column numbers in the concurrent vulnerability pair information are collected and used as identifiers. The identifiers are used to determine whether the instrumented content has been marked. If marked, proceed to step 10); otherwise, mark it to obtain the binary file containing the instrumented code, and proceed to step 10). Here, a binary search method is used to examine the file array in the hash table, allowing the instrumentation location to be found in O(logn) time. Because the instrumented content requires multiple explorations of intertwined threads, the thread scheduling method needs to be controlled to make it easier to trigger concurrent vulnerabilities, ultimately resulting in a binary file containing the instrumented code.

[0067] 10) Preparations for fuzzy execution:

[0068] Using the program binary file containing the stub code obtained in step 9) as a test program, add an initial input file to the input queue as preparation for AFL (American fuzzy lop) fuzzy execution.

[0069] 11) Concurrency vulnerability orientation:

[0070] Based on the preparations in step 10) and the concurrent vulnerability pairs obtained in step 8), a concurrent vulnerability guidance mechanism is added to AFL to achieve concurrent vulnerability-guided fuzzy execution. The specific process is as follows: First, when the program binary file executes to the location of the inserted stub code, the execution order of the thread containing the current event is adjusted. Generally, the execution order of the threads is set according to the order in which the vulnerability triggers, thus achieving concurrent vulnerability guidance. Taking use-after-free as an example, the execution order of the free event is set to take precedence over the execution order of the use event. This way, when the fuzzer executes the use event, the execution order is adjusted according to the vulnerability characteristics, allowing the thread of the free event to execute the corresponding release operation first. The adjustment of the execution order is achieved through thread priority; a higher thread priority results in a higher execution order.

[0071] 12) Exploring Thread Intertwining:

[0072] After implementing concurrency vulnerability guidance, the vulnerability can be triggered as much as possible when execution reaches the location of the vulnerability. Then, an interesting input determination method is added to AFL—whether a new thread interleaving is triggered—to preserve such interesting inputs and assign them a higher mutation probability. Specifically, during program execution, each time the thread-related event function `threadE` (such as `Fork`, `Join`, or `Lock`) is called, the method in this paper collects the thread information at the corresponding location, forming a tuple.<threadID,threadE> `threadID` is the ID number of the thread executing the statement at the current position, and is used with the IDE. i =<threadID,threadE> As an execution event in thread interleaving. An execution sequence F =<IDE1,IDE2,…,IDEn> For a thread interleaving, IDEi is the event function associated with the current thread. If the current input overwrites a new thread interleaving in an execution, the current input is directly selected as the new mutation input. This is because generating a multi-threaded related seed mutation from an existing multi-threaded related seed is generally easier than entering a seed that cannot be used for thread creation. This is because mutation operations in gray-box fuzzers (e.g., bit / byte-level flips, arithmetic additions / child-level) are quite random, making it difficult to transform invalid seeds into valid ones. Therefore, from a mutation perspective, it is more preferable to mutate multi-threaded related seeds to reduce the probability of selecting unfavorable inputs.

[0073] 13) Trim unfeasible paths:

[0074] During fuzzy execution, to reduce the runtime of a single fuzzer run, infeasible paths are pruned based on static analysis. Specifically, the process involves: first, performing graph reachability analysis using the control flow graph (ICFG) of the multi-threaded program, pruning basic blocks of unreachable target code; then, using reverse analysis to find conditional constraint paths that reachable free or null nodes; and finally, pruning unreachable paths based on path branch information. This aims to quickly terminate the current round of fuzzy execution without triggering a vulnerability. Here, `exit()` is used to quickly terminate the program.

[0075] Concurrency vulnerability guidance, thread interleaving exploration, and pruning of infeasible paths are parallel modules, and there is no specific order of execution.

[0076] 14) Dynamic analysis of the execution process:

[0077] Based on the results of concurrent vulnerability guidance in step 11), thread interleaving exploration in step 12), and pruning infeasible paths in step 13), fuzzing begins to detect vulnerabilities. Based on the characteristics of concurrent vulnerability analysis in step 11), when execution reaches the current vulnerability triggering position, vulnerabilities are triggered as sequentially as possible. Based on thread interleaving exploration in step 12), more thread interleaving paths can be explored, which is more conducive to executing the code location that triggers the vulnerability. Based on the infeasible path pruning method in step 13), when execution reaches a path that cannot reach the vulnerability, the current execution can be quickly terminated, reducing execution time. In a fuzzing execution, an input is first selected from the input pool, and the instrumented binary file is executed. When execution reaches the vulnerability location, if execution follows the vulnerability characteristic sequence, the vulnerability will be triggered. The vulnerability will be presented as a crash in this execution and ultimately output to the vulnerability report. Furthermore, during fuzzing, whether to retain the input of this execution depends on whether a new thread interleaving or a new execution path is triggered.

[0078] To verify the effectiveness of the concurrent memory vulnerability detection method based on a combination of static and dynamic analysis, this method was tested using 10 CVE programs containing concurrent vulnerabilities. Static analysis was first used to detect suspected vulnerability pairs, followed by dynamic vulnerability simulation detection. Because current static analysis techniques cannot fully obtain the concurrency and pointer information of the program's code, some vulnerabilities may be missed. In dynamic analysis, some vulnerabilities may not be reported within a fixed timeframe.

[0079] Table 1. Detection results of CVE vulnerability programs

[0080] Program Name Vulnerability types Causes Static test results Dynamic detection results CVE-2009-3547 NPD Critical section exchange √ √ CVE-2011-2183 NPD Critical section exchange √ √ CVE-2013-1792 NPD Data competition × √ CVE-2015-7550 NPD Critical section exchange √ √ CVE-2016-1972 UAF Data competition √ √ CVE-2016-1973 UAF Data competition √ × CVE-2016-7911 NPD Data competition √ × CVE-2016-9806 DF Data competition × √ CVE-2017-6346 UAF Data competition √ √ CVE-2017-15265 UAF Data competition × √

[0081] Table 1 presents the vulnerability detection results. In static analysis, the detection algorithm was able to find 7 vulnerabilities among the suspected vulnerability pairs. In dynamic detection, the program was instrumented using known vulnerability pairs to simulate the occurrence of vulnerabilities, ultimately triggering 8 related vulnerabilities. Based on the above results, this invention is effective in detecting concurrent program vulnerabilities.

[0082] This invention proposes a novel approach to detecting multi-threaded concurrent memory vulnerabilities. It statically analyzes suspected concurrent vulnerability pairs, reverse-engineers the path constraints of related events based on the identified vulnerability pairs, prunes obviously unreachable paths, and uses concurrent vulnerability pairs as a guide. This involves instrumenting threads to set execution priority scheduling and setting the probability of seed mutations to guide fuzzing to explore more thread interleaving and collect concurrent vulnerabilities caused by thread interleaving during execution. This invention not only leverages the characteristics of concurrent program vulnerabilities and uses static analysis techniques to optimize redundant nodes to reduce the number of concurrent vulnerabilities detected, but also uses fuzzing techniques to efficiently reproduce the occurrence process of concurrent program vulnerabilities. Compared to traditional methods, it achieves more efficient and intuitive concurrent vulnerability detection.

Claims

1. A concurrent program vulnerability detection method based on fuzz testing and static analysis, characterized in that, Includes the following steps: 1) Compile the source code of the program to be detected to obtain the compiled bytecode file; based on the compiled bytecode file, obtain the optimized thread-aware value flow graph; 2) Based on the optimized thread-aware value flow graph, perform static analysis to identify concurrency vulnerability pairs; 3) Instrument the concurrent vulnerability pair to obtain the binary file of the program containing the instrumented code; 4) Use the binary file containing the inserted stub code as the test program, add an initial input file to the input queue, add a concurrent vulnerability guidance mechanism and a method for determining whether an input is interesting in AFL, and prune infeasible paths; then perform fuzz testing to achieve vulnerability detection; the method for determining interesting input is whether it triggers new thread interleaving, and such interesting inputs are retained and given a higher mutation probability; Based on the compiled bytecode file, the optimized thread-aware value flow graph is obtained, including the following process: a) Static Anderson pointer analysis is used to perform pointer analysis on the compiled bytecode file to obtain the pointer information within the program; b) Based on the pointer information within the program and the compiled bytecode file, analyze the statements in each thread to obtain a set of concurrent instruction pairs; By analyzing the pointer information within the program, a value flow graph of the sequential execution version of the program is obtained; c) Based on the characteristics of concurrent instruction pairs and concurrent vulnerabilities, perform thread-aware def-use chain analysis on the value flow graph of the sequential execution version of the program to obtain a thread-aware value flow graph; d) Based on the pointer information in the program, delete irrelevant value flow regions that have a thread-aware value flow graph to obtain an optimized thread-aware value flow graph.

2. The concurrent program vulnerability detection method based on fuzz testing and static analysis according to claim 1, characterized in that, The specific process of step c) is as follows: based on the thread relationships and the basic semantics of the program, perform forward data flow analysis to obtain the set of each concurrent thread.

3. The concurrent program vulnerability detection method based on fuzz testing and static analysis according to claim 2, characterized in that, Thread relationships include parent-child relationships, intersection relationships, and sibling threads.

4. The concurrent program vulnerability detection method based on fuzz testing and static analysis according to claim 1, characterized in that, Based on the pointer information within the program, irrelevant value flow regions in the thread-aware value flow graph are deleted to obtain an optimized thread-aware value flow graph. This process includes the following steps: For program segments in the thread-aware value flow graph that do not contain statements for releasing nodes and null nodes, deletion is performed to obtain the optimized thread-aware value flow graph.

5. The concurrent program vulnerability detection method based on fuzz testing and static analysis according to claim 1, characterized in that, Step 2) involves identifying the read / write instruction nodes in the optimized thread-aware value flow graph, identifying the key events that trigger program vulnerabilities, release events, and null events, and obtaining concurrent vulnerability pairs.

6. The concurrent program vulnerability detection method based on fuzzing and static analysis according to claim 1, characterized in that, Step 3) involves collecting the source file path, line number, and column number from the concurrent vulnerability information. Using these identifiers, the location of the instrumented content is determined. If marked, proceed to step 4). If not marked, mark the location to obtain the binary file containing the instrumented code, and then proceed to step 4.

7. The concurrent program vulnerability detection method based on fuzzing and static analysis according to claim 1, characterized in that, Step 4) The specific process is as follows: First, when the program binary file that inserts stub code reaches the location of the inserted stub code, the execution order of the thread where the current event is located is adjusted according to the characteristics of the concurrency vulnerability, so that the thread of the free event executes the corresponding release operation first, thereby achieving fuzzy execution guided by the concurrency vulnerability.

8. The concurrent program vulnerability detection method based on fuzzing and static analysis according to claim 7, characterized in that, The specific characteristics of concurrency vulnerabilities are as follows: Concurrency vulnerabilities include concurrent Use-After-Flight (UAF) vulnerabilities, concurrent Defender (DF) vulnerabilities, and concurrent Non-Destructive (NPD) vulnerabilities. The characteristic of concurrent UAF vulnerabilities is that memory free events and memory usage events pointing to the same memory address can execute concurrently under concurrency control conditions, and...<free,use> Presented in a way that allows concurrent NPD vulnerabilities to be exploited.<null,*ptr> Concurrent presentation in form, concurrent DF vulnerability can be...<free,free> It is presented concurrently in the form of [the following].

9. A concurrent program vulnerability detection method based on fuzzing and static analysis according to claim 1, characterized in that, The specific process of pruning infeasible paths is as follows: perform graph reachability analysis based on the control flow graph (ICFG) of the multi-threaded program, prune the basic blocks of the target code that cannot be reached, use reverse analysis to find the conditional constraint paths that can reach free or null nodes, and prune some unreachable paths based on the path branch information.

Images