Closed source kernel vulnerability mining method and device, electronic equipment and storage medium

Abstract

The invention provides a closed-source kernel vulnerability mining method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining target kernel function information of a to-be-tested kernel which is a kernel of a closed-source Linux operating system; performing dynamic instrumentation on the kernel function to be instrumented indicated by the target kernel function information; when it is detected that a kernel function which is subjected to dynamic instrumentation in the kernel to be tested is called, generating coverage path information of the kernel to be tested; and performing vulnerability mining on the to-be-tested kernel based on the coverage path information. According to the embodiment provided by the scheme, the vulnerability mining efficiency of the closed source kernel can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of vulnerability mining, and in particular to a closed-source kernel vulnerability mining method, device, electronic device and storage medium. Background Art

[0002] In the actual application of security testing and vulnerability mining, syzkaller is a widely used fuzz testing tool, mainly used to detect kernel vulnerabilities. The tool generates random system call sequences to trigger potential problems in the target kernel. Syzkaller usually relies on the source code of the target kernel to insert code blocks during compilation, so as to obtain coverage path information when the kernel is running and finally guide the mutation of the test corpus. However, in the actual environment, the source code of the target kernel is not always easy to obtain, which leads to the lack of feedback guidance of coverage path information on the mutation of the test corpus in kernel vulnerability mining, thus affecting the efficiency of kernel vulnerability mining. Summary of the invention

[0003] The embodiments of the present application provide a closed-source kernel vulnerability mining method, device, electronic device and computer storage medium, which can test the closed-source kernel with coverage feedback, effectively improving the vulnerability mining efficiency of the closed-source kernel. The above technical solution is as follows:

[0004] In a first aspect, an embodiment of the present application provides a closed-source kernel vulnerability mining method, the method comprising:

[0005] Obtain target kernel function information of a kernel to be tested, where the kernel to be tested is a kernel of a closed-source Linux operating system;

[0006] Dynamically inserting the kernel function to be inserted indicated by the target kernel function information;

[0007] When it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called, generating coverage path information of the kernel to be tested;

[0008] Based on the above coverage path information, vulnerability mining is performed on the above kernel to be tested.

[0009] In a possible implementation, the step of obtaining target kernel function information of the kernel to be tested includes:

[0010] Obtaining initial kernel function information of the kernel to be tested, wherein the initial kernel function information includes all initial kernel function symbols;

[0011] All initial kernel function symbols in the initial kernel function information are screened based on a preset source code file path blacklist and a preset source code file path whitelist to obtain the target kernel function information of the kernel to be tested.

[0012] In a possible implementation, all initial kernel function symbols in the initial kernel function information are screened based on the preset source code file path blacklist and source code file path whitelist to obtain the target kernel function information of the kernel to be tested, including:

[0013] Determine a plurality of candidate kernel function symbols from all the initial kernel function symbols in the initial kernel function information based on a preset source code file path whitelist;

[0014] Determine a target kernel function symbol from the plurality of candidate kernel function symbols based on a preset source code file path blacklist;

[0015] The target kernel function symbol is determined as the target kernel function information of the kernel to be tested.

[0016] In a possible implementation, before dynamically inserting the kernel function to be inserted indicated by the target kernel function information, the method further includes:

[0017] Start the test task for the above kernel to be tested;

[0018] Loading a preset kernel driver, the kernel driver is used to provide the coverage path statistics-related IOCTL interface required for the dynamic instrumentation process, the dynamic instrumentation call-related interface and the kernel code coverage path tracking-related API function;

[0019] The above-mentioned dynamically inserting the kernel function to be inserted indicated by the above-mentioned target kernel function information includes:

[0020] A kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information is created through the kernel driver, and the kprobe probe object is registered in the kernel function.

[0021] In a possible implementation, the above-mentioned creation of a kprobe probe object corresponding to the kernel function to be plugged indicated by the above-mentioned target kernel function information through the above-mentioned kernel driver, and registration of the above-mentioned kprobe probe object in the above-mentioned kernel function, includes:

[0022] Parsing the target kernel function information through a user-mode program to obtain a parsing result corresponding to the target kernel function information;

[0023] Sending the parsing result to the character device driver provided by the kernel driver through the IOCTL interface provided by the kernel driver;

[0024] A kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information is created through the character device driver, and the kprobe probe object is registered in the kernel function.

[0025] In a possible implementation, when it is detected that a kernel function that has been dynamically instrumented in the kernel to be tested is called, generating coverage path information of the kernel to be tested includes:

[0026] When it is detected that the kernel function that has been dynamically plugged in the kernel to be tested is called, the API function provided by the kernel driver is called to record the coverage path information of the kernel to be tested through the API function.

[0027] In a possible implementation, the vulnerability mining of the kernel to be tested based on the coverage path information includes:

[0028] Mutate the fuzzy test case corresponding to the kernel to be tested based on the coverage path information to obtain a new fuzzy test case;

[0029] Determine the test result corresponding to the new fuzzy test case;

[0030] According to the above test results, vulnerability mining is carried out on the above kernel to be tested.

[0031] In a second aspect, an embodiment of the present application provides a closed-source kernel vulnerability mining device, the device comprising:

[0032] An acquisition module is used to acquire target kernel function information of a kernel to be tested, where the kernel to be tested is a kernel of a closed-source Linux operating system;

[0033] The plugging module is used to dynamically plug the kernel function to be plugged indicated by the target kernel function information;

[0034] A generation module, used for generating coverage path information of the kernel to be tested when it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called;

[0035] The mining module is used to mine vulnerabilities in the kernel to be tested based on the coverage path information.

[0036] In a possible implementation, the acquisition module includes:

[0037] An acquisition unit, used for acquiring initial kernel function information of the kernel to be tested, wherein the initial kernel function information includes all initial kernel function symbols;

[0038] The screening unit is used to screen all initial kernel function symbols in the initial kernel function information based on a preset source code file path blacklist and a source code file path whitelist to obtain the target kernel function information of the kernel to be tested.

[0039] In a possible implementation, the screening unit includes:

[0040] A first determination subunit is used to determine a plurality of candidate kernel function symbols from all initial kernel function symbols in the initial kernel function information based on a preset source code file path whitelist;

[0041] A second determination subunit is used to determine a target kernel function symbol from the above-mentioned multiple candidate kernel function symbols based on a preset source code file path blacklist;

[0042] The third determining subunit is used to determine the target kernel function symbol as the target kernel function information of the kernel to be tested.

[0043] In a possible implementation, the above device further includes:

[0044] A startup module, used to start the test task for the above-mentioned kernel to be tested;

[0045] A loading module is used to load a preset kernel driver, wherein the kernel driver is used to provide IOCTL interfaces related to coverage path statistics, dynamic instrumentation call related interfaces, and API functions related to kernel code coverage path tracking required by the dynamic instrumentation process;

[0046] The above-mentioned instrumentation module includes:

[0047] The registration unit is used to create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through the kernel driver, and register the kprobe probe object in the kernel function.

[0048] In a possible implementation, the registration unit includes:

[0049] The parsing subunit is used to parse the target kernel function information through the user state program to obtain the parsing result corresponding to the target kernel function information;

[0050] A sending subunit, used for sending the parsing result to the character device driver provided by the kernel driver through the IOCTL interface provided by the kernel driver;

[0051] The registration subunit is used to create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through the character device driver, and register the kprobe probe object in the kernel function.

[0052] In a possible implementation, the generation module includes:

[0053] The recording unit is used to call the API function provided by the kernel driver when it is detected that the kernel function that has been dynamically inserted in the kernel to be tested is called, so as to record the coverage path information of the kernel to be tested through the API function.

[0054] In a possible implementation, the mining module includes:

[0055] A generating unit, configured to mutate the fuzzy test case corresponding to the kernel to be tested based on the coverage path information to obtain a new fuzzy test case;

[0056] A determination unit, used to determine the test result corresponding to the above new fuzzy test case;

[0057] The mining unit is used to mine vulnerabilities in the kernel to be tested according to the test results.

[0058] In a third aspect, an embodiment of the present application provides an electronic device, including: a processor and a memory;

[0059] The above-mentioned memory stores a computer program, and the above-mentioned computer program is suitable for being loaded by the above-mentioned processor and executing the steps of the method provided by the first aspect of the embodiment of the present application or any possible implementation method of the first aspect.

[0060] In a fourth aspect, an embodiment of the present application provides a computer storage medium, which stores multiple instructions, and the instructions are suitable for being loaded by a processor and executing the steps of the method provided by the first aspect of the embodiment of the present application or any possible implementation method of the first aspect.

[0061] The embodiment of the present application obtains the target kernel function information of the kernel to be tested, and the kernel to be tested is the kernel of the closed-source Linux operating system; dynamically inserts the kernel function to be inserted indicated by the target kernel function information; when it is detected that the kernel function that has been dynamically inserted in the kernel to be tested is called, the coverage path information of the kernel to be tested is generated; and the kernel to be tested is mined based on the coverage path information. Kernel vulnerability mining is performed by dynamic insertion, which allows monitoring and analysis of specific kernel functions at runtime, and in-depth understanding of the kernel behavior without source code; and combined with coverage path information, it allows testers to observe the execution of kernel functions, function call relationships, etc. at runtime, which helps to discover potential security vulnerabilities or logical defects in the kernel. The use of this solution can test closed-source kernels with coverage feedback, effectively improving the efficiency of vulnerability mining for closed-source kernels. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0063] Figure 1 A schematic diagram of the structure of a closed-source kernel vulnerability mining system provided by an exemplary embodiment of the present application;

[0064] Figure 2 A flowchart of a closed-source kernel vulnerability mining method provided by an exemplary embodiment of the present application;

[0065] Figure 3 A schematic diagram of the structure of a closed-source kernel plug-in submodule provided for an exemplary embodiment of the present application;

[0066] Figure 4 A flowchart of a method for generating coverage path information provided by an exemplary embodiment of the present application;

[0067] Figure 5 A schematic diagram of the structure of a closed-source kernel vulnerability mining device provided by an exemplary embodiment of the present application;

[0068] Figure 6 A schematic structural diagram of an electronic device provided as an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0069] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0070] The terms "first", "second", "third", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices.

[0071] Please refer to the following Figure 1 , which exemplarily shows a structural diagram of a closed-source kernel vulnerability mining system provided by an embodiment of the present application. Figure 1 As shown, the system includes a website user interface (WEB UI) interface, a test management module and a test implementation module; the closed-source kernel vulnerability mining method provided in the embodiment of the present application can be executed by a closed-source kernel vulnerability mining system.

[0072] Optionally, the closed-source kernel vulnerability mining system interacts with the user through a WEB UI interface. In an embodiment of the present application, the WEB UI interface is used to obtain the task name, test target time, test target crash number, test kernel target type, and template library and test machine node used by the user in the task creation interface, and send this information to the test management module. Among them, a browser / server mode (Browser / Server, BS) can be used between the test management module and the WEB UI interface.

[0073] Optionally, the test implementation module may include a closed-source kernel plug-in submodule. When the test target selected by the user is a closed-source kernel (i.e., the kernel of a closed-source operating system) and a test with coverage path guidance is required, the closed-source kernel plug-in submodule will be called to obtain the target kernel function information of the kernel to be tested, where the kernel to be tested is a closed-source kernel; dynamically plug the kernel function to be plugged indicated by the target kernel function information; and generate coverage path information of the test kernel when the fuzzy test case is executed and when it is detected that the kernel function that has been dynamically plugged in the test kernel is called.

[0074] Furthermore, the test implementation module may send the coverage path information to the test management module, so that the test management module can guide the mutation of the fuzzy test case based on the coverage path information.

[0075] It should be noted that the closed-source kernel vulnerability mining system here can be set in any device such as a smartphone, a tablet computer, an e-reader, a desktop computer, a laptop computer, a server, etc., and this application does not limit this.

[0076] An exemplary embodiment of the present application provides a closed-source kernel vulnerability mining method. The closed-source kernel vulnerability mining method can be applied to the above-mentioned closed-source kernel vulnerability mining system. For details, please refer to Figure 2 , which exemplarily shows a flow chart of a closed-source kernel vulnerability mining method provided by an embodiment of the present application. Figure 2 As shown, the closed-source kernel vulnerability mining method includes the following S21-S24:

[0077] S21. Obtain target kernel function information of a kernel to be tested, where the kernel to be tested is a kernel of a closed-source Linux operating system.

[0078] In some embodiments, the target kernel function information of the kernel to be tested may be a set of kernel symbols of the kernel function to be plugged in. The kernel symbol is used to uniquely indicate the corresponding kernel function. The kernel to be tested is a closed-source Linux operating system kernel.

[0079] Among them, a closed-source kernel refers to a kernel whose source code is not fully disclosed and ordinary users cannot view, modify or distribute its source code.

[0080] S22: Dynamically insert the kernel function to be inserted indicated by the target kernel function information.

[0081] Among them, dynamic instrumentation is a technology that inserts code while the program is running. Dynamic instrumentation can be used in scenarios such as performance analysis, debugging, monitoring, tracing and testing.

[0082] In some embodiments, the instrumented kernel function indicated by the target kernel function information is a kernel function corresponding to each kernel symbol in a set of kernel symbols indicated by the target kernel function information.

[0083] S23. When it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called, coverage path information of the kernel to be tested is generated.

[0084] That is, when it is detected that a dynamic stub has been inserted into the kernel to be tested (a kprobe probe object has been registered) and a kernel function has been called, coverage path information of the function can be automatically generated.

[0085] In some embodiments, the above-mentioned coverage path information may be a record of whether the execution path of the program (ie, different execution branches and paths in the code) is actually accessed or executed during the test process.

[0086] S24. Perform vulnerability mining on the kernel to be tested based on the coverage path information.

[0087] In some embodiments, the above coverage path information can be used to help relevant developers understand which code segments are covered by the test and which code segments are not executed, so as to optimize test cases, analyze code coverage, and discover potential untested paths based on the coverage path information.

[0088] The embodiment of the present application obtains the target kernel function information of the kernel to be tested, and the kernel to be tested is the kernel of the closed-source Linux operating system; dynamically inserts the kernel function to be inserted indicated by the target kernel function information; when it is detected that the kernel function that has been dynamically inserted in the kernel to be tested is called, the coverage path information of the kernel to be tested is generated; and the kernel to be tested is mined based on the coverage path information. Kernel vulnerability mining is performed by dynamic insertion, which allows monitoring and analysis of specific kernel functions at runtime, and in-depth understanding of the kernel behavior without source code; and combined with coverage path information, it allows testers to observe the execution of kernel functions, function call relationships, etc. at runtime, which helps to discover potential security vulnerabilities or logical defects in the kernel. The use of this solution can test closed-source kernels with coverage feedback, effectively improving the efficiency of vulnerability mining for closed-source kernels.

[0089] In some embodiments, in S21, the above-mentioned obtaining the target kernel function information of the kernel to be tested includes S211-S212:

[0090] S211 . Obtain initial kernel function information of the kernel to be tested, wherein the initial kernel function information includes all initial kernel function symbols.

[0091] In some embodiments, the initial kernel function information includes all initial kernel function symbols which are symbols of all kernel functions of the kernel to be tested.

[0092] S212: Filter all initial kernel function symbols in the initial kernel function information based on a preset source code file path blacklist and a preset source code file path whitelist to obtain the target kernel function information of the kernel to be tested.

[0093] In some embodiments, the source code file path blacklist includes a pre-set source code file path where the first kernel function is located. The first kernel function may be a function that the developer does not want or need to execute in the test. The first kernel function may be a function that is no longer in the test target or is not suitable for testing for other reasons. By blacklisting the symbols of these functions, they can be prevented from being dynamically plugged and tested.

[0094] In some embodiments, the source code file path whitelist includes a pre-set source code file path where the second kernel function is located. The second kernel function may be a function that the developer wishes to execute and monitor during testing. The second kernel function may be a function that needs to be tested intensively or plays an important role in a specific test scenario. By including the source code file path where the second kernel function is located in the whitelist, the second kernel function may be dynamically instrumented, monitored, and tested.

[0095] Optionally, the source code file path whitelist and the source code file path blacklist may be regular expression rule lists.

[0096] In the embodiment of the present application, by performing black and white list screening on kernel function symbols, it is possible to control which kernel functions will be executed and monitored, thereby performing kernel testing more efficiently and accurately.

[0097] In some embodiments, in S212, all initial kernel function symbols in the initial kernel function information are screened based on the preset source code file path blacklist and source code file path whitelist to obtain the target kernel function information of the kernel to be tested, including S2121-S2123:

[0098] S2121. Determine a plurality of candidate kernel function symbols from all initial kernel function symbols in the initial kernel function information based on a preset source code file path whitelist.

[0099] In some embodiments, in S2121, multiple candidate kernel function symbols are determined from all initial kernel function symbols in the initial kernel function information based on a preset source code file path whitelist, including:

[0100] For each initial kernel function symbol in the above-mentioned initial kernel function information, the above-mentioned initial kernel function symbol is matched with the source code file path of each second kernel function in the preset source code file path whitelist, and it is determined whether the above-mentioned source code file path whitelist includes the source code file path of the second kernel function that matches the above-mentioned initial kernel function symbol; if so, the above-mentioned initial kernel function symbol is determined as a candidate kernel function symbol, and then multiple candidate kernel function symbols are determined from all the above-mentioned initial kernel function symbols.

[0101] In some embodiments, if the source file path whitelist does not include the source file path of the second kernel function that matches the initial kernel function symbol, the initial kernel function symbol is filtered, indicating that the initial kernel function symbol is not a candidate kernel function symbol.

[0102] S2122: Determine a target kernel function symbol from the multiple candidate kernel function symbols based on a preset source code file path blacklist.

[0103] In some embodiments, in S2122, determining a target kernel function symbol from the plurality of candidate kernel function symbols based on a preset source code file path blacklist includes:

[0104] For each candidate kernel function symbol in the above-mentioned candidate kernel function information, the above-mentioned candidate kernel function symbol is matched with the source code file path of each first kernel function in the preset source code file path blacklist, and it is determined whether the above-mentioned source code file path blacklist includes the source code file path of the first kernel function matching the above-mentioned candidate kernel function symbol; if not, the above-mentioned candidate kernel function symbol is determined as the target kernel function symbol, and then multiple target kernel function symbols are determined from the above-mentioned multiple candidate kernel function symbols.

[0105] In some embodiments, if the source file path blacklist includes the source file path of the first kernel function that matches the candidate kernel function symbol, the candidate kernel function symbol is filtered, indicating that the candidate kernel function symbol is not the target kernel function symbol.

[0106] S2123: Determine the target kernel function symbol as the target kernel function information of the kernel to be tested.

[0107] The target kernel function symbols can form a symbol set, which can be determined as the target kernel function information of the kernel to be tested.

[0108] In some embodiments, the relevant kernel driver can collect the initial kernel function information of the above-mentioned kernel to be tested, and filter all the initial kernel function symbols in the above-mentioned initial kernel function information based on the preset source code file path blacklist and source code file path whitelist to obtain the target kernel function information of the above-mentioned kernel to be tested.

[0109] In the embodiment of the present application, by combining the whitelist and the blacklist, the target kernel function information to be tested can be accurately screened out. In addition, the whitelist and the blacklist can be flexibly adjusted according to different test requirements, effectively improving the efficiency and reliability of the test.

[0110] In some embodiments, before executing S22 and dynamically inserting the kernel function to be inserted indicated by the target kernel function information, the method further includes S01-S02:

[0111] S01. Start a test task for the above kernel to be tested.

[0112] In some embodiments, the test task of the kernel to be tested can be started through a related command line or script.

[0113] S02. Load a preset kernel driver, where the kernel driver is used to provide IOCTL interfaces related to coverage path statistics, dynamic instrumentation call related interfaces, and API functions related to kernel code coverage path tracking required for the dynamic instrumentation process.

[0114] In some embodiments, the preset kernel driver is disposed in the closed-source kernel plug-in submodule.

[0115] Figure 3 The following is a schematic diagram of the structure of a closed-source kernel plug-in submodule provided by an exemplary embodiment of the present application. Figure 3 As shown, the closed-source kernel plug-in submodule includes KCOV_DEVICE (KCOV device) kernel driver, KCOV_INSTRUCTION (KCOV instruction) kernel driver and KCOV_KPROBE_PREPARE (kernel probe mechanism preparation) kernel driver. Among them, KCOV is a cross-platform code coverage testing tool.

[0116] Among them, the KCOV_INSTRUCTION kernel driver can include three driver units. The first driver unit is the user-mode program for collecting the initial kernel function information of the kernel to be tested. The first driver unit is also used to screen the function symbols with the blacklist and whitelist constructed by the source code path, and obtain the function symbol set to be inserted (target kernel function information) through the communication interface / dev / instruction between the user-mode program and the kernel mode to transfer the target function symbol to be inserted. The first driver unit is executed before the test task is created to collect the target function symbols to be inserted in advance.

[0117] The second driver unit of the KPROBE_INSTRUCTION kernel driver is used to expose a character device driver to the user-mode program of the third driver unit, receive a set of function symbols to be plugged in, i.e., target kernel function information, sent by the third driver unit in the IOCTL interface of the character device driver, create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information, and register the kprobe probe object in the kernel function.

[0118] The third driver unit of the KPROBE_INSTRUCTION kernel driver is a user-mode program, which is used to parse the function symbol set (target kernel function information) to be plugged in upon receiving the plugging instruction and pass the parsing result to the second driver unit. The third driver unit is executed when the test task is started.

[0119] The KCOV_DEVICE kernel driver is a driver module that can be dynamically loaded into the kernel to be tested. The kernel driver is modified from the KCOV driver in the Linux kernel mainline code and is used to provide dynamic instrumentation APIs and other related necessary API functions to other kernel drivers.

[0120] The KCOV_KPROBE_PREPARE kernel driver is used to initialize and prepare for the subsequent generation of coverage path information. Specifically, the KCOV_KPROBE_PREPARE kernel driver uses the kernel's KPROBE (kernel probe) mechanism to hook some key kernel functions, which are related to operations such as process creation, exit, and context switching.

[0121] In some embodiments, the closed-source kernel plug-in submodule also includes a target closed-source kernel image to be tested, and the closed-source kernel image can contain all functional modules and interfaces of the kernel to be tested. The various kernel drivers mentioned above can interact with the closed-source kernel image to achieve coverage tracking and monitoring of the kernel code path. In this mode, although the kernel itself is closed-source, through mechanisms such as HOOK and KPROBE, it is still possible to dynamically monitor the execution of kernel functions and collect coverage path information to meet testing and analysis requirements.

[0122] In some embodiments, in S02, the preset kernel driver may specifically include: a KCOV_DEVICE kernel driver, a KPROBE_INSTRUCTION kernel driver, and a second driver unit of the KPROBE_INSTRUCTION kernel driver.

[0123] In the embodiment of the present application, the closed-source kernel plug-in submodule separates different functions into multiple kernel drivers, so that each kernel driver is focused on a specific task. The modular design makes the code easier to maintain, debug and expand, and each driver can be updated or optimized independently without affecting the work of the entire system. In addition, the kernel driver and the user-mode program interact through the character device driver and the IOCTL interface, allowing the kernel plug-in to be performed flexibly without modifying the kernel code. This decoupling method enables the user-mode program to more easily control the kernel behavior and perform functional debugging and modification.

[0124] In some embodiments, in S22, the above-mentioned dynamically inserting the kernel function to be inserted indicated by the above-mentioned target kernel function information includes S221:

[0125] S221. Create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through the kernel driver, and register the kprobe probe object in the kernel function.

[0126] In some embodiments, the kernel driver may provide a required configuration environment for creating a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information, and registering the kprobe probe object in the kernel function.

[0127] In some embodiments, in S221, the kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information is created through the kernel driver, and the kprobe probe object is registered in the kernel function, including S2211-S2213:

[0128] S2211. parse the target kernel function information through a user-mode program to obtain a parsing result corresponding to the target kernel function information.

[0129] In some embodiments, the user-mode program is a third driver unit provided by the KPROBE_INSTRUCTION kernel driver.

[0130] In some embodiments, the parsing result is the target kernel function symbol indicated by the target kernel function information.

[0131] S2212. Send the parsing result to the character device driver provided by the kernel driver through the IOCTL interface provided by the kernel driver.

[0132] Among them, in the computer, IOCTL (Input / Output Control) is a system call dedicated to device input and output operations. The call passes in a request code related to the device, and the function of the system call depends entirely on the request code. The IOCTL interface (input / output control interface) is a mechanism for communication between the kernel and user-mode programs. It allows user-mode programs to interact with the kernel driver through specific commands to control kernel operations or exchange data.

[0133] S2213. Create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through the character device driver, and register the kprobe probe object in the kernel function.

[0134] Kprobe is a mechanism provided by the Linux kernel to insert probe objects at specified kernel functions or addresses in the kernel in order to track function calls, execution status, or obtain information such as variable values ​​inside kernel functions. Kprobe probe objects can include a hook, and developers can insert custom code before and after the execution of the kernel function to be inserted, or collect information during the execution of the kernel function.

[0135] In some embodiments, the above registration of the kprobe probe object refers to adding the created kprobe probe object to the probe management system of the kernel to make it effective. Once the probe is successfully registered, the kernel will trigger the probe when the kernel function is called.

[0136] In an embodiment of the present application, through the kprobe mechanism, developers can insert custom code or logic during the execution of kernel functions without modifying the kernel code, thereby achieving dynamic monitoring and debugging without affecting the kernel code, effectively improving the stability of operation and the efficiency of coverage path information collection.

[0137] In some embodiments, in S23, when it is detected that a kernel function that has been dynamically instrumented in the kernel to be tested is called, generating coverage path information of the kernel to be tested includes S231:

[0138] S231. When it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called, the API function provided by the kernel driver is called to record coverage path information of the kernel to be tested through the API function.

[0139] Optionally, when a kernel function that has been dynamically instrumented is called, the corresponding kprobe probe object is triggered, and then the application programming interface (Application Programming Interface, API) function provided by the KCOV_DEVICE kernel driver can be jumped to. These API functions are responsible for collecting and maintaining coverage path information. Specifically, the API can be Figure 3 / dev / kcov interface in the Linux kernel. / dev / kcov is a special device file in the Linux kernel that is specifically used for code coverage collection. Especially in the testing and analysis of kernel code, it allows user-mode programs to collect coverage path information executed in the kernel through interfaces.

[0140] In the embodiment of the present application, the API records the execution path of the kernel function, which can provide more accurate path coverage information, and is helpful for subsequent mutation of the test corpus, thereby improving the effectiveness of the test corpus.

[0141] In some embodiments, in S24, the vulnerability mining of the kernel to be tested based on the coverage path information includes S241-S243:

[0142] S241. Mutate the fuzzy test case corresponding to the kernel to be tested based on the coverage path information to obtain a new fuzzy test case.

[0143] In some embodiments, fuzz testing cases may include various legal and illegal inputs, and perform boundary condition tests on different function calls, system calls, and system interaction behaviors. Fuzz testing usually performs a large number of randomization, boundary conditions, format errors, and other types of input combinations on the validity of input data to expose potential vulnerabilities as much as possible.

[0144] S242. Determine the test result corresponding to the new fuzzy test case.

[0145] In some embodiments, the generated new fuzzy test case can be input into the kernel system to be tested to perform the actual test process. The kernel system can run the corresponding function or program according to the input data. During the test process, the system is detected for abnormal behaviors such as crash, memory leak, unhandled exception, error handling failure, buffer overflow, etc. If these abnormal behaviors exist, the system will record the abnormal information and mark it as a potential vulnerability.

[0146] Among them, the test results can indicate which test cases successfully exposed potential vulnerabilities and which ones did not have problems. The test results can help developers understand the vulnerability of the system.

[0147] S243. Perform vulnerability mining on the kernel to be tested according to the test results.

[0148] By analyzing the results of fuzz testing, relevant testers (such as third-party testers) can identify potential vulnerabilities exposed by the above fuzz test cases and conduct in-depth analysis. If a potential vulnerability is identified, the tester can report the vulnerability to the developer of the closed-source kernel. After fixing the vulnerability, the tester can also perform fuzz testing again to confirm the effect of the repair.

[0149] In the embodiment of the present application, by generating fuzzy test cases based on coverage path information and mining vulnerabilities in the kernel in combination with the test results, the security and stability of the kernel can be significantly improved. This method is not only automated and efficient, but can also cover paths that may be missed by traditional testing methods, and can also accelerate the process of vulnerability discovery and repair, thereby helping testers to more effectively test closed-source kernels during kernel vulnerability mining, and improve the reliability and security of the tested system.

[0150] Figure 4 A flowchart of a method for generating coverage path information provided by an exemplary embodiment of the present application is shown as follows: Figure 4 The coverage path information generation method specifically includes S41-S48:

[0151] S41, obtaining initial kernel function information of the kernel to be tested.

[0152] S42: Filter all initial kernel function symbols in the initial kernel function information based on a preset source code file path blacklist and a preset source code file path whitelist to obtain target kernel function information of the kernel to be tested.

[0153] Optionally, the specific process of S41-S42 is consistent with the above-mentioned S211-S212, and will not be repeated here.

[0154] S43: Start the test task for the kernel to be tested.

[0155] S44. Load the preset kernel driver.

[0156] Optionally, the specific process of S43-S44 is consistent with the above-mentioned S01-S02, and will not be repeated here.

[0157] S45. Parse the target kernel function information through a user-mode program provided by the kernel driver to obtain a parsing result corresponding to the target kernel function information.

[0158] S46. Send the parsing result to the character device driver provided by the kernel driver through the IOCTL interface provided by the kernel driver.

[0159] S47. Create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through a character device driver, and register the kprobe probe object in the kernel function.

[0160] Optionally, the specific process of S45-S47 is consistent with the above-mentioned S2211-S2213 and will not be repeated here.

[0161] S48. When it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called, an application programming interface provided by the kernel driver is called to record coverage path information of the kernel to be tested through the application programming interface.

[0162] Optionally, the specific process of S48 is consistent with the above S231 and will not be repeated here.

[0163] By dynamically instrumenting the target kernel function and accurately tracking the execution of the kernel function, it helps relevant developers understand the code coverage and effectively improves the accuracy and reliability of the coverage path information.

[0164] Please refer to the following Figure 5 , which is a schematic diagram of the structure of a closed-source kernel vulnerability mining device provided by an exemplary embodiment of the present application. Figure 5 As shown, the closed-source kernel vulnerability mining device 500 includes:

[0165] An acquisition module 501 is used to acquire target kernel function information of a kernel to be tested, where the kernel to be tested is a kernel of a closed-source Linux operating system;

[0166] The plugging module 502 is used to dynamically plug the kernel function to be plugged indicated by the target kernel function information;

[0167] A generating module 503, configured to generate coverage path information of the kernel to be tested when it is detected that a kernel function that has been dynamically instrumented in the kernel to be tested is called;

[0168] The mining module 504 is used to mine vulnerabilities in the kernel to be tested based on the coverage path information.

[0169] In a possible implementation, the acquisition module 501 includes:

[0170] An acquisition unit, used for acquiring initial kernel function information of the kernel to be tested, wherein the initial kernel function information includes all initial kernel function symbols;

[0171] The screening unit is used to screen all initial kernel function symbols in the initial kernel function information based on a preset source code file path blacklist and a source code file path whitelist to obtain the target kernel function information of the kernel to be tested.

[0172] In a possible implementation, the screening unit includes:

[0173] A first determination subunit is used to determine a plurality of candidate kernel function symbols from all initial kernel function symbols in the initial kernel function information based on a preset source code file path whitelist;

[0174] A second determination subunit is used to determine a target kernel function symbol from the above-mentioned multiple candidate kernel function symbols based on a preset source code file path blacklist;

[0175] The third determining subunit is used to determine the target kernel function symbol as the target kernel function information of the kernel to be tested.

[0176] In a possible implementation, the apparatus 500 further includes:

[0177] A startup module, used to start the test task for the above-mentioned kernel to be tested;

[0178] A loading module is used to load a preset kernel driver, wherein the kernel driver is used to provide IOCTL interfaces related to coverage path statistics, dynamic instrumentation call related interfaces, and API functions related to kernel code coverage path tracking required by the dynamic instrumentation process;

[0179] The above-mentioned plug-in module 502 includes:

[0180] The registration unit is used to create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through the kernel driver, and register the kprobe probe object in the kernel function.

[0181] In a possible implementation, the registration unit includes:

[0182] The parsing subunit is used to parse the target kernel function information through the user state program to obtain the parsing result corresponding to the target kernel function information;

[0183] A sending subunit, used for sending the parsing result to the character device driver provided by the kernel driver through the IOCTL interface provided by the kernel driver;

[0184] The registration subunit is used to create a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through the character device driver, and register the kprobe probe object in the kernel function.

[0185] In a possible implementation, the generation module includes:

[0186] The recording unit is used to call the API function provided by the kernel driver when it is detected that the kernel function that has been dynamically inserted in the kernel to be tested is called, so as to record the coverage path information of the kernel to be tested through the API function.

[0187] In a possible implementation, the mining module 504 includes:

[0188] A generating unit, configured to mutate the fuzzy test case corresponding to the kernel to be tested based on the coverage path information to obtain a new fuzzy test case;

[0189] A determination unit, used to determine the test result corresponding to the above new fuzzy test case;

[0190] The mining unit is used to mine vulnerabilities in the kernel to be tested according to the test results.

[0191] The division of each module in the above-mentioned closed-source kernel vulnerability mining device 500 is only for illustration. In other embodiments, the closed-source kernel vulnerability mining device can be divided into different modules as needed to complete all or part of the functions of the above-mentioned closed-source kernel vulnerability mining device. The implementation of each module in the closed-source kernel vulnerability mining device provided in the embodiment of this specification can be in the form of a computer program. The computer program can be run on a terminal or a server. The program modules constituted by the computer program can be stored in the memory of the terminal or the server. When the computer program is executed by the processor, all or part of the steps of the closed-source kernel vulnerability mining method described in the embodiment of this specification are implemented.

[0192] See next Figure 6 , which is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present application. Figure 6 As shown, the electronic device 600 may include: a processor 610 and a memory 620 , and may also include a user interface 630 , a network interface 640 and a communication bus 650 .

[0193] Among them, the processor 610 may include one or more processing cores. The processor 610 uses various interfaces and lines to connect various parts of the entire electronic device 600, and executes various functions and processes data of the electronic device 600 by running or executing instructions, programs, code sets or instruction sets stored in the memory 620, and calling data stored in the memory 620. Optionally, the processor 610 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The processor 610 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 610, and it can be implemented separately through a chip.

[0194] The memory 620 may include a random access memory (RAM) or a read-only memory (Read-Only Memory). Optionally, the memory 620 includes a non-transitory computer-readable storage medium. The memory 620 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 620 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a receiving function, a control function, etc.), instructions for implementing the above-mentioned method embodiments, etc.; the data storage area may store data involved in the above-mentioned method embodiments, etc. The memory 620 may optionally be at least one storage device located away from the aforementioned processor 610. As Figure 6 As shown, the memory 620 as a computer storage medium may include an operating system, a network communication module, a user interface module, and program instructions.

[0195] Optionally, the communication bus 650 is used to realize the connection and communication between these components. The user interface 630 may include a display screen (Display), a camera (Camera), and may also include a standard wired interface and a wireless interface; the network interface 640 may optionally include a standard wired interface and a wireless interface (such as a WIFI interface).

[0196] exist Figure 6 In the electronic device 600 shown, the processor 610 may be used to call the program instructions stored in the memory 620 and specifically perform the following operations:

[0197] Obtain target kernel function information of a kernel to be tested, where the kernel to be tested is a kernel of a closed-source Linux operating system;

[0198] Dynamically inserting the kernel function to be inserted indicated by the target kernel function information;

[0199] When it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called, generating coverage path information of the kernel to be tested;

[0200] Based on the above coverage path information, vulnerability mining is performed on the above kernel to be tested.

[0201] In a possible implementation, the step of obtaining target kernel function information of the kernel to be tested includes:

[0202] Obtaining initial kernel function information of the kernel to be tested, wherein the initial kernel function information includes all initial kernel function symbols;

[0203] All initial kernel function symbols in the initial kernel function information are screened based on a preset source code file path blacklist and a preset source code file path whitelist to obtain the target kernel function information of the kernel to be tested.

[0204] In a possible implementation, all initial kernel function symbols in the initial kernel function information are screened based on the preset source code file path blacklist and source code file path whitelist to obtain the target kernel function information of the kernel to be tested, including:

[0205] Determine a plurality of candidate kernel function symbols from all the initial kernel function symbols in the initial kernel function information based on a preset source code file path whitelist;

[0206] Determine a target kernel function symbol from the plurality of candidate kernel function symbols based on a preset source code file path blacklist;

[0207] The target kernel function symbol is determined as the target kernel function information of the kernel to be tested.

[0208] In a possible implementation, before dynamically inserting the kernel function to be inserted indicated by the target kernel function information, the method further includes:

[0209] Start the test task for the above kernel to be tested;

[0210] Loading a preset kernel driver, the kernel driver is used to provide the coverage path statistics-related IOCTL interface required for the dynamic instrumentation process, the dynamic instrumentation call-related interface and the kernel code coverage path tracking-related API function;

[0211] The above-mentioned dynamically inserting the kernel function to be inserted indicated by the above-mentioned target kernel function information includes:

[0212] A kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information is created through the kernel driver, and the kprobe probe object is registered in the kernel function.

[0213] In a possible implementation, the above-mentioned creation of a kprobe probe object corresponding to the kernel function to be plugged indicated by the above-mentioned target kernel function information through the above-mentioned kernel driver, and registration of the above-mentioned kprobe probe object in the above-mentioned kernel function, includes:

[0214] Parsing the target kernel function information through a user-mode program to obtain a parsing result corresponding to the target kernel function information;

[0215] Sending the parsing result to the character device driver provided by the kernel driver through the IOCTL interface provided by the kernel driver;

[0216] A kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information is created through the character device driver, and the kprobe probe object is registered in the kernel function.

[0217] In a possible implementation, when it is detected that a kernel function that has been dynamically instrumented in the kernel to be tested is called, generating coverage path information of the kernel to be tested includes:

[0218] When it is detected that the kernel function that has been dynamically plugged in the kernel to be tested is called, the API function provided by the kernel driver is called to record the coverage path information of the kernel to be tested through the API function.

[0219] In a possible implementation, the vulnerability mining of the kernel to be tested based on the coverage path information includes:

[0220] Mutate the fuzzy test case corresponding to the kernel to be tested based on the coverage path information to obtain a new fuzzy test case;

[0221] Determine the test result corresponding to the new fuzzy test case;

[0222] According to the above test results, vulnerability mining is carried out on the above kernel to be tested.

[0223] The embodiment of the present application also provides a computer-readable storage medium, which stores instructions, and when the instructions are executed on a computer or a processor, the computer or the processor executes one or more steps in the above embodiment. If the components of the above closed-source kernel vulnerability mining device are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium.

[0224] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The above-mentioned computer program product includes one or more computer instructions. When the above-mentioned computer program instructions are loaded and executed on a computer, the above-mentioned process or function according to the embodiment of the present application is generated in whole or in part. The above-mentioned computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The above-mentioned computer instructions can be stored in a computer-readable storage medium or transmitted by the above-mentioned computer-readable storage medium. The above-mentioned computer instructions can be transmitted from a website site, a computer, a server or a data center to another website site, a computer, a server or a data center by wired (such as coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode. The above-mentioned computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that contains one or more available media integrated. The above-mentioned available media can be magnetic media (for example, floppy disks, hard disks, tapes), optical media (for example, digital versatile discs (DVD)), or semiconductor media (for example, solid state disks (SSD)), etc.

[0225] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk and other media that can store program codes. In the absence of conflict, the technical features in this embodiment and the implementation scheme can be combined arbitrarily.

[0226] The above-mentioned embodiments are merely preferred embodiments of the present application and are not intended to limit the scope of the present application. Without departing from the design spirit of the present application, various modifications and improvements made to the technical solutions of the present application by ordinary technicians in this field should fall within the protection scope determined by the claims of the present application.

Claims

1. A closed-source kernel vulnerability mining method, characterized in that: include: Obtaining target kernel function information of a kernel to be tested, wherein the kernel to be tested is a kernel of a closed-source Linux operating system; Dynamically inserting the kernel function to be inserted indicated by the target kernel function information; When it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called, generating coverage path information of the kernel to be tested; Vulnerabilities are mined for the kernel to be tested based on the coverage path information.

2. The method according to claim 1, characterized in that The step of obtaining target kernel function information of the kernel to be tested includes: Acquire initial kernel function information of the kernel to be tested, wherein the initial kernel function information includes all initial kernel function symbols; The initial kernel function information is screened based on a preset source code file path blacklist and a preset source code file path whitelist to obtain target kernel function information of the kernel to be tested.

3. The method according to claim 2, characterized in that The method of screening all initial kernel function symbols in the initial kernel function information based on a preset source code file path blacklist and a source code file path whitelist to obtain target kernel function information of the kernel to be tested includes: Determine a plurality of candidate kernel function symbols from all initial kernel function symbols in the initial kernel function information based on a preset source code file path whitelist; Determining a target kernel function symbol from the plurality of candidate kernel function symbols based on a preset source code file path blacklist; The target kernel function symbol is determined as the target kernel function information of the kernel to be tested.

4. The method according to claim 1, characterized in that Before dynamically inserting the kernel function to be inserted indicated by the target kernel function information, the method further includes: Starting a test task for the kernel to be tested; Loading a preset kernel driver, the kernel driver is used to provide the coverage path statistics-related IOCTL interface required by the dynamic instrumentation process, the dynamic instrumentation call-related interface and the kernel code coverage path tracking-related API function; The dynamically inserting the kernel function to be inserted indicated by the target kernel function information comprises: A kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information is created through the kernel driver, and the kprobe probe object is registered in the kernel function.

5. The method according to claim 4, characterized in that The step of creating a kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information through the kernel driver, and registering the kprobe probe object in the kernel function, includes: Parsing the target kernel function information through a user state program to obtain a parsing result corresponding to the target kernel function information; Sending the parsing result to the character device driver provided by the kernel driver through the IOCTL interface provided by the kernel driver; A kprobe probe object corresponding to the kernel function to be plugged indicated by the target kernel function information is created through the character device driver, and the kprobe probe object is registered in the kernel function.

6. The method according to claim 4, characterized in that When it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called, generating coverage path information of the kernel to be tested includes: When it is detected that a kernel function that has been dynamically instrumented in the kernel to be tested is called, the API function provided by the kernel driver is called to record coverage path information of the kernel to be tested through the API function.

7. The method according to claim 1, characterized in that The performing vulnerability mining on the kernel to be tested based on the coverage path information includes: Mutating the fuzzy test case corresponding to the kernel to be tested based on the coverage path information to obtain a new fuzzy test case; Determine the test result corresponding to the new fuzzy test case; Vulnerabilities are mined for the kernel to be tested according to the test results.

8. A closed-source kernel vulnerability mining device, characterized in that: include: An acquisition module is used to acquire target kernel function information of a kernel to be tested, where the kernel to be tested is a kernel of a closed-source Linux operating system; An insert module, used for dynamically inserting the kernel function to be inserted indicated by the target kernel function information; A generating module, configured to generate coverage path information of the kernel to be tested when it is detected that a kernel function that has been dynamically plugged in the kernel to be tested is called; A mining module is used to mine vulnerabilities in the kernel to be tested based on the coverage path information.

9. An electronic device, characterized in that: include: Processor and memory; The memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the steps of the method according to any one of claims 1 to 7.

10. A computer storage medium, characterized in that: The computer storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and executing the steps of the method according to any one of claims 1 to 7.

Images