A fuzzy testing method and device for conditional competition vulnerabilities in inter-process communication interfaces

Abstract

The present invention discloses a fuzz testing method and device for conditional competition vulnerabilities in an inter-process communication interface. The method is to generate, based on the interface information in the inter-process communication (IPC) code, a code and corresponding basic corpus that can be used to organize the random corpus input provided by a general fuzz testing tool into a valid data structure and call the IPC interface through a static analysis method; to collect information such as the code, memory read and written, and corresponding context, coverage, etc. through a single-threaded fuzz test; to select corpus that accesses similar memory according to probability based on the collected information, and to perform fuzz testing for conditional competition problems through interleaving execution of the current context to discover such vulnerabilities; and to reproduce the vulnerability triggering scenario through the scheduling information collected during the interleaving execution. Therefore, the present invention improves the ability of fuzz testing to discover vulnerabilities and ensures the ability to reproduce vulnerabilities after triggering vulnerabilities for IPC calls and conditional competition problem scenarios.

Description

Technical Field

[0001] The present invention belongs to the field of network security, and in particular relates to a fuzzy testing method and device for conditional competition vulnerabilities in an inter-process communication interface. Background Art

[0002] With the development of software technology, inter-process communication (IPC) is increasingly used as an interface for a high-privilege system process to provide certain functions to a low-privilege process. Typical scenarios include the code in the sandboxed rendering process in the browser calling various functions implemented by the main process through IPC; some functions in the operating system and application framework are implemented by high-privilege user-mode processes, and these processes provide their functions to ordinary applications in the application container through IPC interfaces. Some of these functions are very basic and commonly used, so restricting these functions to single-threaded execution will cause serious performance degradation and is unrealistic. However, once a high-privilege process uses multi-threading technology to concurrently respond to requests from low-privilege processes, the code that handles these requests must avoid conditional competition problems, because conditional competition problems can cause logical errors or even memory corruption in high-privilege processes, and even allow the IPC initiator from the low-privilege process to completely control the execution of the high-privilege process. The execution permissions of low-privilege processes themselves are easily obtained by malicious attackers, because low-privilege processes are used to execute and process a large amount of code from untrusted input, such as browser JavaScript engines, untrusted third-party applications in mobile operating systems, etc. Since the concurrent security of a program is difficult to ensure by developers when coding, it is necessary to check these codes through fuzz testing to ensure the security boundary.

[0003] Existing work has certain limitations. Fuzz testing tools for IPC do not have features for conditional race problems to improve the discovery rate of related vulnerabilities. They often need to encounter conditional race problems by chance or even do not support simultaneous execution of multiple threads in fuzz testing. Fuzz testing tools for conditional race problems are difficult to strictly enumerate operation pairs one by one in scenarios where IPC overhead is large and one call is relatively complex, and the corpus generated by them is difficult to achieve high coverage of the IPC attack surface. In addition, since two threads are used for concurrent execution, it is difficult to determine the order of read and write operations on key addresses, making it difficult to reproduce vulnerabilities. Or although interleaved execution is used and only one thread is executed at a time, the location where the stub gives up the current CPU execution right is limited, and it is impossible to simulate the scenario of being triggered by the operating system time slice interrupt. Summary of the invention

[0004] In view of the shortcomings of the prior art, the present invention provides a fuzzy testing method and device for conditional competition vulnerabilities in an inter-process communication interface. The method can generate corresponding corpus for IPC scenarios to improve coverage, guide interleaved execution to trigger vulnerabilities according to the running conditions of a single thread to improve the vulnerability triggering rate, and efficiently reproduce the vulnerabilities according to records after triggering. The method generally includes generating initial corpus according to interface information, performing single-thread fuzzy testing and collecting read-write sets according to coverage feedback, inducing conditional competition vulnerabilities through multi-threaded interleaved execution, and reproducing the vulnerabilities according to records.

[0005] The present invention is achieved through the following technical solutions:

[0006] The first aspect of the present invention is a fuzzy testing method for conditional competition vulnerabilities in an inter-process communication interface, comprising the following steps:

[0007] (1) Based on the interface information in the inter-process communication (IPC) code in the software under test, a static analysis method is used to generate the code and corresponding basic corpus that can be organized into valid data structures using the random corpus provided by the general fuzz testing tool, and then use these data structures as parameters to call the IPC interface;

[0008] (2) Perform fuzz testing on a single thread to collect the code, memory read and written, corresponding context, and coverage information of the running program;

[0009] (3) Based on the collected information, multiple copies of the corpus that access similar memory are selected probabilistically, and fuzz testing is performed against conditional competition by preemptively or collaboratively giving up the current time slice for interleaved execution;

[0010] (4) When a race condition exists in the test, the vulnerability triggering scenario is reproduced using the information collected during the interleaved execution in step (3).

[0011] Specifically, the inter-process communication IPC code in step (1) is an interface definition language IDL and a Proxy code for implementing interface calls.

[0012] Furthermore, the step (1) specifically comprises the following sub-steps:

[0013] (1.1) Obtain the type information of each parameter of the IPC interface by parsing the interface definition language IDL or C++ abstract syntax tree AST, and generate a data structure organized by random corpus input into each parameter type type and the code using it to call the IPC interface; and run the software under test after inserting the IPC basic library, and record the IPC calls made during its operation as the basic corpus;

[0014] (1.2) For situations where triggering needs to rely on a specific context, a fuzz testing tool that considers context information to generate a call sequence is used to generate an IPC call sequence, and the serialized data of the call sequence is used as the basic corpus, and its executor is used as the conversion code from the corpus to the call;

[0015] (1.3) When the IPC interface definition is too complex to be automatically processed, manual static analysis is performed and the corresponding code and corpus are written.

[0016] Furthermore, the step (2) specifically comprises the following sub-steps:

[0017] (2.1) Compile the code generated in step (1) and the methods called by it, and insert stubs at the locations where memory is read and written and control flow reaches the beginning of the new basic block during compilation to record the occurrence of memory read and write and control flow events;

[0018] (2.2) Run the program using the basic corpus in step (1) to trigger inter-process calls and collect information using instrumentation code;

[0019] (2.3) Combine and mutate the corpus to generate new corpus based on the collected information;

[0020] (2.4) Continue running and collecting information using the new corpus;

[0021] (2.5) When the coverage does not increase within the threshold number of runs, end this step, otherwise return to the combination and mutation step to continue.

[0022] Furthermore, the step (3) specifically comprises the following sub-steps:

[0023] (3.1) Compile the code generated in step (1) and the methods it calls. During compilation, insert a stub when the control flow reaches the beginning of a new basic block, use a counter to record the number of times the control flow reaches this beginning, and insert a stub when reading or writing memory or acquiring a lock to actively give up the CPU time slice;

[0024] (3.2) Randomly select a corpus and randomly select a memory address as the target, where the probability of the corpus and the memory address being selected is inversely proportional to the number of times they were previously selected as the target;

[0025] (3.3) Calculate the similarity between each corpus and the target, and randomly select a threshold number of corpora, where the similarity is proportional to the probability of the corpus being selected;

[0026] (3.4) Start a thread and pause all threads after inputting the corpus;

[0027] (3.5) After setting a timer with a random time, randomly select one of the threads to record the scheduling log and resume its execution. The scheduling log contains the count of the number of times the current basic block is executed, the current program counter PC and the number of the newly scheduled thread, until the active yield function is called or the timer is triggered, or the program crashes or ends;

[0028] (3.6) If the program crashes, it means a vulnerability is found, and the corpus and all scheduling logs are recorded; if the program crashes or ends normally, the test is completed. If you continue the test, return to the step of selecting the corpus target and start the loop. If you do not continue, the loop ends; otherwise, return to the previous step and continue execution.

[0029] Furthermore, the step (4) specifically comprises the following sub-steps:

[0030] (4.1) Start n threads and pause them all after inputting the recorded corpus;

[0031] (4.2) Take all scheduling logs as queues, take out the program counter PC of the first item, and set the hardware execution breakpoint here;

[0032] (4.3) Continue to execute the thread corresponding to the first item until the program ends, crashes, or encounters a hardware breakpoint;

[0033] (4.4) If a hardware breakpoint is encountered and the current basic block counter is less than the recorded value, return to the previous step to continue execution; if the program ends, the current basic block counter is greater than the recorded value when a hardware breakpoint is encountered, or there is only one item in the log queue when it is equal to the recorded value, then this reproduction fails, and try to reproduce again from the step of starting the thread; if the program crashes, the reproduction is successful; otherwise, remove the first item in the log queue and remove the current hardware execution breakpoint, and then return to the step of setting the hardware breakpoint to continue execution.

[0034] The second aspect of the present invention is a fuzzy testing device for conditional competition vulnerabilities in an inter-process communication interface, comprising the following modules:

[0035] Generate data structure module: Based on the interface information in the inter-process communication (IPC) code in the software to be tested, generate code and corresponding basic corpus that can be organized into valid data structures using random corpus provided by general fuzz testing tools through static analysis methods, and use these data structures as parameters to call the IPC interface;

[0036] Test collection module: collects the code, memory read and written, corresponding context and coverage information of the running program through single-threaded fuzz testing;

[0037] Fuzz testing module: Based on the collected information, multiple corpora that access similar memory are selected by probability, and fuzz testing is performed on conditional competition by preemptively or collaboratively giving up the current time slice for interleaved execution;

[0038] Vulnerability reproduction module: When there is a conditional race in the test, the vulnerability triggering scenario is reproduced through the information collected during the interleaved execution in the fuzz test module.

[0039] The third aspect of the present invention: an electronic device, comprising:

[0040] one or more processors;

[0041] A memory for storing one or more programs;

[0042] When the one or more programs are executed by the one or more processors, the one or more processors implement the fuzz testing method for conditional competition vulnerabilities in an inter-process communication interface.

[0043] The fourth aspect of the present invention: a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of a fuzzy testing method for conditional competition vulnerabilities in an inter-process communication interface.

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

[0045] 1. The coverage improvement of the method for IPC scenarios can be effectively used to improve the vulnerability discovery rate.

[0046] 2. Probabilistically select interleaved corpus combinations to induce conditional competition so that multiple conditional competition operations can be tried at the same time to see if they may trigger the problem;

[0047] 3. By simulating the random timer of the operating system time slice expiration and actively giving up the current CPU when reading or writing memory or acquiring locks, similar to the simulation delay method, the probability of triggering conditional competition problems can be increased;

[0048] 4. During the interleaved execution, key information such as the number of times the basic block where the PC is located is run is recorded to ensure the ability to efficiently reproduce the vulnerability after the vulnerability is triggered, making it easier to analyze the vulnerability. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 It is a flow chart of the fuzzy testing method for conditional competition vulnerability in the inter-process communication interface of the present invention;

[0050] Figure 2 A specific flow chart of concurrent fuzz testing in the fuzz testing method for conditional competition vulnerabilities in the inter-process communication interface of the present invention;

[0051] Figure 3 It is a specific flow chart reproduced according to records in the fuzzy testing method for conditional competition vulnerabilities in the inter-process communication interface of the present invention. DETAILED DESCRIPTION

[0052] The present invention will be further described in detail below in conjunction with the accompanying drawings.

[0053] like Figure 1 As shown, a fuzz testing method for conditional competition vulnerabilities in an inter-process communication interface includes the following steps:

[0054] (1) Based on the interface information in the inter-process communication (IPC) code (e.g., interface definition language IDL, proxy code for implementing interface calls) in the software under test, a static analysis method is used to generate code and corresponding basic corpus that can be organized into valid data structures using random corpus provided by common fuzz testing tools (e.g., libFuzzer, AFL) and use these data structures as parameters to call the IPC interface. The generation process specifically adopts the following method:

[0055] (1.1) Obtain the type information of each parameter of the IPC interface by parsing the IDL or C++ abstract syntax tree (AST), and generate code that organizes the random corpus input into data structures of these parameter types and then uses them to call the IPC interface. In addition, run the software under test after inserting the IPC basic library, and record the IPC calls made during its operation as the basic corpus;

[0056] (1.2) For situations where triggering needs to rely on a specific context, use a fuzz testing tool (such as syzkaller) that considers context information to generate call sequences to generate IPC call sequences, use the serialized data of the call sequence as the basic corpus, and use its executor as the conversion code from the corpus to the call;

[0057] (1.3) For situations where the IPC interface definition is particularly complex and cannot be processed automatically, manual static analysis is performed and corresponding code and corpus are written;

[0058] (2) Perform fuzz testing on a single thread to collect the code, memory read and written, and corresponding context and coverage information of the running program, including the following sub-steps:

[0059] (2.1) Compile the code generated in step (1) and the methods it calls. During compilation, insert stubs at the locations where memory is read and written and where the control flow reaches the beginning of a new basic block to record the occurrence of these events;

[0060] (2.2) Use the basic corpus in step (1) to run the program in step (1) to trigger inter-process calls and collect information using instrumentation code;

[0061] (2.3) Combine and mutate the corpus to generate new corpus based on the collected information;

[0062] (2.4) Continue running and collecting information using the new corpus;

[0063] (2.5) When the coverage does not increase within the threshold number of runs, end this step, otherwise return to the combination and mutation step to continue execution;

[0064] Noteworthy things to note in this step:

[0065] 1. The purpose of single-thread operation here is to ensure that the collected information is not interfered by other threads. Therefore, a multi-process fuzz testing framework can still be used to give full play to the processor performance;

[0066] 2. In order to ensure the consistency of the address information collected in multiple runs, it is necessary to turn off the address space randomization function of the operating system;

[0067] 3. The instrumentation information mentioned in this step is mainly used in step (3). In order to generate better corpus when combining and mutating, the comparison instructions and other locations can be further instrumented.

[0068] (3) If Figure 2 As shown, based on the collected information, multiple corpora that access similar memory are selected according to probability, and fuzz testing for conditional competition is performed by preemptively or collaboratively giving up the current time slice for interleaved execution, which specifically includes the following sub-steps:

[0069] (3.1) Compile the code generated in step (1) and the methods it calls. During compilation, insert a stub when the control flow reaches the beginning of a new basic block, use a counter to record the number of times the control flow reaches this beginning, and insert a stub when reading or writing memory or acquiring a lock to actively give up the current CPU time slice;

[0070] (3.2) Randomly select a corpus and randomly select a memory address as the target, where the probability of the corpus and the memory address being selected is inversely proportional to the number of times they were previously selected as the target;

[0071] (3.3) Calculate the similarity between each corpus and the target (composed of the similarity between the read and write sets of the target corpus when running in a single thread, whether memory access is performed, and other indicators), and randomly select a threshold number of corpora, where the similarity is proportional to the probability of the corpus being selected;

[0072] (3.4) Start a thread (coroutines can also be used instead. The thread suspension and resumption are changed to use the coroutine library to switch the coroutine context executed by the current thread). After entering the corpus, all are suspended;

[0073] (3.5) After setting a timer with a random time, randomly select one of the threads to record the scheduling log (including the count of the number of times the current basic block is executed, the current program counter PC, and the number of the newly scheduled thread) and then resume its execution until the function is called or the timer is triggered, the program crashes (which means a possible vulnerability is found, and the sanitizer can be used to actively crash when it finds that the problem has occurred) or ends;

[0074] (3.6) If the program crashes, it means a vulnerability is found, and the corpus and all scheduling logs are recorded; if the program crashes or ends normally, the test is completed. If you continue the test, return to the step of selecting the corpus target and start the loop. If you do not continue, it ends; otherwise, return to the previous step to continue execution;

[0075] (4) If Figure 3 As shown in the figure, when there is a conditional competition in the test, the vulnerability triggering scenario is reproduced through the information collected during the interleaved execution in step (3), which specifically includes the following sub-steps:

[0076] (4.1) Start a thread and pause all threads after inputting the recorded corpus;

[0077] (4.2) Take all scheduling logs as queues, take out the program counter PC of the first item, and set the hardware execution breakpoint here;

[0078] (4.3) Continue to execute the thread corresponding to the first item until the program ends, crashes, or encounters a hardware breakpoint;

[0079] (4.4) If a hardware breakpoint is encountered and the current basic block counter is less than the recorded value, return to the previous step to continue execution; if the program ends, the current basic block counter is greater than the recorded value when a hardware breakpoint is encountered, or there is only one item in the log queue when it is equal to the recorded value, then this reproduction fails, and try to reproduce again from the step of starting the thread; if the program crashes, the reproduction is successful; otherwise, remove the first item in the log queue and remove the current hardware execution breakpoint, and then return to the step of setting the hardware breakpoint to continue execution.

[0080] The present invention also provides a fuzzy testing device for conditional competition vulnerabilities in an inter-process communication interface, comprising the following modules:

[0081] Generate IPC call code module: Based on the interface information in the inter-process communication IPC code in the software to be tested, generate the code and corresponding basic corpus that can be organized into valid data structures using the random corpus provided by the general fuzz testing tool through static analysis methods, and use these data structures as parameters to call the IPC interface;

[0082] Test collection module: collects the code, memory read and written, corresponding context and coverage information of the running program through single-threaded fuzz testing;

[0083] Fuzz testing module: Based on the collected information, multiple corpora that access similar memory are selected by probability, and fuzz testing is performed on conditional competition by preemptively or collaboratively giving up the current time slice for interleaved execution;

[0084] Vulnerability reproduction module: When there is a conditional race in the test, the vulnerability triggering scenario is reproduced through the information collected during the interleaved execution in the fuzz test module.

[0085] And an electronic device is provided, comprising:

[0086] one or more processors;

[0087] A memory for storing one or more programs;

[0088] When the one or more programs are executed by the one or more processors, the one or more processors implement the fuzz testing method for conditional competition vulnerabilities in an inter-process communication interface.

[0089] A computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the steps of a fuzzy testing method for conditional competition vulnerabilities in an inter-process communication interface.

[0090] The present invention uses a common method used by fuzz testing tools for IPC to improve the coverage of corpus generated in the initialization and single-threaded fuzz testing stages; then abandons the common fuzz testing method for conditional competition problems that is difficult to implement by strictly enumerating operation equivalence one by one, and probabilistically selects a combination of corpus for interleaved execution to induce the occurrence of conditional competition problems; and in the specific interleaved execution steps, a random timer that simulates the expiration of the operating system time slice is introduced, and a method of actively giving up the current CPU when reading and writing memory or acquiring locks is introduced for common concurrency problem patterns, so as to increase the occurrence rate of conditional competition problems as much as possible; and for these situations, a program counter PC and the record of the number of times the basic block where the PC is located is run are introduced so that all scheduling can be effectively reproduced.

[0091] Those skilled in the art will readily appreciate other embodiments of the present application after considering the description and practicing the contents disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The description and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the claims.

[0092] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A fuzzy testing method for conditional competition vulnerabilities in an inter-process communication interface, characterized in that: The following steps are involved: (1) Based on the interface information in the IPC code of the software under test, a static analysis method is used to generate the code and corresponding basic corpus that can be organized into a valid data structure using the random corpus provided by a general fuzz testing tool, and use these data structures as parameters to call the IPC interface; specifically, the following sub-steps are included: (1.1) Obtain the type information of each parameter of the IPC interface by parsing the interface definition language IDL or C++ abstract syntax tree AST, and generate a data structure organized by random corpus input into each parameter type type and the code using it to call the IPC interface; and run the software under test after inserting the IPC basic library, and record the IPC calls made during its operation as the basic corpus; (1.2) For situations where triggering needs to rely on a specific context, a fuzz testing tool that considers context information to generate a call sequence is used to generate an IPC call sequence, and the serialized data of the call sequence is used as the basic corpus, and its executor is used as the conversion code from the corpus to the call; (1.3) When the IPC interface definition is too complex to be automatically processed, manual static analysis is performed and the corresponding code and corpus are written; (2) Perform fuzz testing on a single thread to collect the code, memory read and written, corresponding context, and coverage information of the running program; specifically, the following sub-steps are included: (2.1) Compile the code generated in step (1) and the methods called by it, and insert stubs at the locations where memory is read and written and control flow reaches the beginning of the new basic block during compilation to record the occurrence of memory read and write and control flow events; (2.2) Run the program using the basic corpus in step (1) to trigger inter-process calls and collect information using instrumentation code; (2.3) Combine and mutate the corpus to generate new corpus based on the collected information; (2.4) Continue running and collecting information using the new corpus; (2.5) When the coverage does not increase within the threshold number of runs, end this step, otherwise return to the combination and mutation step to continue execution; (3) Based on the collected information, multiple corpora that access similar memory are selected probabilistically, and fuzz testing for conditional competition is performed by preemptively or collaboratively giving up the current time slice for interleaved execution; specifically, the following sub-steps are included: (3.1) Compile the code generated in step (1) and the methods it calls. During compilation, insert a stub when the control flow reaches the beginning of a new basic block, use a counter to record the number of times the control flow reaches this beginning, and insert a stub when reading or writing memory or acquiring a lock to actively give up the CPU time slice; (3.2) Randomly select a corpus and randomly select a memory address as the target, where the probability of the corpus and the memory address being selected is inversely proportional to the number of times they were previously selected as the target; (3.3) Calculate the similarity between each corpus and the target, and randomly select a threshold number of corpora, where the similarity is proportional to the probability of the corpus being selected; (3.4) Start a thread and pause all threads after inputting the corpus; (3.5) After setting a timer with a random time, randomly select one of the threads to record the scheduling log and resume its execution. The scheduling log contains the count of the number of times the current basic block is executed, the current program counter PC and the number of the newly scheduled thread, until the active yield function is called or the timer is triggered, or the program crashes or ends; (3.6) If the program crashes, it means a vulnerability is found, and the corpus and all scheduling logs are recorded; if the program crashes or ends normally, the test is completed. If you continue the test, return to the step of selecting the corpus target and start the loop. If you do not continue, it ends; otherwise, return to the previous step to continue execution; (4) When a race condition exists in the test, the vulnerability triggering scenario is reproduced using the information collected during the interleaved execution in step (3); this includes the following sub-steps: (4.1) Start n threads and pause them all after inputting the recorded corpus; (4.2) Take all scheduling logs as queues, take out the program counter PC of the first item, and set the hardware execution breakpoint here; (4.3) Continue to execute the thread corresponding to the first item until the program ends, crashes, or encounters a hardware breakpoint; (4.4) If a hardware breakpoint is encountered and the current basic block counter is less than the recorded value, return to the previous step to continue execution; if the program ends, the current basic block counter is greater than the recorded value when a hardware breakpoint is encountered, or there is only one item in the log queue when it is equal to the recorded value, then this reproduction fails, and try to reproduce again from the step of starting the thread; if the program crashes, the reproduction is successful; otherwise, remove the first item in the log queue and remove the current hardware execution breakpoint, and then return to the step of setting the hardware breakpoint to continue execution.

2. According to claim 1, a fuzzy testing method for conditional competition vulnerability in an inter-process communication interface is characterized in that: The inter-process communication IPC code in step (1) is an interface definition language IDL and a Proxy code for implementing interface calls.

3. A fuzzy testing device for conditional competition vulnerabilities in an inter-process communication interface, characterized in that: Includes the following modules: Generate data structure module: Based on the interface information in the inter-process communication (IPC) code in the software to be tested, generate code and corresponding basic corpus that can be organized into valid data structures using random corpus provided by general fuzz testing tools through static analysis methods, and use these data structures as parameters to call the IPC interface; Specifically: By parsing the interface definition language IDL or C++ abstract syntax tree AST, the type information of each parameter of the IPC interface is obtained, and the data structure organized by random corpus input into each parameter type and the code using it to call the IPC interface are generated; and the software under test is run after the IPC basic library is plugged in, and the IPC calls that have been made during its operation are recorded as the basic corpus; for the case where the trigger needs to rely on a specific context, a fuzz testing tool that generates a call sequence considering the context information is used to generate an IPC call sequence, and the serialized data of the call sequence is used as the basic corpus, and its executor is used as the conversion code from the corpus to the call; When the IPC interface definition is too complex to be processed automatically, manual static analysis is performed and the corresponding code and corpus are written; Test collection module: collects the code, memory read and written, corresponding context and coverage information of the running program through single-threaded fuzz testing; Specifically: Compile the code generated by the data structure generation module and the methods it calls, and insert stubs at the locations where the memory is read and written and the control flow reaches the beginning of the new basic block during compilation to record the occurrence of memory read and write and control flow events; Use the basic corpus in the data structure generation module to run the program to trigger inter-process calls, and use the instrumentation code to collect information; combine and mutate the corpus based on the collected information to generate a new corpus; continue to run and collect information using the new corpus; end this step when the coverage does not increase within the threshold number of runs, otherwise return to the combination and mutation step to continue execution; Fuzz testing module: Based on the collected information, multiple corpora that access similar memory are selected by probability, and fuzz testing is performed on conditional competition by preemptively or collaboratively giving up the current time slice for interleaved execution; specifically: Compile the code generated by the data structure generation module and the methods it calls. During compilation, insert a stub when the control flow reaches the beginning of a new basic block, use a counter to record the number of times the control flow reaches this beginning, and insert a stub when reading or writing memory or acquiring a lock to actively give up the CPU time slice; randomly select a corpus, and randomly select a memory access address as the target, where the probability of the corpus and the memory access address being selected is inversely proportional to the number of times they were previously selected as the target; calculate the similarity between each corpus and the target, randomly select a threshold corpus, where the similarity is proportional to the probability of the corpus being selected; start a thread, input After the corpus is entered, all are paused; after setting a timer with a random time, one of the threads is randomly selected to record the scheduling log and then resume its execution. The scheduling log contains the count of the number of times the current basic block is executed, the current program counter PC and the number of the newly scheduled thread, until the function is called or the timer is triggered, the program crashes or ends; if the program crashes, it means that a vulnerability has been found, and the corpus and all scheduling logs are recorded; if the program crashes or ends normally, the test is completed. If the test continues, it returns to the step of selecting the corpus target to start the loop. If not, it ends; otherwise, it returns to the previous step to continue execution; Vulnerability Reproduction Module: When there is a conditional race in the test, the vulnerability triggering scenario is reproduced through the information collected during the interleaved execution in the fuzz test module; Specifically: Start n threads, and pause them all after inputting the recorded corpus; Take all scheduling logs as queues, take out the program counter PC of the first item, and set a hardware execution breakpoint here; continue to execute the thread corresponding to the first item until the program ends, crashes, or encounters a hardware breakpoint; if a hardware breakpoint is encountered and the current basic block counter is less than the recorded value, return to the previous step to continue execution; if the program ends, encounters a hardware breakpoint, and the current basic block counter is greater than the recorded value, or when it is equal to the recorded value and there is only one item in the log queue, this reproduction fails, and try to reproduce again from the step of starting the thread; if the program crashes, the reproduction is successful; otherwise, remove the first item of the log queue and remove the current hardware execution breakpoint, and then return to the step of setting the hardware breakpoint to continue execution.

4. An electronic device, characterized in that: include: one or more processors; A memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement a fuzz testing method for conditional competition vulnerabilities in an inter-process communication interface as described in any one of claims 1-2.

5. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the instruction is executed by the processor, the steps of a fuzz testing method for conditional competition vulnerabilities in an inter-process communication interface as described in any one of claims 1-2 are implemented.

Images