Kernel-driven fuzzy test sample determination method and related device

Abstract

The invention discloses a kernel driver fuzzy test sample determination method and a related device, and the method comprises the steps: obtaining real-time state information of a to-be-tested kernel driver, the real-time state information being capable of representing test coverage data; generating a new to-be-tested sample based on the real-time state information and a predetermined sample generation and variation constraint model, and adding the new to-be-tested sample into a to-be-tested sample set; and based on the real-time state information, a target test sample is selected from the to-be-tested sample set by adopting a multi-arm bandit, and the probability that the target test sample can cover a new test path which is not tested yet in all to-be-tested samples in the to-be-tested sample set is maximum. According to the scheme, the multi-arm gambling machine and the fuzzy test are combined for use, and the generation of a new to-be-tested sample test path is directionally guided through the obtained real-time state information of the to-be-tested kernel driver, so that the newly generated to-be-tested sample can cover the test path which is not covered before in a large probability; and the fuzzy test efficiency is improved on the whole.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and more specifically, to a method for determining a kernel-driven fuzzy test sample and a related device. Background Art

[0002] Fuzz testing technology is the process of simulating user input. Its core idea is to generate a large number of random samples in a short period of time and input them into the target program to trigger possible vulnerabilities in the memory. With the development of random fuzz testing technology, technicians in the field have found that overly random samples will lead to very low testing efficiency. Therefore, how to optimize fuzz testing samples has become the focus of attention of technicians in the field. Summary of the invention

[0003] In view of this, this application provides the following technical solutions:

[0004] A method for determining a kernel driver fuzz test sample, comprising:

[0005] Obtaining real-time status information of the kernel driver to be tested, wherein the real-time status information can represent test coverage data;

[0006] Generate a new sample to be tested based on the real-time status information and a predetermined constraint model of sample generation and mutation and add the new sample to be tested to the sample set;

[0007] Based on the real-time status information, a multi-armed bandit is used to select a target test sample from the sample set to be tested, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested.

[0008] Optionally, obtaining the real-time status information of the kernel driver to be tested includes:

[0009] The kernel debugging technology based on eBFP obtains the real-time status information of the kernel driver to be tested.

[0010] Optionally, the eBFP-based kernel debugging technology obtains real-time status information of the kernel driver to be tested, including:

[0011] Determine the function first address of the kernel function corresponding to the kernel driver to be tested and the first address offset of each basic block included in the kernel function, wherein the first address offset represents the offset of the first address of the basic block relative to the first address of the function;

[0012] Determine the stub position of each basic block based on the function first address and the first address offset of each basic block;

[0013] Adding a plugging code to each of the plugging positions, wherein the code is used to obtain operation data of the plugging position;

[0014] The real-time status information of the kernel driver to be tested is determined based on the operation data of each position.

[0015] Optionally, the generation of the constraint model includes:

[0016] Analyze the interface parameters of the kernel driver to determine the target parameters of the kernel driver and the data type of the target parameters, wherein the data type includes a structure type, and the target parameters include a plurality of parameters with association;

[0017] A constraint model for fuzz testing sample generation and mutation is determined based on the correlation between multiple target parameters and the data types of the target parameters.

[0018] Optionally, the target parameter includes a first parameter, a second parameter and a third parameter, the first parameter is a file descriptor returned by a function controlling the opening of a node device file, the second parameter is a command code corresponding to a kernel driver, and the third parameter is an optional parameter, and its data type corresponds to the second parameter;

[0019] The correlation between the first parameter, the second parameter and the third parameter includes: different node devices correspond to a certain first parameter respectively; different node device drivers correspond to a certain second parameter set respectively; different second parameters have third parameters of different data types;

[0020] The generating of new samples to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation and adding the new samples to be tested to the sample set includes:

[0021] Determine the node device corresponding to the kernel driver program that needs to be tested based on the real-time status information;

[0022] Determining a target first parameter based on the node device;

[0023] Determine a corresponding target second parameter set based on the first parameter;

[0024] Determine a target third parameter and its data type based on the second parameter set;

[0025] A new sample to be tested is generated based on the target first parameter, the target second parameter set, the target third parameter and their data types and added to the sample set to be tested.

[0026] Optionally, the generating a new sample to be tested based on the real-time status information and a predetermined constraint model for sample generation and variation and adding the new sample to be tested to the sample set includes:

[0027] Determine, based on the real-time status information, kernel functions and / or basic blocks that have not yet been detected, the kernel functions and the basic blocks belonging to the kernel driver to be tested;

[0028] Based on the kernel functions and / or basic blocks that have not yet been detected and the constraint model of sample generation and mutation, new samples to be tested are generated and added to the sample set to be tested, and the constraint model enables the generated samples to be tested to cover the kernel functions and / or basic blocks when executed by the kernel driver to be tested.

[0029] Optionally, based on the real-time status information, a multi-armed bandit is used to select a target test sample from the set of samples to be tested, including:

[0030] Based on the real-time status information, a seed selection algorithm of a multi-armed bandit is used to score the samples to be tested that have no scores in the sample set to be tested;

[0031] The sample to be tested with the highest score in the set of samples to be tested is determined as the target test sample.

[0032] Optionally, the reward of the multi-armed bandit triggers a new test path for the selected test sample, and the new test path includes kernel functions and / or basic blocks that are not included in all previous test paths;

[0033] The seed selection algorithm makes it more likely that the samples to be tested that cover the new test path in the set of samples to be tested will be selected.

[0034] The present application also discloses a device for determining a kernel-driven fuzzy test sample, comprising:

[0035] A status acquisition module, used to obtain real-time status information of the kernel driver to be tested, wherein the real-time status information can represent test coverage data;

[0036] A sample generation module, used to generate new samples to be tested and add them to the sample set to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation;

[0037] A sample selection module is used to select a target test sample from the sample set to be tested using a multi-armed bandit based on the real-time status information, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested.

[0038] Furthermore, the present application discloses a kernel-driven fuzz testing system, comprising:

[0039] A sample generation module is used to obtain real-time status information of the kernel driver to be tested, wherein the real-time status information can represent test coverage data; based on the real-time status information and a predetermined constraint model for sample generation and variation, a new sample to be tested is generated and added to a sample set to be tested; based on the real-time status information, a multi-armed bandit is used to select a target test sample from the sample set to be tested, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested;

[0040] The test running module is used to input the test sample into the kernel driver to be tested and run it.

[0041] Through the above technical scheme, it can be known that the embodiment of the present application discloses a method for generating kernel driver fuzz test samples and related devices, the method includes: obtaining real-time status information of the kernel driver to be tested, the real-time status information can represent the test coverage data; based on the real-time status information and the predetermined constraint model of sample generation and mutation, a new sample to be tested is generated and added to the sample set to be tested; based on the real-time status information, a multi-armed bandit is used to select a target test sample from the sample set to be tested, the target test sample is the one with the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested. The above scheme combines the multi-armed bandit with fuzz testing, and in the implementation, the real-time status information of the kernel driver to be tested is obtained to guide the generation of the new test path of the sample to be tested, so that the newly generated sample to be tested is likely to cover the test path that has not been covered before, thereby improving the efficiency of fuzz testing as a whole. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0043] Figure 1 A schematic diagram of the overall process of the fuzzy test disclosed in the embodiment of the present application;

[0044] Figure 2 A flow chart of a method for determining a kernel-driven fuzzy test sample disclosed in an embodiment of the present application;

[0045] Figure 3 A flowchart of obtaining real-time status information of a kernel driver to be tested disclosed in an embodiment of the present application;

[0046] Figure 4An abstract schematic diagram of the interaction between the application program and the kernel space data disclosed in the embodiment of the present application;

[0047] Figure 5 A schematic diagram of a traditional sample generation framework disclosed in an embodiment of the present application;

[0048] Figure 6 A schematic diagram of a sample generation framework for target parameter association constraints disclosed in an embodiment of the present application;

[0049] Figure 7 A schematic diagram of the complete conversion process of the cmd command disclosed in the embodiment of the present application;

[0050] Figure 8 This is an example diagram of the principle of selecting seeds for a multi-armed gambling machine disclosed in an embodiment of the present application;

[0051] Fig. 9 A schematic diagram of the seed selection algorithm flow of the multi-armed bandit disclosed in the embodiment of the present application;

[0052] Fig.10 A schematic diagram of the structure of a device for determining a kernel-driven fuzzy test sample disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0053] For the purpose of reference and clarity, the descriptions, abbreviations or acronyms of the technical terms used below are summarized as follows:

[0054] Binary instrumentation: Binary instrumentation is achieved by inserting additional code (called "probes" or "instrumentation code") into the execution flow of the program. These instrumentation codes can be executed before and after function calls, before and after instruction execution, or other specified program points. The instrumentation framework is responsible for managing these instrumentation points and executing the instrumentation code at the appropriate time.

[0055] Static instrumentation: Instrumentation is performed during the program compilation or linking phase, which usually requires modifying the original binary file.

[0056] Dynamic instrumentation: Instrumentation is performed while the program is running. There is no need to modify the original binary file. Instead, the execution flow of the program is modified in memory through various technical means.

[0057] eBPF: eBPF is a technology for running sandboxed programs in the Linux kernel. It originated from classic BPF and was originally used for network packet filtering, but over time, eBPF has developed into a powerful kernel programmable technology that can safely and efficiently extend kernel functionality without changing the kernel source code or loading kernel modules.

[0058] Fuzz testing: Fuzz testing is a software testing technique that is mainly used to find errors, vulnerabilities or abnormal behaviors in programs. It inputs a large amount of random or semi-random data (called "fuzzy input") into the target system in an automated way and monitors the system's response to detect potential problems. The core idea of ​​this method is that hidden defects in the software can be triggered by a large amount of unexpected input, which may be difficult to find in conventional testing. Fuzz testing is particularly suitable for complex systems and code areas that are difficult to cover with traditional testing methods.

[0059] ioctl function: ioctl is a system call widely used in Unix and Unix-like systems, and its full name is "input / output control". Its main function is to perform control operations on devices, such as opening or closing devices, getting or setting device parameters, etc. ioctl is usually used for devices that do not have dedicated read and write interfaces, such as serial ports, sound cards, printers, etc. The working principle of ioctl call is to send a control command to the kernel, which is specified by the request parameter. The kernel performs the corresponding operations based on this command and the passed parameters, and returns the results to the program in user space. These operations may be to query device status, change device behavior, configure device parameters, etc.

[0060] QEMU: The full name is Quick EMUlator, which is an open source virtualization software that can simulate multiple hardware platforms and run various operating systems on these platforms.

[0061] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0062] In order to better understand the technical solution disclosed in this application, the relevant contents of fuzz testing are first introduced. The overall process of fuzz testing is as follows: Figure 1 As shown, combined Figure 1 , fuzz testing can be mainly divided into the following six steps:

[0063] (1) Determine the target to be tested

[0064] Determining the target to be tested (corresponding to the kernel driver to be tested in the following text) is an essential step before fuzz testing. Different fuzz testing schemes can be selected for different systems, different operating environments, and different test objects to ensure that all selected methods can be completed efficiently. In this step, it is mainly necessary to ensure that the following choices are correct: first, the operating environment of the target to be tested must be determined; second, the instrumentation scheme or information acquisition method of the target to be tested must be determined; third, the format of the test sample of the target to be tested (corresponding to the sample to be tested in the following text) is determined; finally, the error capture scheme of the target to be tested is determined.

[0065] (2) Determine the input method

[0066] Determining the input method is one of the core aspects of fuzz testing solution design. The fuzz testing program needs to build a suitable execution environment based on the unique operating environment of the program under test; it needs to know how to communicate with the program under test and build a suitable execution plan; it needs to know how to let the program under test continue to execute the samples generated by the fuzz test. Taking the fuzz testing of the driver as an example, the fuzz testing program must first open the corresponding device, prepare the prerequisite environment for the driver test, and then interact with the corresponding driver through the ioctl system call to trigger the corresponding code in the kernel.

[0067] (3) Generate test samples

[0068] Generating test samples is the core component of fuzz testing. There are often different fuzz testing schemes for different input programs (targets). Kernel-driven fuzz testing inputs are highly constrained and have obvious format requirements, and usually use constraint models to constrain sample generation schemes.

[0069] (4) Run the program under test

[0070] After the test samples are prepared by means of constraints, the program under test needs to execute these test samples, and execute these test samples through the input scheme determined in the second step to determine the input method. Usually there are methods such as sending data packets, reading and writing local files, and executing system calls. The kernel driver chooses to execute the ioctl system call to complete data communication.

[0071] (5) Detect the running status of the target to be tested

[0072] Detecting the running status of the target to be tested is the key basis for discovering vulnerabilities. If no exceptions are found during the entire fuzz testing process, it is generally assumed that the test sample has no triggering problems and the program to be tested is running normally. Only when the current test sample triggers certain exceptions can it be determined that the current program to be tested has certain vulnerabilities.

[0073] (6) Collect test samples

[0074] Collecting test samples is an important step to fix the program after fuzz testing. Security researchers reproduce the vulnerability through these crash-causing test samples, analyze the cause of the vulnerability from these crash samples, and finally fix the vulnerability.

[0075] The above content introduces the overall implementation process of fuzz testing. The technical solution of this application is to generate test samples and input the target to be tested for iterative operation, thereby improving the overall efficiency of fuzz testing. The following will introduce in detail the solution for determining kernel-driven fuzz test samples.

[0076] Figure 2 This is a flow chart of a method for determining a kernel driver fuzzy test sample disclosed in an embodiment of the present application. Figure 2 As shown, the method for determining the kernel driver fuzz test sample may include:

[0077] Step 201: Obtain real-time status information of the kernel driver to be tested, where the real-time status information can represent test coverage data.

[0078] In the process of fuzz testing the kernel driver to be tested, a test sample is input to the kernel driver to be tested, and the kernel driver to be tested runs, and the state information of the running process can be obtained in real time. The real-time state information can reflect which kernel functions and / or basic blocks in the kernel driver to be tested have been covered by the test. The specific implementation of obtaining the real-time state information of the kernel driver to be tested will be described in detail in the embodiment content below, and will not be described in detail here.

[0079] Step 202: Generate a new sample to be tested based on the real-time status information and a predetermined constraint model for sample generation and variation, and add the new sample to be tested to the sample set.

[0080] After obtaining the real-time status information, you can refer to the real-time status information to generate new samples to be tested. The principle of generating the new samples to be tested is that when the kernel program to be tested runs the samples to be tested, it can cover kernel functions and / or basic blocks that were not covered before, thereby improving the overall coverage of the fuzz test.

[0081] Among them, the constraint model for sample generation and mutation can be predetermined, and there is a corresponding constraint model for the interface parameters of different kernel drivers to be tested. The constraint model records or stipulates the constraint conditions between the various parameters contained in the interface parameters. Therefore, after determining the kernel functions and / or basic blocks that have not been covered, the interface parameters corresponding to the kernel functions and / or basic blocks can be determined, and the corresponding samples to be tested can be generated based on the constraint model corresponding to the determined interface parameters.

[0082] Step 203: Based on the real-time status information, a multi-armed bandit is used to select a target test sample from the sample set to be tested, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested.

[0083] In an embodiment of the present application, for the updated set of samples to be tested, a multi-armed bandit can be used to select an optimal sample to be tested from the set of samples to be tested as a target test sample. When the selected target test sample is input into the kernel driver to be tested and executed, it is highly likely to cover kernel functions and / or basic blocks that have not been covered before.

[0084] In the scheme for determining the kernel driver fuzz test samples described in this embodiment, a multi-armed bandit and fuzz testing are used in combination. In the implementation, the real-time status information of the kernel driver to be tested is obtained to provide guidance for the generation of new test paths for the samples to be tested, so that the newly generated samples to be tested are likely to cover the test paths that have not been covered before, thereby improving the overall fuzz testing efficiency.

[0085] In the above embodiment, the obtaining of the real-time status information of the kernel driver to be tested may include: obtaining the real-time status information of the kernel driver to be tested based on the kernel debugging technology of eBFP (Extended Berkeley Packet Filter).

[0086] Being able to obtain real-time status information of kernel drivers is a prerequisite for generating high-quality samples to be tested and guiding fuzz test samples to mutate. However, since the driver runs in kernel state, it is difficult to obtain real-time information of the driver. This is mainly reflected in two aspects: First, since the driver runs directly on the kernel, the kernel provides limited interfaces to users, making it difficult to obtain real-time running information, but coverage-oriented fuzz testing usually requires coverage information with a granularity smaller than that of functions. Common instrumentation tools are generally user-mode instrumentation tools, which are difficult to perform kernel instrumentation tasks; second, the existing acquisition of real-time status information of kernel-mode programs usually adopts the QEMU method. For some drivers, virtualization may not be completed well on QEMU or customized front-end and back-end drivers may be required, which is also an obstacle to the acquisition of real-time information of the driver.

[0087] The inventor of the present application discovered during the research process that kprobes, a kernel debugging technology in Linux eBPF (a mechanism in the Linux kernel that allows the execution of functions to be dynamically intercepted (probed) when the kernel is running), is very suitable for the need for real-time kernel information acquisition in this article, because kprobes can add user plug-in code at almost any location, but its application requires the user to provide the specific memory address of the plug-in analysis point. Therefore, the problem of real-time kernel information acquisition based on eBPF is converted into the specific location acquisition of the plug-in analysis point.

[0088] Specifically, Figure 3 The process of obtaining the real-time status information of the kernel driver to be tested is shown, combined with Figure 3 As shown, the eBFP-based kernel debugging technology obtains the real-time status information of the kernel driver to be tested, which may include:

[0089] Step 301: Determine the function first address of the kernel function corresponding to the kernel driver to be tested and the first address offset of each basic block included in the kernel function, wherein the first address offset represents the offset of the first address of the basic block relative to the first address of the function.

[0090] Step 302: Determine the insertion position of each basic block based on the function first address and the first address offset of each basic block.

[0091] The address of the kernel function Func_addr i It can be obtained by exporting the symbol table, but considering that the required dot location may have a smaller granularity than the function, it is necessary to adopt an offset calculation solution to obtain the actual memory address.

[0092] Addr i =Func_addr i +Offset i

[0093] Among them, Addr i Indicates the specific address of the i-th instrumentation analysis point, Func_addr i Indicates the kernel function head address corresponding to the i-th instrumentation analysis point, Offset i Indicates the offset of the ith instrumentation analysis point relative to the first address of its corresponding kernel function, that is, the first address offset. In implementation, the IDA Pro tool can be used to automatically complete the basic block division of the binary program. IDA Pro can not only provide an intuitive basic block flow chart, but also output the relative address of each function and each basic block. Based on the formula Offset i =addr_block i-addr_func i To determine the first address offset Offset i Among them, addr_block i is the relative address of the ith basic block, addr_func i is the relative address of the function corresponding to the i-th basic block.

[0094] Step 303: adding an insertion code to each of the insertion positions, wherein the code is used to obtain the operation data of the insertion position.

[0095] Step 304: Determine the real-time status information of the kernel driver to be tested based on the operation data of each location.

[0096] A basic block is the basic unit of program control flow, consisting of one or several branchless instructions. A basic block has a unique entry address and a unique exit address. Therefore, when collecting coverage information, as long as the running status of each basic block can be monitored, the corresponding coverage information can be obtained. In actual implementation, the first instruction of each basic block is marked, that is, the first address of each basic block is used as the insertion analysis point. Whenever these insertion points are reached, kprobes is activated to collect the execution status of the current basic block. After statistics, the corresponding coverage situation can be obtained.

[0097] As mentioned above, Addr i In fact, it is the first address of the basic block. As long as all basic blocks can be divided, all the stub analysis points will be determined accordingly. The first address of each basic block is used as the stub analysis point to record the execution status of the current basic block. After the test is fully executed, every basic block executed by the program will be recorded, and all coverage information will be counted to obtain the overall coverage rate of the program.

[0098] This embodiment aims at the difficulty of directly obtaining real-time information of kernel-state programs, and proposes a solution for obtaining kernel real-time state information by using kernel debugging technology based on eBPF. By combining the operating system's own debugging technology with customized processing functions to complete the monitoring of kernel real-time information, the coverage rate of the driver program during runtime can be effectively obtained.

[0099] In the above embodiment, the generation of the constraint model may include: analyzing the interface parameters of the kernel driver, determining the target parameters of the kernel driver and the data type of the target parameters, the data type includes a structure type, and the target parameters include multiple parameters with association; based on the association between multiple target parameters and the data type of the target parameters, determining the constraint model for fuzzy test sample generation and mutation.

[0100] Kernel drivers are different from other kernel programs. Drivers need to manage numerous physical devices and provide interfaces for these external devices. This results in the driver usually being customized, and custom structures are usually used when transmitting data, making the driver's input data structure type very complex and highly constrained, which is extremely unfavorable for the generation of high-quality samples. This leads to a common problem in the current fuzz testing tools for kernel driver testing, which is the weak ability to generate high-quality samples to be tested. In order to improve the quality of the samples to be tested, it is necessary to remove the black box outside the driver, analyze the driver interface parameters from the perspective of the source code, and parse out several important parameters of the driver and their data types, especially the structure type.

[0101] The interface may be ioctl, and the interface parameter may be a parameter of the ioctl interface. Among all interfaces of the driver, ioctl is the most complex interface and is the main customization object of the driver. By analyzing the three main parameters of ioctl, fd, cmd, arg, and the specific structure type of the arg parameter, a constraint model for fuzz test sample generation and mutation can be summarized to support the subsequent fuzz test system.

[0102] For example, there is a calculator driver, the corresponding fd is fd1, the cmd set is {1, 2, 3, 4}, the arg parameters are two arg1 and arg2, and the data types of arg1 and arg2 are float;

[0103] When Cmd = 1, the calculator does arg1 + arg2;

[0104] When Cmd = 2, the calculator does arg1-arg2;

[0105] When Cmd=3, the calculator does arg1*arg2;

[0106] When Cmd=4, the calculator does arg1 / arg2;

[0107] Parsing it, we get the constraint model as {fd1,{1,2,3,4},float,float}.

[0108] Based on the above, the target parameters may include but are not limited to a first parameter, a second parameter and a third parameter. The first parameter may be a file descriptor fd returned by a function that controls opening a node device file. The second parameter may be a command code cmd corresponding to a kernel driver. The third parameter may be an optional parameter arg, and its data type corresponds to that of the second parameter.

[0109] From the application's perspective, the abstract diagram of the interaction between application and kernel space data is as follows: Figure 4As shown in the figure. In the driver, open, read, write, and close are basically available to every driver and their functions are not much different. Open is responsible for opening the node device file to prepare for the next interaction; read and write are responsible for reading and writing data between kernel space and user space; close is to close the device file. In addition to these basic functions, almost all device-related interaction operations of the driver are solved through ioctl. Compared with other system calls, ioctl performs more complex functions, interacts more frequently, and has a higher probability of vulnerabilities.

[0110] Ioctl is the most customized function in the kernel driver. It controls some personalized functions of the device by managing the I / O channel. Its calling form is: int ioctl(int fd, unsigned intcmd, unsigned long arg); where fd is the file descriptor returned by the open function, cmd is the command code corresponding to the driver, and arg is an optional parameter. The specific type corresponds to the cmd command. In general, the value of arg is the address of the actual parameter. Through the ioctl method prototype, according to the general fuzz testing scheme, Figure 5 Such a sample generation framework generates samples.

[0111] However, due to the characteristics of ioctl, the three parameters of fd, cmd, and arg are not unrelated to each other. Different fds correspond to different cmd command sets, and different cmd values ​​correspond to different arg parameter types. During the actual operation of the driver, the driver will perform two levels of preliminary checks. The first level is to determine whether the driver has the corresponding operation type, that is, whether the cmd command in fd is valid. If not, the driver will directly return -1 if the verification error occurs. The second level is to determine whether the parameters of the current operation are legal, that is, whether the data parameter type corresponding to the current cmd command is consistent with arg. If not, the currently generated arg parameter will lose its actual measurement significance.

[0112] If we use random parameter generation, the sample combinations that need to be tested will be very large. At the same time, these huge sample combinations contain a large number of meaningless test samples, and most of them cannot even pass the initial feasibility check. Therefore, the test of the ioctl function cannot be simply completed with three random parameters. In the process of fuzz testing, the three parameters need to be associated and constrained.

[0113] Figure 6 A sample generation framework for target parameter association constraints disclosed in the embodiments of this application. Figure 6As shown, the sample generation framework of the present application replaces the random generation of three parameters with a step-by-step form on the original basis, so as to constrain the generation of test samples step by step.

[0114] (1) fd, first determine the corresponding fd value based on the open device node.

[0115] (2) cmd: For different device drivers, the corresponding cmd command set is also determined. The cmd command set corresponding to the device can be extracted by analyzing the kernel driver code.

[0116] (3) arg. For each cmd command, there will be different types of arg. After determining the cmd command to be used, the corresponding arg parameter type can also be determined by analyzing the kernel driver code. Among them, the arg parameter type is mostly a structure type. Therefore, the actual constraint process involves multiple basic types of variable constraints.

[0117] The sample generation of fuzz testing is mainly constrained by the above three methods. Due to the existence of constraints, most of the generated samples can pass the initial logic monitoring of the driver. These samples can enter the deeper logic of the driver and find more problems in the program. From the perspective of this article, the improved sample generation framework will be able to better generate usable high-quality samples.

[0118] In the implementation, analysis of the ioctl interface: when the user calls ioctl in user space, the corresponding interface in the driver device may be one of the three: ioctl, unlocked_ioctl, and compat_ioctl.

[0119] In the kernel, common driver operations such as ioctl and open, read, and write are encapsulated in the file_operations structure in the driver code, usually expressed in the following form:

[0120]

[0121] Among them, XXX_ioctl is the function name of the driver device operation. Through XXX_ioctl, you can locate the specific function in the source code and determine whether the called interface is ioctl, unlocked_ioctl or compat_ioctl.

[0122] About cmd parameter analysis: The cmd command code is divided into 4 fields in the kernel.

[0123] The dir segment, bit31 to bit30, 2 bits are the "read-write distinction" area, which is used to distinguish between read commands and write commands.

[0124] The size segment, bit 29 to bit 15, 14 bits are the "data size" area, which is used to indicate the actual memory size of the arg parameter corresponding to the cmd command code.

[0125] The type segment, bit 20 to bit 08, 8 bits are the "magic number" area, usually represented by some random characters, used to distinguish commands from other devices.

[0126] The nr segment, bit07 to bit00, 8 bits are the "distinguishing sequence number" area, which is used to distinguish the command sequence.

[0127] Macro definition: The kernel also provides 4 auxiliary macros to represent cmd commands.

[0128] _IO(magic number, base number) means that there are no variables to be transferred, only commands need to be transferred.

[0129] _IOR (magic number, base number, variable type) indicates a command with a read operation, which is used to read data from the driver device.

[0130] _IOW (magic number, base number, variable type) indicates a command with a write operation, which is used to write data to the drive device.

[0131] _IOWR (magic number, base number, variable type) indicates a command with read and write operations, which is used to read data from the drive device and write data to the drive device.

[0132] In actual driver writing, these macro definitions are usually used to express cmd commands. Take the cmd command PPPIOCSFLAGS in the driver ppp as an example. Figure 7 It shows the complete conversion process of cmd command.

[0133] About obtaining the command set: The previous article analyzed the parsing method of cmd commands, and its purpose is to obtain the cmd command set corresponding to the driver device ioctl.

[0134] After identifying the ioctl function XXX_ioctl corresponding to the driver in the previous article, a series of switch case statements can be found inside XXX_ioctl. The macros following these cases are all components of the cmd command set. The corresponding values ​​can be found in the macro definition, which are generally expressed in two forms. A small part of the definition is directly expressed in hexadecimal numbers, which can be directly incorporated into the cmd command set. After the macro definition is determined, these macro definitions need to be converted according to the macro definition method and then incorporated into the cmd command set. Through the above processing, the analysis of the cmd parameters can be completed and the corresponding cmd command set can be obtained.

[0135] About arg parameter analysis: There is a one-to-one correspondence between the arg parameter type and the cmd parameter. The macro definition of the cmd parameter actually contains the arg parameter type information. However, for a small number of drivers, the writing process is not so standardized, so it is necessary to analyze the arg parameter type in combination with the data flow.

[0136] Arg parameter analysis involves standardized parameter type extraction and non-standardized parameter type extraction. For standardized parameter type extraction.

[0137] For most standardized drivers that are written in accordance with specifications, take the PPPIOCSBPMODE command of the driver ppp as an example, its corresponding macro definition is _IOW('t',75,struct npioctl). It can be clearly found from the macro definition that the arg parameter type corresponding to the cmd command PPPIOCSBPMODE is the npioctl structure, and all the information of this structure can be obtained from the header file of the driver.

[0138] For non-standard parameter type extraction: A small number of drivers do not standardize the writing of cmd commands and choose to directly express them in hexadecimal. In this case, the standardized extraction method is no longer useful, considering that the order of parameter passing in ioctl calls must be from user space to kernel space. The data copy functions in this direction are copy_from_user and get_user, so the parameter type extraction of non-standard conversion mainly depends on the analysis of these two functions.

[0139] Take the driver's PPPIOCCPNNECT command as an example:

[0140] case PPPIOCCPNNECT:

[0141] if(get_user(uint,p))

[0142] break;

[0143] You can see that the arg parameter type corresponding to the cmd command PPPIOCCPNNECT is uint.

[0144] In combination with the above content, the association between the first parameter, the second parameter and the third parameter may include but is not limited to: different node devices correspond to a certain first parameter respectively; different node device drivers correspond to a certain second parameter set respectively; different second parameters have third parameters of different data types;

[0145] The generating of new samples to be tested and adding them to the sample set to be tested based on the real-time status information and a predetermined constraint model for sample generation and variation may include: determining a node device corresponding to a kernel driver to be tested based on the real-time status information; determining a target first parameter based on the node device; determining a corresponding target second parameter set based on the first parameter; determining a target third parameter and its data type based on the second parameter set; generating a new sample to be tested and adding it to the sample set to be tested based on the target first parameter, the target second parameter set, and the target third parameter and its data type.

[0146] Alternatively, from the perspective of overall processing logic, the generating of new samples to be tested and adding them to the sample set to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation may include: determining kernel functions and / or basic blocks that have not yet been detected based on the real-time status information, wherein the kernel functions and basic blocks belong to the kernel driver to be tested; generating new samples to be tested and adding them to the sample set to be tested based on the kernel functions and / or basic blocks that have not yet been detected and a constraint model for sample generation and mutation, wherein the constraint model enables the generated samples to be tested to cover the kernel functions and / or basic blocks when executed by the kernel driver to be tested.

[0147] In view of the complex input and strong constraints of ioctl function, this embodiment of the application proposes a static analysis scheme for driver interface parameters. By analyzing the source code of the kernel driver, the parameter information such as fd and cmd is extracted from the source code of the driver, and on this basis, the specific information of the arg parameter is determined from the copy_from_user and get_user functions, and a set of constraint models are summarized to constrain the variation and generation of the samples to be tested in the subsequent fuzz testing process.

[0148] In one implementation, based on the real-time status information, a multi-armed bandit is used to select a target test sample from the set of samples to be tested, which may include: based on the real-time status information, using a seed selection algorithm of the multi-armed bandit to score the samples to be tested that have no scores in the set of samples to be tested; and determining the sample to be tested with the highest score in the set of samples to be tested as the target test sample.

[0149] Among them, the reward of the multi-armed bandit machine is to trigger a new test path for the selected test sample, and the new test path includes kernel functions and / or basic blocks that are not included in all previous test paths; the seed selection algorithm makes it more likely that the test samples covering the new test path in the test sample set will be selected.

[0150] This application scheme introduces the multi-armed bandit into the problem of seed (test sample) selection. Then each seed in the seed library is regarded as a lever on the multi-armed bandit. Each time the seeds are selected and a seed is selected, it is regarded as the multi-armed bandit pulling the lever once. The seed mutation generates a new test case and discovers a new path, which is regarded as obtaining a reward. If no new path is found, it means that no reward is found. In the case of an unknown probability of the bandit reward, a seed selection algorithm is formulated so that the mutation covers as many new paths as possible when the number of seed selections is the same.

[0151] The principle of multi-armed gambling machine seed selection is shown in the figure below: Figure 8 As shown. Combined Figure 8 The total node expectation of a seed predicts how many new paths a seed may discover after mutation, and can be used to evaluate the future potential of a seed. In addition, if a new path is discovered, the total node expectation of the seed will be updated. The total node expectation of the seed will decrease as the coverage rate increases. Therefore, the decay of the potential of the seed after discovering a new path can be measured. From the perspective of actual fuzz testing operations, it is easier to discover new basic blocks in the initial stage of fuzz testing, and the probability of discovering new basic blocks becomes smaller afterwards. The seeds that enter the seed library are more likely to be more difficult to generate and the corresponding new paths are less likely to be covered.

[0152] The formula for calculating the seed value is:

[0153]

[0154] The left side of the equal sign in the above formula represents action a, which means selecting seed a; the right side of the equal sign represents the benefit, which is the number of new paths generated.

[0155]

[0156] in, seedTotalNodeExpect indicates the expected total number of nodes in the seed, nodeExpecti is the node expectation of the i-th node; nodeExpect = x1 + kx2 + ... + k i-1 x i ; i represents the number of layers of successor node records, xi represents the number of uncovered successor nodes in the i-th layer, and k = 0.4.

[0157] i is the seed number, which is arranged in the order of time when it enters the seed library. i is the average return of seed i, seedvaluation i Indicates the estimated return of the ith seed, seedTotalNodeExpect i Indicates the total node expectation of the i-th seed, initTotalNodeExpect i is the total node expectation when the i-th seed just enters the seed library.

[0158] Regarding the seed selection algorithm of the multi-armed bandit, its implementation process is as follows Fig. 9 As shown. Combined Fig. 9 For the initial seed sequence, if there are unexecuted seeds, they will be executed first; if there are no unexecuted seeds, random selection will be performed, with a higher probability of selecting the seed with the highest valuation, and a lower probability of randomly selecting from the seed queue. If a new path is generated by this seed execution, it will be added to the seed sequence. This process is repeated until the coverage reaches the preset value of the program.

[0159] The embodiment of the present application combines the use of multi-armed bandits and fuzz testing, optimizes the sample mutation method based on the characteristics of the driver, optimizes the sample fitness calculation method based on the specific operation process of the driver, and designs and implements a driver vulnerability mining tool. On the premise of obtaining the driver interface parameter information, a more effective input to be tested is constructed, and the efficiency of fuzz testing is improved by optimizing the particle swarm algorithm in combination with real-time monitoring technology.

[0160] In summary, in order to solve the problems that the kernel driver status is difficult to monitor and the input is complex and constrained, this application firstly designs and implements a kernel driver real-time information acquisition scheme by using eBPF-based kernel debugging technology combined with static analysis of the kernel driver in view of the difficulty that the real-time information of the kernel driver is difficult to obtain through general instrumentation methods; then, in view of the characteristics of complex and strong constraints of ioctl function input, the rules of kernel driver interface parameters are analyzed and summarized, and the number of parameters, parameter rules, parameter types and other information required for kernel driver fuzz testing are determined. A kernel driver parameter extraction scheme based on static analysis is designed and the constraint model is summarized for subsequent sample constraints; finally, the multi-armed bandit is introduced into the seed selection problem, and the quality of the mutated samples is improved in combination with the constraint model.

[0161] For the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0162] The method is described in detail in the embodiments disclosed in the above-mentioned application. The method of the application can be implemented by various forms of devices. Therefore, the application also discloses a device, and a specific embodiment is given below for detailed description.

[0163] Fig.10 This is a schematic diagram of the structure of a device for determining a kernel-driven fuzzy test sample disclosed in an embodiment of the present application. Fig.10 As shown, the kernel driver fuzzy test sample determination device 100 may include:

[0164] The status acquisition module 1001 is used to obtain the real-time status information of the kernel driver to be tested, and the real-time status information can represent the test coverage data.

[0165] The sample generation module 1002 is used to generate a new sample to be tested based on the real-time status information and a predetermined constraint model of sample generation and variation, and add the new sample to be tested to the sample set.

[0166] The sample selection module 1003 is used to select a target test sample from the sample set to be tested using a multi-armed bandit based on the real-time status information, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested.

[0167] In the scheme for determining the kernel driver fuzz test samples described in this embodiment, a multi-armed bandit and fuzz testing are used in combination. In the implementation, the real-time status information of the kernel driver to be tested is obtained to provide guidance for the generation of new test paths for the samples to be tested, so that the newly generated samples to be tested are likely to cover the test paths that have not been covered before, thereby improving the overall fuzz testing efficiency.

[0168] The specific implementation of the above-mentioned kernel driver fuzzy test sample determination device and the modules it contains can be found in the corresponding part of the method embodiment, which will not be repeated here.

[0169] Any one of the kernel-driven fuzzy test sample determination devices described in the above embodiments includes a processor and a memory. The state acquisition module, sample generation module, sample selection module, etc. in the above embodiments are all stored in the memory as program modules, and the processor executes the above program modules stored in the memory to implement corresponding functions.

[0170] The processor includes a kernel, which retrieves the corresponding program module from the memory. One or more kernels can be set, and the processing of the access data can be realized by adjusting the kernel parameters.

[0171] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0172] In an exemplary embodiment, a computer-readable storage medium is also provided, which can be directly loaded into the internal memory of a computer and contains software code. After being loaded and executed by a computer, the computer program can implement the steps shown in any embodiment of the above-mentioned kernel-driven fuzz test sample determination method.

[0173] In an exemplary embodiment, a computer program product is also provided, which can be directly loaded into the internal memory of a computer, and contains software code. After being loaded and executed by a computer, the computer program can implement the steps shown in any embodiment of the method for determining the kernel-driven fuzzy test sample described above.

[0174] Furthermore, the embodiment of the present application provides a kernel-driven fuzz testing system, including:

[0175] A sample generation module is used to obtain real-time status information of the kernel driver to be tested, wherein the real-time status information can represent test coverage data; based on the real-time status information and a predetermined constraint model for sample generation and variation, a new sample to be tested is generated and added to a sample set to be tested; based on the real-time status information, a multi-armed bandit is used to select a target test sample from the sample set to be tested, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested;

[0176] The test running module is used to input the test sample into the kernel driver to be tested and run it.

[0177] 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 device 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.

[0178] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0179] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0180] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for determining a kernel driver fuzzy test sample, characterized in that: include: Obtaining real-time status information of the kernel driver to be tested, wherein the real-time status information can represent test coverage data; Generate a new sample to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation and add the new sample to be tested to the sample set; Based on the real-time status information, a multi-armed bandit is used to select a target test sample from the sample set to be tested, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested.

2. The method for determining a kernel driver fuzzy test sample according to claim 1, characterized in that: The step of obtaining the real-time status information of the kernel driver to be tested includes: The kernel debugging technology based on eBFP obtains the real-time status information of the kernel driver to be tested.

3. The method for determining a kernel driver fuzzy test sample according to claim 2, characterized in that: The eBFP-based kernel debugging technology obtains real-time status information of the kernel driver to be tested, including: Determine the function first address of the kernel function corresponding to the kernel driver to be tested and the first address offset of each basic block included in the kernel function, wherein the first address offset represents the offset of the first address of the basic block relative to the first address of the function; Determine the stub position of each basic block based on the function first address and the first address offset of each basic block; Adding a plugging code to each of the plugging positions, wherein the code is used to obtain operation data of the plugging position; The real-time status information of the kernel driver to be tested is determined based on the operation data of each position.

4. The method for determining a kernel driver fuzzy test sample according to claim 1, characterized in that: The generation of the constraint model includes: Analyze the interface parameters of the kernel driver to determine the target parameters of the kernel driver and the data type of the target parameters, wherein the data type includes a structure type, and the target parameters include a plurality of parameters with association; A constraint model for fuzz testing sample generation and mutation is determined based on the correlation between multiple target parameters and the data types of the target parameters.

5. The method for determining a kernel driver fuzzy test sample according to claim 4, characterized in that: The target parameter includes a first parameter, a second parameter and a third parameter, the first parameter is a file descriptor returned by a function that controls opening a node device file, the second parameter is a command code corresponding to a kernel driver, and the third parameter is an optional parameter, and its data type corresponds to the second parameter; The correlation between the first parameter, the second parameter and the third parameter includes: different node devices correspond to a certain first parameter respectively; different node device drivers correspond to a certain second parameter set respectively; different second parameters have third parameters of different data types; The generating of new samples to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation and adding the new samples to be tested to the sample set includes: Determine the node device corresponding to the kernel driver program that needs to be tested based on the real-time status information; Determining a target first parameter based on the node device; Determine a corresponding target second parameter set based on the first parameter; Determine a target third parameter and its data type based on the second parameter set; A new sample to be tested is generated based on the target first parameter, the target second parameter set, the target third parameter and their data types and added to the sample set to be tested.

6. The method for determining a kernel driver fuzzy test sample according to claim 1, characterized in that: The generating of new samples to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation and adding the new samples to be tested to the sample set includes: Determine, based on the real-time status information, kernel functions and / or basic blocks that have not yet been detected, the kernel functions and the basic blocks belonging to the kernel driver to be tested; Based on the kernel functions and / or basic blocks that have not yet been detected and the constraint model of sample generation and mutation, new samples to be tested are generated and added to the sample set to be tested, and the constraint model enables the generated samples to be tested to cover the kernel functions and / or basic blocks when executed by the kernel driver to be tested.

7. The method for determining a kernel driver fuzzy test sample according to claim 1, characterized in that: Based on the real-time status information, a target test sample is selected from the set of samples to be tested using a multi-armed bandit, including: Based on the real-time status information, a seed selection algorithm of a multi-armed bandit is used to score the samples to be tested that have no scores in the sample set to be tested; The sample to be tested with the highest score in the set of samples to be tested is determined as the target test sample.

8. The method for determining a kernel driver fuzzy test sample according to claim 7, characterized in that: The reward of the multi-armed bandit triggers a new test path for the selected test sample, and the new test path includes kernel functions and / or basic blocks that are not included in all previous test paths; The seed selection algorithm makes it more likely that the samples to be tested that cover the new test path in the set of samples to be tested will be selected.

9. A device for determining a kernel driver fuzzy test sample, characterized in that: include: A status acquisition module, used to obtain real-time status information of the kernel driver to be tested, wherein the real-time status information can represent test coverage data; A sample generation module, used to generate new samples to be tested and add them to the sample set to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation; A sample selection module is used to select a target test sample from the sample set to be tested using a multi-armed bandit based on the real-time status information, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested.

10. A kernel-driven fuzzy testing system, characterized in that: include: A sample generation module, used to obtain real-time status information of the kernel driver to be tested, wherein the real-time status information can represent test coverage data; Generate a new sample to be tested based on the real-time status information and a predetermined constraint model for sample generation and mutation and add the new sample to be tested to the sample set; Based on the real-time status information, a target test sample is selected from the sample set to be tested using a multi-armed bandit, wherein the target test sample has the highest probability of covering a new test path that has not been tested among all the samples to be tested in the sample set to be tested; The test running module is used to input the test sample into the kernel driver to be tested and run it.

Images