VxWorks transport layer protocol fuzz testing method based on feature tracking

Abstract

The present invention discloses a VxWorks transport layer protocol fuzz testing method based on feature tracking. This method performs consistency checks on the message response flag features of the transport layer TCP protocol of the closed-source operating system VxWorks, thereby driving seed iterative mutation and dynamically guiding the fuzz testing process. A progressive fuzzification method that fuses feature relationships between messages is used to construct test cases with high acceptance rates and high complexity. A dual anomaly detection mechanism that combines client connection detection with system anomaly task detection based on WDB RPC is used to determine and detect abnormal states during the fuzz testing process. The present invention implements a lightweight, practical, and efficient fuzz testing method for the TCP protocol of the VxWorks operating system.

Description

Technical Field

[0001] The present invention relates to the technical field of network protocol security of embedded real-time operating systems, and in particular to a VxWorks transport layer protocol fuzz testing method based on feature tracking. Background Art

[0002] The rapid development of IoT and network technologies has made human life more convenient. Smart homes are bringing convenience to most people, and healthcare systems are crucial for patients. Furthermore, the Industrial Internet of Things (IIoT), which refers to the network of interconnected devices in the industrial sector, has attracted considerable attention in the era of the Fourth Industrial Revolution. Most of these IoT devices are embedded systems with firmware and various applications. However, with these advances, the security threats posed by software vulnerabilities in embedded systems are also increasing. For example, the Mirai malware infected millions of IoT devices and commanded them to launch large-scale cyberattacks. As a result of these attacks, hundreds of thousands of web servers worldwide suffered denial of service. These attacks exploited software vulnerabilities in the embedded device firmware, which can be discovered using carefully designed embedded fuzz testing techniques. With the increasing number of attacks targeting embedded devices, fuzz testing techniques for embedded system vulnerabilities warrant research attention.

[0003] VxWorks is a componentized, highly reliable, and real-time embedded operating system developed by Wind River. Due to its high reliability and real-time performance, VxWorks is widely used in a variety of fields, including aviation, aerospace, healthcare, communications, and industry. The VxWorks system boasts flexible interrupt management, efficient task scheduling, and real-time task processing, making it a globally recognized embedded operating system for security. However, even the most secure software can still have security issues. In 2019, Armis researchers discovered 11 zero-day vulnerabilities in VxWorks, dubbed URGENT / 11. These vulnerabilities, located in the IPnet and TCP / IP stacks, affected versions of VxWorks dating back 13 years and were a rare example of vulnerabilities discovered that affect operating systems.

[0004] Fuzz testing is an automated testing method that uses random data (from files, network protocols, API calls, etc.) as software input to generate a large number of test cases to identify exploitable vulnerabilities. Although fuzz testing is an effective technique for automatically detecting software vulnerabilities, its direct application to embedded systems with strong hardware dependencies is challenging. Currently, automated network protocol vulnerability detection techniques for the VxWorks operating system all use fuzz testing as their core technology. In 2015, Yannick Formaggio proposed VxMon, a VxWorks target host debugging tool based on the Sulley fuzz testing framework; in 2016, the 404 Security Team at Knowsec further improved the VxWorks operating system testing tool based on Formaggio's fuzz testing ideas; and in 2019, Wei Zheng et al. implemented a VxWorks fuzz testing system using dynamic symbolic execution through memory monitoring. These are all fuzz testing techniques for VxWorks' application-layer protocols. Fuzz testing of application-layer protocols often uses sockets to encapsulate data, making data transmission and reception more convenient. However, fuzz testing of transport layer protocols cannot utilize mature sockets for sending and receiving data. Instead, it is necessary to construct each data packet sent and process each response independently. In 2021, Wang Yuchao proposed a VxWorks firmware network protocol fuzz testing technology based on binary static instrumentation. Although it can perform fuzz testing on transport layer protocols, its implementation is too complex to be used directly.

[0005] The Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol defined by the IETF's RFC 793. In the simplified OSI model of computer networks, it performs the functions specified by the fourth layer, the transport layer. In the Internet protocol suite, the TCP layer is an intermediate layer located above the IP layer and below the application layer. Application layers between different hosts often require reliable, pipe-like connections, but the IP layer does not provide such a streaming mechanism. The application layer sends an 8-bit byte data stream to the TCP layer for transmission across the internet. TCP then segments the data stream into segments of appropriate lengths. TCP then passes the resulting packets to the IP layer, which delivers them across the network to the TCP layer at the receiving entity. To prevent packet loss, TCP assigns each packet a sequence number. This sequence number also ensures that packets are received in order. The receiving entity then sends an acknowledgment (ACK) for each successfully received packet. At the same time, TCP uses a checksum function to verify data for errors, and the checksum must be calculated during both sending and receiving. Therefore, the TCP protocol has a characteristic relationship between messages, that is, every two messages must satisfy the appropriate IP address, port number, logical sequence number (i.e., within the window), and correct checksum. For example, the confirmation sequence number of the current message must be equal to the sum of the sequence number and data length of the previous message to be a correct confirmation sequence number. In a TCP connection, only messages with the appropriate IP address, port number, logical sequence number (i.e., within the window), and correct checksum can be received by the other party. However, the fuzzification methods currently used in the field of network protocol fuzz testing are difficult to apply to the TCP protocol. They do not consider the characteristic relationship between TCP messages, and the TCP protocol test cases they generate have a low acceptance rate. Most of them are directly discarded by the test object without any processing, resulting in reduced efficiency of fuzz testing of the TCP protocol.

[0006] The WDB RPC protocol is a proprietary protocol used by target servers and target agents (VxWorks target machines) for communication debugging. It is based on the SUN RPC standard and uses the UDP (User Datagram Protocol) protocol as the transport layer protocol. The WDB RPC protocol service is designated to run on port 17185 of the UDP protocol. The VxWorks operating system includes a WDB (Wi nd Debug) target agent tool, a target-resident runtime tool that is essential for connecting a host tool to a VxWorks target system. The primary purpose of developing WDB is to facilitate VxWorks application developers in debugging applications on the VxWorks target system, executing requests transmitted from the host-based debugging tool and responding to the corresponding results. The WDB RPC protocol is the proprietary protocol used to implement this functionality. Therefore, the present invention utilizes the WDB RPC protocol to not only access VxWorks system memory but also detect abnormal conditions in VxWorks system tasks.

[0007] In summary, the TCP protocol in the VxWorks operating system has design flaws and potential vulnerabilities. However, existing vulnerability detection technologies for VxWorks operating system network protocols mostly focus on application-layer protocols and are not applicable to transport-layer protocols. Fuzz testing technologies that can perform transport-layer testing on VxWorks operating systems rely on binary code instrumentation, which is complex to implement. Furthermore, due to the unique nature of the feature relationships between TCP messages, test cases generated using traditional fuzzing methods have a low acceptance rate, which in turn reduces the efficiency of fuzz testing of the TCP protocol. Summary of the Invention

[0008] The purpose of the present invention is to provide a VxWorks transport layer protocol fuzz testing method based on feature tracking, aiming to solve the problems that existing network protocol fuzz testing methods cannot efficiently fuzz test the TCP protocol and the fuzz testing process lacks guidance.

[0009] To address the above issues, this paper takes the TCP protocol of VxWorks as the research object, explores how to conduct lightweight, efficient, and practical fuzz testing of the TCP protocol, and proposes a VxWorks transport layer protocol fuzz testing method based on feature tracking. Compared with existing VxWorks network protocol fuzz testing technologies, this paper's innovations lie in:

[0010] (1) This invention is a lightweight technology for vulnerability fuzz testing of the TCP protocol in the VxWorks network transport layer, which does not require the configuration of complex code instrumentation environments. During the fuzz test preparation process, the user only needs to enter the IP address and port number corresponding to the TCP service of the test object;

[0011] (2) The test case fuzzification method used in the present invention is based on the characteristic relationship between TCP messages. Compared with traditional test case fuzzification methods, the test cases generated by the present invention can be correctly transmitted to the test object and fully received by the test object;

[0012] (3) The present invention uses TCP message feature tracking to dynamically guide the fuzz testing process, which can drive seed mutation and solve the problem of lack of guidance when fuzz testing the TCP protocol;

[0013] (4) The present invention combines client heartbeat detection with system abnormality task detection based on WDB RPC to implement a dual abnormality detection mechanism, which can more comprehensively detect abnormal conditions of the test object during the TCP protocol fuzz testing process and improve the network protocol abnormality detection mechanism of VxWorks.

[0014] The VxWorks transport layer protocol fuzz testing method based on feature tracking of the present invention is specifically implemented according to the following steps:

[0015] Step 1, preprocessing: Activate the TCP server state to be tested and determine the FLAGS flag of the current test case based on the test state;

[0016] Step 2: Start the dual anomaly detection mechanism: start the client connection detection mechanism implemented by sending heartbeat packets using the client program and the system abnormal task detection mechanism implemented by using the WDB RPC protocol;

[0017] Step 3: Generate and send a test case set: Construct an initial corpus based on the FLAGS flags of the test cases determined in the preprocessing phase; then fuzzify the initial corpus using a progressive fuzzification method that fuses feature relationships between messages to generate a test case set;

[0018] Step 4, test object status monitoring and anomaly detection: After each test case is sent to the test object, the client connection detection mechanism sends a heartbeat packet to the test object to determine whether the TCP connection is online; at the same time, the system abnormal task detection mechanism uses the WDB_EVENT_GET function to detect whether the VxWorks system has any network task processing anomalies;

[0019] Step 5: Consistency check of the flag features of the response message: Extract the TCP flag feature value of the response message of the test object in each round of testing, and then compare and analyze the consistency of the TCP flag feature value with the expected value; if the TCP flag feature value does not match the expected value, the test case of this round of fuzz testing is classified as a seed;

[0020] Step 6: TCP feature-driven seed iteration generates new test cases: First, locate the abnormal field of the seed obtained in step 5, and then iteratively mutate other fields of the seed except the abnormal field to generate new test cases covering multiple fields at the same time;

[0021] Step 7, exception handling and environment recovery: When the client connection detection mechanism in step 4 is abnormally disconnected, the test case that caused the abnormal disconnection of the client will be saved in PCAP format and logged at the same time; when the system abnormal task detection mechanism discovers the VxWorks system abnormal event, the register group content and memory content at the abnormal task breakpoint will be extracted and saved using the WDB_REGS_GET and WDB_MEM_READ function functions, and finally the WDB_CONTEXT_KILL function function will be used to implement hot restart environment recovery of the test object;

[0022] Step 8: If the test case is not completed or the time threshold is not reached, the test continues. When the fuzz test is completed, the results of this fuzz test are statistically output.

[0023] Preferably, the step 1 is specifically implemented according to the following steps:

[0024] Step 1.1, TCP service state activation: Based on the current state of the TCP server to be tested, construct a data packet that can trigger the state and send the data packet to the test object to activate the state of the TCP server to be tested;

[0025] Step 1.2, test case FLAGS flag determination: Each state of the TCP server will receive a specific FLAGS flag, determine the FLAGS flag that the test case needs to set.

[0026] Preferably, step 2 is specifically implemented according to the following steps:

[0027] Step 2.1: Establish a TCP connection between the client program and the TCP service of the test object;

[0028] In step 2.2, the host agent is implemented using the WDB RPC protocol, and then the WDB_TARGET_CONNECT2 function with the integer identifier 122 in the WDB RPC protocol is used to create a connection request packet. The connection is established with the 17185 port service of the VxWorks operating system through the request packet.

[0029] Preferably, step 3 is specifically implemented according to the following steps:

[0030] Step 3.1, by setting the TCP flag field to other FLAGS flags different from the FLAGS flag and their combinations, constructing the initial corpus of the state test phase; setting the TCP flag field to the FLAGS flag, constructing the initial corpus of the state transition test phase;

[0031] Step 3.2: Extract the value of the characteristic relationship field from the TCP message responded to when the TCP server state to be tested is activated in step 1.1; then, calculate the value of the characteristic relationship field required to be set for the test case based on the characteristic relationship between the TCP messages;

[0032] Step 3.3: Fuzzify the regular fields of the initial corpus using a progressive fuzzification method. The fuzzification of the regular fields of the TCP protocol is based on the value range of each regular field. Each field is assigned a progressive value from empty to out-of-bounds to generate different test case sets.

[0033] Step 3.4: Fuzzify the option fields of the initial corpus using a two-layer cross-fuzzification method. The fuzzification of the TCP protocol option fields is done by mutating the option values ​​of the option fields at the bottom layer and the option tuple positions of the option fields at the top layer, thereby generating different test case sets.

[0034] In step 3.5, the value of the feature relationship field obtained in step 3.2 is merged with the test case set generated by mutation in step 3.4 to form a complete test case set, and then the merged test case set is sent to the test object to start fuzz testing.

[0035] Preferably, step 5 is specifically implemented according to the following steps:

[0036] Step 5.1: Extract the FLAGS flag feature value in the TCP message from the response message received from the test object after each round of test case sending;

[0037] In step 5.2, the extracted FLAGS flag feature value is compared with the expected value. If the two values ​​are the same, the next round of testing is continued. If they are different, the test cases of this round are classified as seeds, and the seeds are subsequently mutated to generate new test cases.

[0038] Preferably, step 6 is specifically implemented according to the following steps:

[0039] Step 6.1, locating abnormal fields in the test case that caused the unexpected response flag to be received by comparing the regular fields and option fields of the seed with the default values ​​in sequence;

[0040] In step 6.2, the seed iteration mutation is as follows: retain the abnormal field of the seed, and then use the Cartesian product combination iteration method to assign values ​​to other fields outside the abnormal field to generate new test cases that cover multiple field domains at the same time.

[0041] Preferably, the double anomaly detection mechanism in step 2 is specifically as follows:

[0042] The dual anomaly detection mechanism consists of a TCP service connection detection mechanism implemented by a TCP client program and a system abnormal task detection mechanism implemented using the WDB RPC protocol. The dual anomaly detection mechanism can simultaneously detect the reliability of TCP service connections and task anomalies in the VxWorks operating system. It is used to detect fluctuations in TCP connections during fuzz testing and discover denial of service anomalies. It is also used to detect the operating system's network task processing during the fuzzing process and discover stack overflow anomalies.

[0043] Preferably, the step 3 further includes:

[0044] The step 3.1 is specifically as follows:

[0045] The initial corpus of the state test phase is constructed by setting the TCP flag field of the test case to other flags and their combination values ​​that are different from the FLAGS flag determined in step 1.2, thereby fuzz testing the TCP service state operation process;

[0046] The initial corpus construction in the state transition test phase is to set the TCP flag field of the test case to the FLAGS flag determined in step 1.2, and then perform fuzz testing on the TCP service state transition process;

[0047] The step 3.2 is specifically as follows:

[0048] Extract the source port, destination port, data sequence number, and acknowledgment sequence number from the TCP message responded to when the TCP server status to be tested is activated in step 1.1.

[0049] The value of the characteristic relationship field that needs to be set for the test case is calculated based on the characteristic relationship between TCP messages; the destination port and source port of the test case are the source port and destination port of the response message respectively, the data sequence number of the test case is equal to the confirmation sequence number of the response message, and the confirmation sequence number is equal to the sum of the sequence number of the response message and its data length. Finally, the value of the packet checksum is calculated in combination with the values ​​of other variation fields.

[0050] Preferably, the step 3.4 is specifically as follows:

[0051] When mutating the option field of the TCP protocol, the two-layer cross-fuzzification method adopted is divided into the bottom-level option value mutation and the upper-level option tuple position mutation; the bottom-level mutation is to perform bit flipping, insertion, replacement or deletion mutation on the option value in the same type of option tuple based on the initial value. At the same time, in order to increase the complexity of fuzzification, the mutation based on the initial value is looped for the initial length of the option and then assigned to the original type of option; the upper-level mutation is to perform mutations such as copying, crossing or position replacement based on the entire tuple on the option tuple obtained after the bottom-level mutation to obtain an option set; finally, this option set is assigned to the option field of the TCP protocol to generate test cases.

[0052] Preferably, the step 6.2 is specifically as follows:

[0053] Establish value sets for other fields except the abnormal fields of the seed, wherein the other fields are regular fields and option fields excluding the feature relationship fields; the specific content in each field value set is a pre-set special value;

[0054] The iterative mutation method for seeds is to keep the values ​​of the abnormal fields of the seeds unchanged, and the values ​​of other fields are based on the Cartesian product idea. Values ​​are taken from the value sets of each field in turn for combined iteration, thereby generating new test cases that cover multiple field domains at the same time.

[0055] Compared with the existing VxWorks network protocol fuzz testing technology, the innovation of this invention lies in:

[0056] (1) This invention is a lightweight technology for vulnerability fuzz testing of the TCP protocol in the VxWorks network transport layer, which does not require the configuration of complex code instrumentation environments. During the fuzz test preparation process, the user only needs to enter the IP address and port number corresponding to the TCP service of the test object;

[0057] (2) The test case fuzzification method used in the present invention is based on the characteristic relationship between TCP messages. Compared with traditional test case fuzzification methods, the test cases generated by the present invention can be correctly transmitted to the test object and fully received by the test object;

[0058] (3) The present invention uses TCP message feature tracking to dynamically guide the fuzz testing process, which can drive seed mutation and solve the problem of lack of guidance when fuzz testing the TCP protocol;

[0059] (4) The present invention combines client heartbeat detection with system abnormality task detection based on WDB RPC to implement a dual abnormality detection mechanism, which can more comprehensively detect abnormal conditions of the test object during the TCP protocol fuzz testing process and improve the network protocol abnormality detection mechanism of VxWorks.

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

[0061] The present invention's feature-tracking-based VxWorks transport layer protocol fuzz testing method is a lightweight vulnerability mining technology for the transport layer TCP protocol of the VxWorks operating system. It aims to address the problems of existing network protocol fuzz testing methods that cannot efficiently fuzz test the TCP protocol and lack guidance during the fuzz testing process. This method constructs protocol test cases through a progressive fuzzification method that integrates feature relationships between messages, ensuring that the test cases are fully received by the test object, solving the problems of difficult data transmission and insufficient test case coverage during the fuzz testing process. The TCP feature-driven seed iteration method can perform continuous and in-depth iterative testing on the TCP protocol, solving the problems of insufficient test depth coverage and lack of guidance during the fuzz testing process. The dual anomaly detection mechanism, which combines client connection detection with system abnormality task detection implemented by the WDB RPC protocol, can help more comprehensively detect anomalies during the TCP protocol fuzz testing process, solving the problems of missing anomalies and incomplete detection by a single detection mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0063] Figure 1 This is a flowchart of the implementation of the VxWorks transport layer protocol fuzz testing method based on feature tracking of the present invention;

[0064] Figure 2 A diagram showing the fields of the TCP protocol header.

[0065] Figure 3 This is an architecture diagram of the dual anomaly detection mechanism in the VxWorks transport layer protocol fuzz testing method based on feature tracking of the present invention;

[0066] Figure 4The VxWorks transport layer protocol fuzz testing method based on feature tracking of the present invention triggers a VxWorks system integer overflow exception during the fuzz testing process;

[0067] Figure 5 This is a test case when the VxWorks transport layer protocol fuzz testing method based on feature tracking of the present invention causes a VxWorks integer overflow crash. DETAILED DESCRIPTION

[0068] To make the technical solutions and advantages of the present invention more clear, the technical solutions of the present invention will be described in detail below. Obviously, the following description is only a part of the implementation examples of the present invention, rather than all implementation examples. The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0069] The present invention is a VxWorks transport layer protocol fuzzy testing method based on feature tracking, the flow chart is as follows Figure 1 As shown, please follow the steps below:

[0070] Step 1: After the present invention is started, it first performs preprocessing, selects and activates the TCP server state to be tested, and determines the FLAGS (flags field of the TCP protocol) flag of the current test case based on the test state. The specific process is as follows: the protocol state to be tested on the TCP protocol server of the VxWorks operating system is selected in sequence. The TCP server state includes six states: CLOSED (service closed state), LI STEN (listening state, the server waits for any TCP connection request), SYN_RCVD (the server has received a synchronization signal and sent a synchronization signal to the client, waiting for the client's confirmation request), ESTABLISHED (the server and client are connected and start sending data), CLOSE_WAIT (after the passive closing end receives a FIN, it sends an ACK in response to the FIN request and enters a semi-closed state waiting for the local user's connection termination request), and LAST_ACK (after the passive closing end completes sending all data, it sends a FIN to the active closing end and enters a state waiting for an acknowledgment packet). The process of state transition is as follows: After the TCP / IP protocol stack is initialized, it will change from CLOSED to LISTEN. After LISTEN receives a SYN message, it will change to SYN_RCVD. Then, after SYN_RCVD receives an ACK message, it will change to ESTABLISHED. After ESTABLISHED receives a FIN message, it will change to CLOSE_WAIT. Finally, after sending a FIN message, CLOSE_WAIT will change to LAST_ACK and finally return to the CLOSED state. The CLOSED state is not a real state, but an imaginary starting point or end point. Therefore, the present invention performs vulnerability fuzz testing on the other five TCP server states in turn. Taking the test of the ESTABLISHED state as an example, the Scapy framework is first used to construct a state activation use case, that is, to construct a client data packet of the TCP three-way handshake, thereby activating the TCP service of the test object VxWorks and entering the ESTABLISHED state. When the ESTABLISHED state receives a FIN message, it will transition to the CLOSE_WAIT state. Therefore, it can be determined that the FLAGS flag of the test case that triggers the ESTABLISHED state transition is FIN.

[0071] Step 2, start the dual anomaly detection mechanism. First, start the client connection detection mechanism, use the TCP client program to establish a TCP connection with the TCP service of the VxWorks operating system on the tested service port, and send a heartbeat packet every 3 seconds to keep the connection online. At the same time, start the system abnormal task detection mechanism implemented by the WDB RPC protocol of the VxWorks system. The system abnormal task detection mechanism will act as a HOST (host agent) agent to establish a connection with the 17185 port service of the VxWorks operating system. The system abnormal task detection mechanism first uses the WDB_TARGET_CONNECT2 function with an integer identifier of 122 in the WDB RPC protocol to create a connection request packet to establish a connection with the VxWorks operating system, and then maintain a mechanism similar to Session (connection session object) between each other to maintain the connection status.

[0072] Step 3, generation and sending of test case set. According to the FLAGS flag of the test case determined in the preprocessing stage, the test process of the same protocol state can be divided into two stages: state test and state transition test. The initial corpus is constructed for the state test stage by setting the flag field of the test case to other flags other than the FLAGS flag, and the initial corpus is constructed for the state transition test stage by setting the flag field of the test case to the FLAGS flag. The initial corpus is then fuzzified to generate test cases. The present invention generates test cases by fuzzifying the header field of the TCP protocol, and the fuzzification is a progressive fuzzification method that fuses the feature relationships between messages. Figure 2As shown, the TCP header is divided into regular fields and optional fields, wherein the regular fields include characteristic relationship fields such as port number, data sequence number, confirmation sequence number and checksum. The value of the characteristic relationship field comes from the message responded when the TCP service reaches the test state by activating the use case in the preprocessing stage of step 1. By calculating the response message using the characteristic relationship between TCP messages, data such as the port number and sequence number received by the test object can be obtained. The present invention fuzzifies the protocol field, that is, sets the value of the field to different values ​​that are consistent with the field data type. First, the regular fields of the TCP protocol are fuzzified by generating different test case sets by progressively assigning values ​​from empty to out of bounds based on the value range of each field. A double-layer cross-fuzzification method is used to generate test cases for the option fields of the TCP protocol. The double-layer cross-fuzzification is divided into the bottom-layer option value variation and the upper-layer option tuple position variation. The underlying mutation involves bit-flipping, inserting, replacing, or deleting option values ​​within an option tuple of the same type based on the initial value. To increase the complexity of the fuzzification, the initial value-based mutation loops through the initial length of the option before assigning the value to the original option. The upper-level mutation fuzzifies the option tuple obtained after the underlying mutation by copying, crossing, and replacing the entire tuple. This fuzzification generates an option set, which is assigned to the option field to generate different test cases. Finally, the calculated feature relationship field is merged with the generated test case, and the merged test case is sent to the test object to begin testing.

[0073] Step 4, test object status monitoring and anomaly detection. After each test case is sent to the test object in step 3, the test object status will be detected through the dual anomaly detection mechanism. The client connection detection mechanism will make a data request to the TCP server of the VxWorks operating system through the TCP client program to determine whether the TCP connection is online, thereby detecting the TCP denial of service. At the same time, the system abnormal task detection mechanism implemented by the WDB RPC protocol will send an abnormal task detection request to the VxWorks system through the abnormal detection packet created by the WDB_EVENT_GET function with an integer identifier of 70 in the Session connection similar to that established in step 2, so as to detect whether the test object has a network task processing abnormality.

[0074] Step 5, check the consistency of the flag features of the response message. After each test case is sent in step 3, the message responded by the test object is received. The received message is then analyzed, the TCP flag feature value of the response is extracted, and then the value is compared with the expected value for consistency. The source of the expected value is the current test state of the test object, and the value of the TCP flag of the response message when receiving a normal message. Therefore, when the flag feature value of the response message is checked for consistency during the fuzz test process, if it is found that it does not match the expected value, the test case of this round of fuzz testing is classified as a seed to guide the generation of subsequent test cases.

[0075] In step 6, the TCP feature drives the seed to iterate and generate new test cases. The abnormal fields of the seed obtained in step 5 are first located. By comparing the values ​​of each field of the seed with the default value in turn, the abnormal field that causes the reception of the unexpected response flag is located. After locating the abnormal field of the seed, the seed is iteratively mutated. The iterative mutation is to retain the abnormal field value of the seed while taking the Cartesian product combination of iterative assignment for other fields to generate test cases that can cover multiple field domains at the same time. After the seed is iteratively mutated, a large number of new test cases can be generated. These test cases can cover the situation where different field domains jointly trigger anomalies.

[0076] Step 7, exception handling and environment recovery. When the exception detection mechanism in step 4 detects an exception, it will save and record the relevant information of the exception, and restore the environment after the exception. When the TCP client program finds that the connection is disconnected, it will first save the test case that caused the abnormal connection disconnection in PCAP (storage format of the original datagram), and use the logging function to record the abnormal disconnection; when the WDB RPC system abnormal task detection mechanism finds that an abnormal event has occurred in the VxWorks system, it will use the WDB_REGS_GET and WDB_MEM_READ functions implemented by the WDB RPC protocol to extract and save the register group content and memory content at the abnormal task breakpoint respectively. After the relevant information at the time of the exception is extracted, the abnormal environment needs to be restored to the initial test environment. The WDB_CONTEXT_KI LL function in the WDB RPC protocol is used to initiate a hot restart operation to the test object, and the test environment recovery is completed by restarting the VxWorks operating system.

[0077] Step 8: Determine whether the fuzz test is complete. If the test case has not been fully executed or the set time threshold has not been reached, the test continues. When the fuzz test is completed, the results of this fuzz test are statistically output. This mainly includes the number of test cases during the fuzz test, the number of test object crashes (system crashes), and the number of abnormal TCP connection disconnections.

[0078] like Figure 3 The figure shows the architecture of the dual anomaly detection mechanism in the present invention. First, the client connection detection mechanism and the system anomaly task detection mechanism, implemented using the WDB RPC protocol, establish a connection with the VxWorks operating system. The client connection detection mechanism establishes a TCP connection with the VxWorks TCP service via the TCP client program. The system anomaly task detection mechanism establishes a Session-like connection with the WDB agent of the VxWorks system via the WDB_TARGET_CONNECT2 function, function number 122. Each time a test case is sent, the client connection detection mechanism sends a TCP data request to determine the connection status. The anomaly task detection mechanism then requests the system task status via the WDB_EVENT_GET function, function number 70, to detect whether the system has an anomaly. During the fuzz testing process, when the client connection detection mechanism detects that the connection is abnormally disconnected, it will save the test case data packet that caused the disconnection and make corresponding log records; when the system abnormal task detection mechanism detects that the test object has a task abnormality, it first requests the WDB_REGS_GET function with function number 40 and the WDB_MEM_READ function with function number 10 to obtain the register group and memory content at the abnormal breakpoint of the test object, and then extract and save them. Finally, a hot restart request is initiated through the WDB_CONTEXT_KI LL function with function number 31 to complete the recovery of the test environment.

[0079] like Figure 4 As shown, during the fuzzy test of the ESTABL I SHED state of the TCP protocol, the present invention triggers an integer overflow exception of the VxWorks operating system, which causes the system task to crash. Figure 5This is the test case packet information saved when an integer overflow exception is triggered. Analysis of the system anomaly and packet content confirms that the vulnerability triggered this time is CVE-2019-12255 in the VxWorks operating system. The specific cause of CVE-2019-12255 is an integer overflow error in the VxWorks system's TCP protocol stack when processing the TCP urgent pointer field. If a TCP packet has the URG (Urgent, TCP protocol urgent pointer) flag set and its urgent_pointer field is 0, when the VxWorks system socket performs a recv() operation, a function called iptcp_usr_get_from_recv_queue() is called to process the TCP packet. During processing, because the TCP packet has the URG flag set but its length is 0, the result of the variable l en in the corrected data length calculation is -1. However, because the data type of l en is an unsigned integer, the actual value of l en is 0xffffffff, which invalidates the read length limit set in the recv() function and copies all readable data to the user buffer, causing a stack overflow. During implementation, this invention triggers the CVE-2019-12255 vulnerability, demonstrating its effectiveness in vulnerability mining for the TCP protocol in VxWorks.

[0080] The foregoing is merely an embodiment of the present invention and is not intended to limit the present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.

Claims

1. A VxWorks transport layer protocol fuzz testing method based on feature tracking, characterized in that: Please follow the steps below to implement it: Step 1, preprocessing: Activate the TCP server state to be tested and determine the FLAGS flag of the current test case based on the test state; Step 2: Start the dual anomaly detection mechanism: start the client connection detection mechanism implemented by sending heartbeat packets using the client program and the system abnormal task detection mechanism implemented by using the WDB RPC protocol; Step 3: Generate and send a test case set: Construct an initial corpus based on the FLAGS flags of the test cases determined in the preprocessing phase; then fuzzify the initial corpus using a progressive fuzzification method that fuses feature relationships between messages to generate a test case set; Step 4, test object status monitoring and anomaly detection: After each test case is sent to the test object, the client connection detection mechanism sends a heartbeat packet to the test object to determine whether the TCP connection is online; at the same time, the system abnormal task detection mechanism uses the WDB_EVENT_GET function to detect whether the VxWorks system has any network task processing anomalies; Step 5: Consistency check of the flag features of the response message: Extract the TCP flag feature value of the response message of the test object in each round of testing, and then compare and analyze the consistency of the TCP flag feature value with the expected value; if the TCP flag feature value does not match the expected value, the test case of this round of fuzz testing is classified as a seed; Step 6: TCP feature-driven seed iteration generates new test cases: First, locate the abnormal field of the seed obtained in step 5, and then iteratively mutate other fields of the seed except the abnormal field to generate new test cases covering multiple fields at the same time; Step 7, exception handling and environment recovery: When the client connection detection mechanism in step 4 is abnormally disconnected, the test case that caused the abnormal disconnection of the client will be saved in PCAP format and logged at the same time; when the system abnormal task detection mechanism discovers the VxWorks system abnormal event, the register group content and memory content at the abnormal task breakpoint will be extracted and saved using the WDB_REGS_GET and WDB_MEM_READ function functions, and finally the WDB_CONTEXT_KILL function function will be used to implement hot restart environment recovery of the test object; Step 8: If the test case is not completed or the time threshold is not reached, the test continues. When the fuzz test is completed, the results of this fuzz test are statistically output.

2. The method according to claim 1, characterized in that The step 1 is specifically implemented according to the following steps: Step 1.1, TCP service state activation: Based on the current state of the TCP server to be tested, construct a data packet that can trigger the state and send the data packet to the test object to activate the state of the TCP server to be tested; Step 1.2, test case FLAGS flag determination: Each state of the TCP server will receive a specific FLAGS flag, determine the FLAGS flag that the test case needs to set.

3. The method according to claim 1, characterized in that The step 2 is specifically implemented according to the following steps: Step 2.1: Establish a TCP connection between the client program and the TCP service of the test object; In step 2.2, the host agent is implemented using the WDB RPC protocol, and then the WDB_TARGET_CONNECT2 function with the integer identifier 122 in the WDB RPC protocol is used to create a connection request packet. The connection is established with the 17185 port service of the VxWorks operating system through the request packet.

4. The method according to claim 1 or 2, characterized in that The step 3 is specifically implemented according to the following steps: Step 3.1, by setting the TCP flag field to other FLAGS flags different from the FLAGS flag and their combinations, constructing the initial corpus of the state test phase; setting the TCP flag field to the FLAGS flag, constructing the initial corpus of the state transition test phase; Step 3.2: Extract the value of the characteristic relationship field from the TCP message responded to when the TCP server state to be tested is activated in step 1.1; then, calculate the value of the characteristic relationship field required to be set for the test case based on the characteristic relationship between the TCP messages; Step 3.3, using the progressive fuzzification method to fuzzify the regular fields of the initial corpus; The fuzzification of the TCP protocol's regular fields is based on the value range of each regular field. Each field is assigned a progressive value from empty to out-of-bounds to generate different test case sets. Step 3.4, use the double-layer cross fuzzification method to fuzzify the option fields of the initial corpus; The fuzzification of the TCP protocol option field is done by mutating the option value of the option field at the bottom layer and the option tuple position of the option field at the upper layer, thereby generating different test case sets; In step 3.5, the value of the feature relationship field obtained in step 3.2 is merged with the test case set generated by mutation in step 3.4 to form a complete test case set, and then the merged test case set is sent to the test object to start fuzz testing.

5. The method according to claim 1, wherein The step 5 is specifically implemented according to the following steps: Step 5.1: Extract the FLAGS flag feature value in the TCP message from the response message received from the test object after each round of test case sending; In step 5.2, the extracted FLAGS flag feature value is compared with the expected value. If the two values ​​are the same, the next round of testing is continued. If they are different, the test cases of this round are classified as seeds, and the seeds are subsequently mutated to generate new test cases.

6. The method according to claim 1, wherein The step 6 is specifically implemented according to the following steps: Step 6.1, locating abnormal fields in the test case that caused the unexpected response flag to be received by comparing the regular fields and option fields of the seed with the default values ​​in sequence; In step 6.2, the seed iteration mutation is as follows: retain the abnormal field of the seed, and then use the Cartesian product combination iteration method to assign values ​​to other fields outside the abnormal field to generate new test cases that cover multiple field domains at the same time.

7. The method according to claim 1, characterized in that The double anomaly detection mechanism in step 2 is specifically as follows: The dual anomaly detection mechanism consists of a TCP service connection detection mechanism implemented by a TCP client program and a system abnormal task detection mechanism implemented using the WDB RPC protocol. The dual anomaly detection mechanism can simultaneously detect the reliability of TCP service connections and task anomalies in the VxWorks operating system. It is used to detect fluctuations in TCP connections during fuzz testing and discover denial of service anomalies. It is also used to detect the operating system's network task processing during the fuzzing process and discover stack overflow anomalies.

8. The method according to claim 4, characterized in that The step 3 also includes: The step 3.1 is specifically as follows: The initial corpus of the state test phase is constructed by setting the TCP flag field of the test case to other flags and their combination values ​​that are different from the FLAGS flag determined in step 1.2, thereby fuzz testing the TCP service state operation process; The initial corpus construction in the state transition test phase is to set the TCP flag field of the test case to the FLAGS flag determined in step 1.2, and then perform fuzz testing on the TCP service state transition process; The step 3.2 is specifically as follows: Extract the source port, destination port, data sequence number, and acknowledgment sequence number from the TCP message responded to when the TCP server status to be tested is activated in step 1.

1. The value of the characteristic relationship field that needs to be set for the test case is calculated based on the characteristic relationship between TCP messages; the destination port and source port of the test case are the source port and destination port of the response message respectively, the data sequence number of the test case is equal to the confirmation sequence number of the response message, and the confirmation sequence number is equal to the sum of the sequence number of the response message and its data length. Finally, the value of the packet checksum is calculated in combination with the values ​​of other variation fields.

9. The method according to claim 4, wherein: The step 3.4 is specifically as follows: When mutating the option field of the TCP protocol, the two-layer cross-fuzzification method adopted is divided into the bottom-level option value mutation and the upper-level option tuple position mutation; the bottom-level mutation is to perform bit flipping, insertion, replacement or deletion mutation on the option value in the same type of option tuple based on the initial value. At the same time, in order to increase the complexity of fuzzification, the mutation based on the initial value is looped for the initial length of the option and then assigned to the original type of option; the upper-level mutation is to perform mutations such as copying, crossing or position replacement based on the entire tuple on the option tuple obtained after the bottom-level mutation to obtain an option set; finally, this option set is assigned to the option field of the TCP protocol to generate test cases.

10. The method according to claim 6, wherein: The step 6.2 is specifically as follows: Establish value sets for other fields except the abnormal fields of the seed, wherein the other fields are regular fields and option fields excluding the feature relationship fields; the specific content in each field value set is a pre-set special value; The iterative mutation method for seeds is to keep the values ​​of the abnormal fields of the seeds unchanged, and the values ​​of other fields are based on the Cartesian product idea. Values ​​are taken from the value sets of each field in turn for combined iteration, thereby generating new test cases that cover multiple field domains at the same time.

Images