Dual-information-aware network protocol fuzz testing method and system based on state variables

Abstract

The invention relates to the technical field of network protocol testing, in particular to a dual information awareness network protocol fuzzy testing method and system based on state variables, and the method comprises the steps: carrying out the static analysis of network protocol source codes, and recognizing the state variables in the source codes; the method comprises the following steps of: tracking and detecting the change of a network protocol state variable by performing instrumentation on the state variable, acquiring a process state in a network protocol, and constructing a state machine according to the process state so as to map a state space and a code space; selecting key states of the network protocol according to the state weight, constructing a message pool of the key states, carrying out selective replacement and cross compiling on messages in the message pool according to the states and message awareness by taking the messages as units to obtain message variation, generating a message sequence for generating a test case according to the message variation, and sending the message sequence to a server; and the key state of the network protocol is subjected to targeted test by using the test case. According to the method, higher edge coverage, more crash triggering and faster first crash triggering can be obtained, and the method has a good application prospect.

Description

Technical Field

[0001] The present invention relates to the technical field of network protocol testing, and in particular to a dual information perception network protocol fuzzy testing method and system based on state variables. Background Art

[0003] Vulnerability mining is a key means of detecting software security, and fuzz testing is an important research direction in the field of vulnerability mining. Fuzz testing uses random data to input into the target program to be tested, monitors program anomalies such as crashes and assertion failures, and then discovers possible security vulnerabilities such as memory leaks. With the introduction of gray-box fuzz testing in recent years, a number of gray-box fuzz testing tools represented by AFL have received more attention. In fact, since the introduction of fuzz testing, it has been gradually and widely used in network protocol-related testing and vulnerability mining. Traditional protocol fuzz testing is carried out through black-box testing methods, which does not require the source code of the protocol program. It only needs to test the network address and port number of the running protocol device. However, there is a lack of feedback information in the black-box fuzz testing process, and the relatively blind scheme leads to poor testing results. The current popular fuzz testing tools are mainly gray-box fuzz testing, which uses coverage information for feedback and introduces genetic mutation algorithms, so that the code coverage in the test results and the final vulnerability mining effect are significantly improved. However, most of the existing gray-box fuzz testing tools target local programs, do not take into account the program status, and cannot effectively test network protocols. Moreover, the mutation efficiency of related testing tools is low, and there are deficiencies in the mutation scheme for messages.

[0004] Due to the complexity of network protocol programs, existing protocol fuzz testing tools cannot effectively explore the protocol state space. This involves the following three challenges: The first is the representation of network service states. Existing gray-box fuzz testers have deficiencies in the representation of network protocol states. Since the protocol itself is stateful, the responses to the same input in different states will also be different. At the same time, certain vulnerabilities can only be triggered when certain states and specific messages are met. Efficient network protocol gray-box fuzz testing requires not only a reasonable description and expression of the state of the protocol itself, but also continuous attention to the transfer of program states. Information feedback obtained by test schemes that are insensitive to protocol states will also have certain problems, which may mislead the guidance direction of genetic mutation algorithms. The second is the problem of not being able to focus on key states. Existing gray-box fuzz testers are relatively independent in scheduling states and seeds. Not all seeds are equally important during the test process. Under the limited test time limit, it is necessary to design an efficient solution for seed scheduling, which requires attention to key states. Although some existing tools have already taken protocol states as important information, and combined with coverage-guided solutions to jointly guide fuzz testing, the two are not organically combined and are still relatively independent when used without correlation analysis. In general, the scheduling of seeds is phased, and the seed selection process is after the protocol state selection. Therefore, it is necessary to consider the exploration of key states, enhance the expression of the state machine, and make full use of the information in the process. The third is the message mutation problem. The existing mutation strategy is not sensitive to the structure and order of the message sequence. Due to the lack of specific messages, the protocol implementation program may not be able to continuously receive the generated message sequence. The protocol fuzzer generates a large number of invalid messages, which will greatly reduce the test efficiency. Summary of the invention

[0005] To this end, the present invention provides a dual information perception network protocol fuzz testing method and system based on state variables, which solves the limitations of current fuzz testing such as inaccurate state representation, inability to test key states, and lack of effectiveness of mutation strategies. Through lightweight protocol program state representation, the disadvantage of too coarse-grained state obtained due to response codes is avoided. At the same time, collaborative linking of coverage is performed for the highest abstract layer of the protocol program, which can more effectively select state and message mutations and improve the effect of network protocol fuzz testing.

[0006] According to the design scheme provided by the present invention, on the one hand, a dual information perception network protocol fuzz testing method based on state variables is provided, comprising:

[0007] Performing static analysis on the network protocol source code and identifying state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol;

[0008] Track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and build a state machine based on the process states to map state space and code space, wherein the process states are code state transitions based on changes in state variables;

[0009] The key state of the network protocol is selected according to the state weight, and a message pool of the key state is constructed. The messages are selected, replaced and cross-compiled in the message pool according to the state and message perception to obtain message variations. A message sequence for generating test cases is generated according to the message variations, so as to use the test cases to perform targeted tests on the key states of the network protocol. The message pool is all protocol message combinations that enable the network protocol entity program to reach the key state.

[0010] As a dual information perception network protocol fuzzy testing method based on state variables of the present invention, further, a static analysis is performed on the network protocol source code, and the state variables in the source code are identified, including:

[0011] Perform static analysis on the source code and obtain the event processing loop using the call stack backtrace information when reading messages from the protocol source code;

[0012] The state variables in the source code are identified and annotated, and a unique string identifier is assigned to each state variable, which is output in the form of a state list. The state variables include: event processing loop program variables, program variables read / written in message processing functions, enumeration / integer global variables written by constants, and member variables in structures.

[0013] As a dual information perception network protocol fuzz testing method based on state variables of the present invention, further, the call stack backtrace information when reading the message by the protocol source code is used to obtain the event processing loop, including:

[0014] Set a breakpoint at the program input class system call;

[0015] In the network protocol service processing stage, if a breakpoint is triggered, the current protocol program function call stack information is used as auxiliary information to identify the event processing loop; and all loop structures containing I / O operations are collected, and a mapping relationship is established through the functions to which the loop structures belong;

[0016] Based on the stack backtrace information, all functions are matched layer by layer in the mapping relationship from the bottom function of the function call stack, and the loop structure contained in the first matched function is used as the event processing loop.

[0017] As a dual information perception network protocol fuzzy testing method based on state variables of the present invention, further, by inserting the state variables to track and detect the changes of the network protocol state variables, it includes:

[0018] Perform instrumentation on the state variable write operation in the network protocol source code, and map the write value of the state variable to the shared memory block between the fuzz test and the network protocol source code under test;

[0019] An XOR operation is performed on the hash value identified by the state variable string and the new value to be written, and the XOR value is used as an index for updating the shared memory block, so as to utilize the change of the shared memory block to record the state transfer process of the network protocol state variable.

[0020] As a dual information perception network protocol fuzz testing method based on state variables of the present invention, further, a state machine is constructed according to the process state to map the state space and the code space, including:

[0021] A state machine is constructed based on feedback codes or state variables, and the state machine is expanded into a directed graph structure, and the state nodes are expanded into a six-tuple representation, so as to establish a mapping relationship between the state space and the code space using the directed graph structure;

[0022] Among them, the directed graph structure is expressed as<S,E,∑:S→{re_mes}> , S is the set of protocol states, E is the set of states and corresponding program variables, ∑ is the mapping between recorded messages and corresponding states, re_mes is the request message, and the six-tuple of state nodes is represented as

[0023] <depth,pnode,statetrans_paths,covered_bits,selscted_time,fuzzed_times> , depth represents the depth of the state node; pnode represents the forward state node of the state node; statetrans_paths represents the number of state transition paths explored in the current state; covered_bits represents the program bitmap covered by the current state; selected_times represents the number of times the state is selected; fuzzed_times represents the number of times the state is tested.

[0024] As the dual information perception network protocol fuzzy testing method based on state variables of the present invention, further, the key state of the network protocol is selected according to the state weight, including:

[0025] The state weight is calculated based on the depth of the state node, the number of state transition paths explored in the current state, the program bitmap covered by the current state, the number of times the state is selected, and the number of times the state is tested;

[0026] The state weight is used as the probability of the state being selected to obtain the key states of the network protocol for targeted testing in the best time.

[0027] As a dual information perception network protocol fuzzy testing method based on state variables of the present invention, further, a message pool of key states is constructed, including:

[0028] Construct a mutation message pool for each state, where the messages in the mutation message pool are high-value messages extracted from the interesting message sequences generated in the corresponding network protocol state. The interesting message sequences are target messages identified based on state transitions, code coverage, and the number of error handling times.

[0029] The message score is calculated based on the number of new states generated, the number of new branches triggered, and the execution time. The message with the message score is added to the message pool under the corresponding state to obtain the message pool for mutation of the corresponding key state.

[0030] On the other hand, the present invention also provides a dual information perception network protocol fuzzy testing system based on state variables, comprising: a static analysis module, a state machine construction module and a targeted testing module, wherein:

[0031] A static analysis module, used to perform static analysis on the network protocol source code and identify state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol;

[0032] A state machine construction module is used to track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and construct a state machine based on the process states to map the state space and the code space, wherein the process state is a code state transition based on changes in state variables;

[0033] A targeted testing module is used to select key states of the network protocol based on state weights, build a message pool for key states, and select, replace and cross-compile messages in the message pool based on states and message perception to obtain message variations. A message sequence for generating test cases is generated based on the message variations, so as to use the test cases to perform targeted tests on key states of the network protocol. The message pool is a combination of all protocol messages that enable the network protocol entity program to reach the key state.

[0034] Beneficial effects of the present invention:

[0035] The present invention uses the state variables identified in the source code to obtain more process states, and can support manual annotation using APIs, thereby obtaining a more complete protocol characterization scheme, as well as a state representation with customizable granularity, establishing a mapping between the state space and the code space, fully associating the test process information, connecting the protocol state and the code space, making the test process information more coordinated, and fully obtaining the available information to lay the foundation for state weight calculation and message pool construction. The state selection algorithm is implemented by setting weights for each state using the state and message-aware mutation strategy, and a message pool for a specific state is constructed for subsequent message-level mutations, limiting the mutation position and generating high-quality message sequences for targeted testing of key states. Further experimental results show that after fuzz testing of protocol service programs such as Tinydtls and ProFTPD, compared with AFLNet and NSFuzz, the tool ZFuzz in the embodiment of this case can obtain higher edge coverage, more crash triggers and faster first crash triggers, has good feasibility and effectiveness, and has good application prospects in the field of network protocol testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 It is a schematic diagram of the dual information perception network protocol fuzzy testing process based on state variables in the embodiment;

[0037] Figure 2 This is a schematic diagram of the architecture of the test tool ZFuzz in the embodiment;

[0038] Figure 3 This is a schematic diagram of the process of mutation strategy 1 in the embodiment;

[0039] Figure 4 This is a schematic diagram of the mutation strategy 2 process in the embodiment. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solutions and advantages of the present invention clearer and more understandable, the present invention is further described in detail below in conjunction with the accompanying drawings and technical solutions.

[0041] Network protocols are important components in network communication systems, supporting interactive communication between different entities in the network. Their security deserves more attention and research. Fuzz testing is widely used in modern vulnerability mining due to its advantages such as high efficiency and low false alarm rate, and has achieved many results in the field of software security. Existing fuzz testing mainly targets local applications, and there are relatively few studies on fuzz testing of network protocols. Related fuzzers have some limitations, such as inaccurate state representation, inability to test key states, and lack of effectiveness of mutation strategies. To this end, the embodiments of the present invention, see Figure 1 As shown, a dual information perception network protocol fuzz testing method based on state variables is provided, comprising:

[0042] S101, statically analyzing the network protocol source code and identifying state variables in the source code, where the state variables are program variables that characterize the state of the network protocol.

[0043] Specifically, the source code can be statically analyzed, and the event processing loop can be obtained by using the call stack backtrace information when the protocol source code reads the message; the state variables in the source code are identified and marked, and a unique string identifier is assigned to each state variable, which is output in the form of a state list. The state variables include: event processing loop program variables, program variables read / written in message processing functions, enumeration / integer global variables written by constants, and member variables in structures.

[0044] The protocol program has clear phase characteristics during operation. Taking the TCP-based server protocol program as an example, its life cycle is roughly divided into three stages: service initialization stage, service processing stage, and cleanup stage. Based on this research, most of the work is concentrated on the service processing stage, processing and responding to request messages through network connections. In specific protocols, the processing stage usually uses an event processing loop. In this loop, the socket is used to read the request message, perform subsequent parsing and transaction processing, and then write the response message to the socket for communication. The protocol service program communicates with the client by continuously executing this loop until the connection is disconnected.

[0045] For stateful protocol programs, the state will be transferred multiple times when implementing event processing. Through extensive analysis, developers use enumeration types or integer constants to identify protocol states when implementing protocol programs. In addition, such variables exist in protocol programs as global variables or structure member variables.

[0046] Therefore, these key variables in the protocol program can characterize the protocol status. For example, when Bftpd receives a PASS request message, it will first determine whether the message can be processed in the current state. In the embodiment of this case, the password field in the request message is used as a parameter to call the processing function only after passing the status check, otherwise an error response will be returned directly. When the user completes the login and the password is correct, Bftpd will update the variable state, which is a global variable representing the status, and the updated variable is a member variable of the enumeration type. It is worth noting that this variable is always read or updated in the event processing loop. In addition, the solution of using program variables to represent the protocol status is more reasonable than using response codes. The response code returned by Bftpd in different states is 503, which cannot well represent the program process and distinguish the status.

[0047] To this end, the call stack backtrace information when reading the message from the protocol source code is used to obtain the event processing loop, which can be designed to include:

[0048] Set a breakpoint at the program input class system call;

[0049] In the network protocol service processing stage, if a breakpoint is triggered, the current protocol program function call stack information is used as auxiliary information to identify the event processing loop; and all loop structures containing I / O operations are collected, and a mapping relationship is established through the functions to which the loop structures belong;

[0050] Based on the stack backtrace information, all functions are matched layer by layer in the mapping relationship from the bottom function of the function call stack, and the loop structure contained in the first matched function is used as the event processing loop.

[0051] In the process of identifying the event processing loop, it is necessary to distinguish it from the loops of other network service programs, and exclude the interference of nested loops in the event processing loop. Therefore, the call stack backtrace information when the protocol program reads the message is used to identify the event processing loop. The event processing loop identification algorithm is shown in Algorithm 1.

[0052] First, when the network protocol program completes initialization and enters the service processing phase, a breakpoint is set at the input class system call in the program. When a subsequent message triggers a breakpoint, the current protocol program function call stack information is saved as auxiliary information for identifying loops. During the identification process, all loop structures containing I / O operations are collected and a mapping relationship is established with the functions to which they belong. Afterwards, based on the stack backtrace information, all functions are matched layer by layer from the bottom function of the function call stack in the mapping, and the loop structure contained in the first matched function is used as the event processing loop. This is because the call stack backtrace information only records the function calls in the service processing phase, which can avoid loop interference in the initialization phase. Moreover, bottom-up function matching identifies the outermost loop and eliminates the influence of nested loops.

[0053]

[0054]

[0055] Since static analysis lacks program runtime information, there may be false positives in the process of state variable identification. Based on the analysis of the protocol program, the characteristics of the state variables are summarized, and heuristic rules can be used to reduce false positives. The specific rules can be summarized as follows:

[0056] 1) The operation of state variables in the protocol program is always performed in the event processing loop, so only the program variables in this loop are analyzed to narrow the scope and reduce false alarms.

[0057] 2) Protocol state variables are read or written in the event processing loop or message processing function, so only the variables that are loaded and stored are recorded.

[0058] 3) Protocol state variables are usually global variables of enumeration type or integer type and member variables in structures, and are usually assigned constants. Therefore, only enumeration or integer global variables written by constants and member variables in structures are retained.

[0059] After the state variables are identified, a unique string identifier is assigned to each variable and output in a list form for use by subsequent tracking modules. However, for protocol programs developed based on event notification libraries, the event processing loop is usually in the library function, so this solution provides an auxiliary module for manual annotation. Using the annotation API to annotate key information can not only refine the identified state variables and implement state-sensitive operations of different granularities, but also accurately annotate state variables based on protocol knowledge.

[0060] S102. Track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and build a state machine based on the process states to map state space and code space. The process states are code state transitions based on changes in state variables.

[0061] Specifically, tracking and detecting changes in network protocol state variables by instrumenting the state variables may include:

[0062] Perform instrumentation on the state variable write operation in the network protocol source code, and map the write value of the state variable to the shared memory block between the fuzz test and the network protocol source code under test;

[0063] An XOR operation is performed on the hash value identified by the state variable string and the new value to be written, and the XOR value is used as an index for updating the shared memory block, so as to utilize the change of the shared memory block to record the state transfer process of the network protocol state variable.

[0064] In order to pass the value of the state variable to the fuzz tester in real time, the state variable write operation in the source code is instrumented during the compilation phase to facilitate subsequent state collection. At the same time, the written value of the state variable is mapped to the shared memory of the fuzz tester and the protocol program under test, and the shared memory block is recorded as share_state. The specific mapping calculation method can be expressed as follows:

[0065]

[0066] Among them, var_id represents the string identifier of the state variable, which is subsequently hashed. The hash value and the new value to be written are XORed, and the resulting XOR value is used as the index to update the shared memory block. At the same time, the index can be calculated based on the previous value of the state variable to restore the corresponding value in the shared memory. Different state variables will produce different hash values, which also correspond to different areas in the shared memory. Every time the value of the state variable changes, it will cause a change in the shared memory, thereby recording a more detailed state transfer process of the protocol program. The program after the stub will be processed as the final program to build a state machine model and perform mutation operations.

[0067] In the process of constructing the state machine, the current gray box fuzz tester usually uses simple feedback codes or unprocessed program variables, which lack the connection with the program code space. The two types of feedback information are relatively independent and cannot work well together to guide the fuzz test. In the embodiment of this case, the state machine M is structurally expanded, and an enhanced protocol state machine is designed to establish a mapping relationship between the state space and the program space, and the fine-grained program state represented by the program variables is used to add more process information between states.

[0068] First, expand the state machine M into a directed graph structure<S,E,∑:S→{re_mes}> , where ∑ is the mapping between recorded messages and corresponding states. If the program state is v before re_mes is sent, then the corresponding program variable var_id that has changed will be added to S, v→var_id will be added to E, and the mapping relationship will be added to ∑. Secondly, expand the state node to<depth,pnode,statetrans_paths,covered_bits,selscted_time,fuzzed_times> . Where, depth∈N represents the depth of the state; pnode∈S represents the forward state node of the state; statetrans_paths∈N represents the number of state transition paths explored when the state is in the state; covered_bits∈M represents the program bitmap covered by the state, and M is a two-dimensional matrix;

[0069] selected_times∈N represents the number of times the state is selected; fuzzed_times∈N represents the number of times the state is tested.

[0070] In the protocol state diagram, the current state node v∈S, its depth is recorded as the distance d(v,v0) to the entry node v0. Based on the research, the state node with a larger depth value is more difficult to explore. The shared memory block shared_state is collected based on the state variables. Each time the fuzz tester receives the plug-in feedback of the protocol under test, it will record the shared memory of the current program variables, organize and perform hash operations, and use the hash value at this time as the overall state of the current protocol program. Each hash value is stored in a queue. As request messages are continuously sent, a set of state sequences state_sequence is obtained after the test case is executed. By comparing different state sequences, the state variable identifier var_id corresponding to the shared memory block shared_state that has changed is obtained, and then the function unique is used to compare the number of different hash values, thereby obtaining statetrans_paths, i.e. unique(hash(var_id)).

[0071] statetrans_paths refers to the state transition path that can be found when a certain state v is selected. The larger the value, the more transition paths can be explored for the current state. Then the correlation between this state and other states is higher, which also means that this state is more important and deserves special attention. covered_bits represents the edge coverage bitmap that can be reached when exploring this state, and each state retains its own independent bitmap. During the fuzz test, the program coverage after the test case is executed in this state is recorded, and the bitmap coverage of each node of the state machine is calculated. As the test progresses, the mapping between the protocol program space and the state space is continuously improved.

[0072] From the above, we can get that for a known protocol state v, we can get the coverage covered_bits that can be triggered by the state. The larger the value, the larger the corresponding program space, and the greater the exploration value of the state. By supplementing the number of times the state is selected selected_times and the number of times it is tested fuzzed_times, we can balance state exploration and utilization and conduct tests more reasonably.

[0073] S103. Select the key state of the network protocol according to the state weight, build a message pool for the key state, and take the message as the unit, select, replace and cross-compile the message in the message pool according to the state and message perception to obtain the message variation, and generate a message sequence for generating test cases according to the message variation, so as to use the test cases to perform targeted tests on the key states of the network protocol. The message pool is all the protocol message combinations that enable the network protocol entity program to reach the key state.

[0074] Specifically, the key states of the network protocol are selected according to the state weight, which can be designed to include:

[0075] The state weight is calculated based on the depth of the state node, the number of state transition paths explored in the current state, the program bitmap covered by the current state, the number of times the state is selected, and the number of times the state is tested;

[0076] The state weight is used as the probability of the state being selected to obtain the key states of the network protocol for targeted testing in the best time.

[0077] In order to find the key state, a weight calculation method for the state is designed, and a heuristic algorithm is used to allocate energy to the key state. The weight calculation is based on the following understanding:

[0078] (1) The deeper the network communication level, the harder it is to test the code. The state has forward dependencies, and as the level of communication increases, the required message sequence becomes more difficult to construct, making it more difficult to fully test and more likely to have potential vulnerabilities.

[0079] (2) States located at key positions in the state machine are associated with more state transition paths, and exploring such states is more likely to trigger unknown coverage.

[0080] (3) The larger the program space affected by the state, the more complex the functions to be implemented will be. The larger the program space and the more complex the code implementation, the more difficult it will be to fully test it, so more attention should be paid to it.

[0081] (4) When exploring program states, it is necessary to consider the exploration of new states to avoid imperfect state machine structures.

[0082] Based on the above principles, for state v i , the calculation formula of its state weight can be expressed as:

[0083]

[0084] The calculated weight is used as the probability of the state being selected. The deeper the state is, the larger the associated path is, and the larger the corresponding program space is, the greater the weight value is. At the same time, states that are selected and tested many times will have response restrictions. In order to make it easier to calculate the selection time of high orders of magnitude, its order of magnitude is downgraded.

[0085] Among them, building a message pool of key status may include:

[0086] Construct a mutation message pool for each state, where the messages in the mutation message pool are high-value messages extracted from the interesting message sequences generated in the corresponding network protocol state. The interesting message sequences are target messages identified based on state transitions, code coverage, and the number of error handling times.

[0087] The message score is calculated based on the number of new states generated, the number of new branches triggered, and the execution time. The message with the message score is added to the message pool under the corresponding state to obtain the message pool for mutation of the corresponding key state.

[0088] This results in insensitivity to the message sequence and structure corresponding to the target state, resulting in poor results. In order to coordinate the protocol state and message structure, a mutation message pool is built for each state. The messages in it are all high-value message sets extracted from the interesting message sequence generated in the corresponding state.

[0089] Specifically, during the fuzz testing process, message sequences that improve state transfer, code coverage, and have fewer error handling times are identified as interesting message sequences. Then, a classification algorithm is used to extract messages at specific locations, and scores are calculated based on the message value formula. Then, messages with scores are added to the message pool in the corresponding state, thereby obtaining a message pool for mutation in a specific state.

[0090] Value=a*newState+b*newCovered+c*e-Time (4)

[0091] Where newState indicates the number of new states generated, newCovered indicates the number of new branches triggered, and Time indicates the execution time. The weights a, b, c∈{x|0≤x≤1}, and a+b+c=1, can be set according to the required ratio, usually a=0.4, b=0.3, c=0.3.

[0092] like Figure 2As shown in the figure, the architecture of the fuzz testing tool ZFuzz in this case mainly includes the identification and tracking part of the protocol state variables, the construction part of the protocol state machine, and the state selection and seed mutation part. In the identification and tracking part of the protocol state variables, the target program source code is processed through automated analysis and manual annotation API to obtain the event processing loop and state variable list of the protocol program. In the variable tracking stage, the compilation and instrumentation engine will first parse the manual annotation information, and then generate the corresponding information output, and at the same time, the target program is instrumented according to the state variable list. The fuzz tester can obtain both state feedback information and coverage feedback information during execution. In the construction part of the protocol state machine, the existing protocol gray box fuzz testing tools usually only contain simple state information for the construction of the protocol state machine model. For example, AFLNet uses the response code in the response message, and SGFuzz uses enumeration type variables as state variables but lacks filtering. As a result, the existing state machine has problems such as rough state, inaccurate representation, and only considers accessibility. In the actual state machine implementation process, there is no association information with the protocol program space, that is, the program state and code coverage are independent of each other and lack association and coordination. Therefore, the state machine building module is designed to expand the state machine structure, map the program space and the state space, and coordinate the protocol state variables to achieve more detailed state design and inter-process information improvement. In the state and information-aware mutation part, in the abstract layer of the protocol program, the upper area will directly or indirectly affect the exploration of the lower area. In the process of protocol fuzz testing, the first thing to be considered is the reasonable state, and then the corresponding seeds are scheduled. Therefore, this paper designs a state selection algorithm, calculates the weight for the protocol state, and uses a heuristic algorithm to allocate energy to the key state. After that, a message pool of interest is constructed for a specific state, and the messages at a specific location are extracted according to the state and information-aware scheme. The messages are scored using the value evaluation calculation formula to guide the subsequent seed mutation process.

[0093] In order to generate efficient message sequences, two new message-level mutation schemes are provided. Taking messages as units, selection and replacement are performed in the message pool without destroying the structure of the message and the order of the message sequence.

[0094] Mutation strategy 1: repeat, replace, and insert messages in the mutation message pool of a specific state. Figure 3 As shown, the mutation strategy is executed on high-value messages selected from the message pool of the target state S2.

[0095] Mutation strategy 2: crossover mutation. Figure 4 As shown, two message sequences that can both reach a specific state are selected, and crossover mutation is performed with the infix message as the endpoint to obtain a new message sequence that can reach the target state.

[0096] Furthermore, based on the above method, an embodiment of the present invention also provides a dual information perception network protocol fuzzy testing system based on state variables, comprising: a static analysis module, a state machine construction module and a targeted testing module, wherein:

[0097] A static analysis module, used to perform static analysis on the network protocol source code and identify state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol;

[0098] A state machine construction module is used to track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and construct a state machine based on the process states to map the state space and the code space, wherein the process state is a code state transition based on changes in state variables;

[0099] A targeted testing module is used to select key states of the network protocol based on state weights, build a message pool for key states, and select, replace and cross-compile messages in the message pool based on states and message perception to obtain message variations. A message sequence for generating test cases is generated based on the message variations, so as to use the test cases to perform targeted tests on key states of the network protocol. The message pool is a combination of all protocol messages that enable the network protocol entity program to reach the key state.

[0100] In order to verify the effectiveness of this solution, the following is a further explanation based on experimental data:

[0101] The experiment was conducted in a server with an Intel(R) CoreTM i7-8700 K@3.70GHz CPU and 32GB memory. The experiment proposed three indicators to test the performance of the tool, namely throughput, code edge coverage, and crash triggering. Widely used protocols were selected as benchmarks for testing, including RTSP, FTP, and DTLS. The service implementation programs of these protocols have been selected by related fuzz testing work and have undergone corresponding security analysis. The specific test program information is shown in Table 1.

[0102] Table 1 Test procedure information

[0103]

[0104] Using AFLNet and NSFuzz as benchmark programs, the selected target protocol program is tested to obtain edge coverage information and then evaluate the tool. The specific experiment uses the comparison tool and the tool ZFuzz in this embodiment to perform a 24-hour test to collect the code branch coverage of the same protocol program to be tested. The following Table 2 shows the final experimental results.

[0105] Table 2 Branch coverage

[0106] Target Agreement Program AFLNET NSFUZZ ZFuzz PureFTPD 983 1035 1152(17.19％、11.30％) ProFTPD 4650 4783 5182(11.44％、8.34％) Live555 2776 2803 2895(4.29％、3.28％) Exim 3588 3621 3770(5.07％、4.11％) Tinydtls 465 549 618(32.90％、12.57％)

[0107] From the data in this table, we can see that under the same test time and the same experimental environment, the solution ZFuzz can achieve higher code coverage on all targets to be tested. Code coverage is a common indicator in fuzz testing, which can indicate how much code is explored during the test. The higher the code coverage, the greater the probability of triggering a vulnerability.

[0108] In addition to the commonly used code coverage as an indicator, the crash triggering situation can also directly reflect the vulnerability mining effect of the tool. Table 3 and Table 4 show the crash situation of the target protocol during the fuzz testing process, including the number of triggered crashes and the first triggering time. When processing the crash situation, clustering is performed by the last instruction address of the crash, and then manual analysis is performed to determine the program vulnerability. In the actual analysis process, the same vulnerability may trigger a crash at different instruction addresses, so the number of crashes generated will be higher than the number of vulnerabilities.

[0109] Table 3 Crash triggering conditions

[0110] Target Agreement Program AFLNET NSFUZZ ZFuzz Live555 4 4 6 Tinydtls 2 4 7

[0111] From the table, we can see that compared with the control tools, ZFuzz can trigger more crashes and can cover the crashes triggered by other tools. For the same target and in the same environment, ZFuzz can achieve better results.

[0112] Table 4 First crash trigger time

[0113] Target Agreement Program AFLNET NSFUZZ ZFuzz Live555 756s 96s 20s Tinydtls 26s 5s <1s

[0114] In terms of the first trigger crash time, the tool in this case solution can trigger the crash faster. In particular, when testing the Tinydtls protocol program, the crash can be triggered in less than 1 second.

[0115] The above experiments show that the ZFuzz tool in this solution can find more crashes and trigger crashes faster during fuzz testing, so it has better vulnerability mining capabilities and is generally more effective.

[0116] Unless otherwise specifically stated, the relative steps, numerical expressions and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present invention.

[0117] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0118] The units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods to implement the described functions for each specific application, but such implementation is not considered to be beyond the scope of the present invention.

[0119] Those skilled in the art will appreciate that all or part of the steps in the above method can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk or an optical disk. Optionally, all or part of the steps in the above embodiment can also be implemented using one or more integrated circuits, and accordingly, each module / unit in the above embodiment can be implemented in the form of hardware or in the form of software function modules. The present invention is not limited to any specific form of combination of hardware and software.

[0120] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A dual information-aware network protocol fuzz testing method based on state variables, characterized in that: Include: Performing static analysis on the network protocol source code and identifying state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol; Track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and build a state machine based on the process states to map state space and code space, wherein the process states are code state transitions based on changes in state variables; The key state of the network protocol is selected according to the state weight, and a message pool of the key state is constructed. The messages are selected, replaced and cross-compiled in the message pool according to the state and message perception to obtain message variations. A message sequence for generating test cases is generated according to the message variations, so as to use the test cases to perform targeted tests on the key states of the network protocol. The message pool is all protocol message combinations that enable the network protocol entity program to reach the key state.

2. The dual information perception network protocol fuzz testing method based on state variables according to claim 1 is characterized in that: Perform static analysis on the network protocol source code and identify state variables in the source code, including: Perform static analysis on the source code and obtain the event processing loop using the call stack backtrace information when reading messages from the protocol source code; The state variables in the source code are identified and annotated, and a unique string identifier is assigned to each state variable, which is output in the form of a state list. The state variables include: event processing loop program variables, program variables read / written in message processing functions, enumeration / integer global variables written by constants, and member variables in structures.

3. The dual information-aware network protocol fuzz testing method based on state variables according to claim 2 is characterized in that: The call stack backtrace information when reading messages using the protocol source code is used to obtain the event processing loop, including: Set a breakpoint at the program input class system call; In the network protocol service processing stage, if a breakpoint is triggered, the current protocol program function call stack information is used as auxiliary information to identify the event processing loop; And collect all loop structures containing I / O operations, and establish mapping relationships through the functions to which the loop structures belong; Based on the stack backtrace information, all functions are matched layer by layer in the mapping relationship from the bottom function of the function call stack, and the loop structure contained in the first matched function is used as the event processing loop.

4. The dual information-aware network protocol fuzz testing method based on state variables according to claim 1 is characterized in that: Track and detect changes in network protocol state variables by instrumenting them, including: Perform instrumentation on the state variable write operation in the network protocol source code, and map the write value of the state variable to the shared memory block between the fuzz test and the network protocol source code under test; An XOR operation is performed on the hash value identified by the state variable string and the new value to be written, and the XOR value is used as an index for updating the shared memory block, so as to utilize the change of the shared memory block to record the state transfer process of the network protocol state variable.

5. The dual information perception network protocol fuzz testing method based on state variables according to claim 1 is characterized in that: Build a state machine based on the process state to map the state space and code space, including: A state machine is constructed based on feedback codes or state variables, and the state machine is expanded into a directed graph structure, and the state nodes are expanded into a six-tuple representation, so as to establish a mapping relationship between the state space and the code space using the directed graph structure; Among them, the directed graph structure is expressed as<S,E,∑:S→{re_mes}> , S is the set of protocol states, E is the set of states and corresponding program variables, ∑ is the mapping between recorded messages and corresponding states, re_mes is the request message, and the six-tuple of state nodes is represented as<depth,pnode,statetrans_paths,covered_bits,selscted_time,fuzzed_times> , depth represents the depth of the state node; pnode represents the forward state node of the state node; statetrans_paths represents the number of state transition paths explored in the current state; covered_bits represents the program bitmap covered by the current state; selected_times represents the number of times the state is selected; fuzzed_times represents the number of times the state is tested.

6. The dual information-aware network protocol fuzz testing method based on state variables according to claim 1 is characterized in that: Select the key status of the network protocol based on the status weight, including: The state weight is calculated based on the depth of the state node, the number of state transition paths explored in the current state, the program bitmap covered by the current state, the number of times the state is selected, and the number of times the state is tested; The state weight is used as the probability of the state being selected to obtain the key states of the network protocol for targeted testing in the best time.

7. The dual information-aware network protocol fuzz testing method based on state variables according to claim 1 or 6, characterized in that: Build a message pool for key states, including: Construct a mutation message pool for each state, where the messages in the mutation message pool are high-value messages extracted from the interesting message sequences generated in the corresponding network protocol state. The interesting message sequences are target messages identified based on state transitions, code coverage, and the number of error handling times. The message score is calculated based on the number of new states generated, the number of new branches triggered, and the execution time. The message with the message score is added to the message pool under the corresponding state to obtain the message pool for mutation of the corresponding key state.

8. A dual information-aware network protocol fuzzy testing system based on state variables, characterized in that: Contains: static analysis module, state machine construction module and targeted testing module, among which, A static analysis module, used to perform static analysis on the network protocol source code and identify state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol; A state machine construction module is used to track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and construct a state machine based on the process states to map the state space and the code space, wherein the process state is a code state transition based on changes in state variables; A targeted testing module is used to select key states of the network protocol based on state weights, build a message pool for key states, and select, replace and cross-compile messages in the message pool based on states and message perception to obtain message variations. A message sequence for generating test cases is generated based on the message variations, so as to use the test cases to perform targeted tests on key states of the network protocol. The message pool is a combination of all protocol messages that enable the network protocol entity program to reach the key state.

9. An electronic device, characterized in that: include: at least one processor, and a memory coupled to the at least one processor; The memory stores a computer program, and the computer program can be executed by the at least one processor to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 7 can be implemented.

Images