A RISCV memory overflow vulnerability detection method and device based on hardware virtualization

Abstract

The present invention discloses a RISC-V memory overflow vulnerability detection method and device based on hardware virtualization, comprising: obtaining a process kernel data structure of an operating system kernel; simulating a RISC-V CPU based on a hardware simulator; constructing a basic process list and a memory area occupancy record table of the operating system; using the sptbr register and the process kernel data structure to obtain characteristic information of a new process; obtaining a target process based on the basic process list and characteristic information; using the target process's API detection results to fill the memory area occupancy record table content to obtain a memory area list; obtaining memory access data based on the target process's instruction analysis results; and comparing the memory access data with the memory area list to obtain an overflow vulnerability detection result. The present invention can completely and transparently monitor the entire running process of a binary program on a RISC-V CPU, provides a memory overflow vulnerability configuration interface, implements transparent process monitoring and memory overflow vulnerability detection, and improves the memory overflow vulnerability detection capability and accuracy.

Description

Technical Field

[0001] The present invention belongs to the field of computer science and technology, and in particular relates to a RISC-V memory overflow vulnerability detection method and device based on hardware virtualization. Background Art

[0002] A memory overflow vulnerability is one in which the write process to stack memory or heap memory exceeds the size of the original memory area, causing subsequent system data or function pointers to be overwritten, thereby causing a program exception. Due to the influence of input samples and program execution, memory overflow vulnerabilities do not necessarily cause exceptions every time, making some vulnerabilities difficult to accurately detect. Currently, the most important detection methods for memory overflow vulnerabilities are dynamic debugging analysis and methods that embed detection code in the source code based on the compiler's Address Sanitizer function. Methods based on debugging analysis rely on manual analysis, which is time-consuming and labor-intensive. Source code-based methods do improve the detection capabilities of memory overflow vulnerabilities to a certain extent, but many software products currently do not provide source code. Therefore, source code-based analysis methods have significant limitations and are difficult to analyze binary application software.

[0003] Currently, the following methods are commonly used to detect memory overflow vulnerabilities on the RISCV platform:

[0004] 1. Debugger-based overflow vulnerability detection

[0005] Memory overflow vulnerabilities are one of the main threats to software security. Overflow vulnerabilities overwrite key variables of a program or the direction of control flow transfer by rewriting data outside of a predetermined memory area. Due to the influence of input samples, not every memory overflow can fully exploit the vulnerability's capabilities, overwrite key data, or cause a crash. Therefore, it is difficult to locate and troubleshoot some overflow vulnerabilities. Currently, the main method for detecting code overflow vulnerabilities on RISCV is to have developers analyze the program using debugging tools such as gdb when the program crashes during execution. This analysis method will miss some memory overflow vulnerabilities. GDB's intrusion into the target program itself will change its memory layout, affecting the manifestation and analysis of the vulnerability, and has significant limitations.

[0006] 2. Compiler-based overflow vulnerability detection

[0007] Some current work leverages the compiler's code optimization capabilities. During the optimization phase, handwritten overflow vulnerability detection code is embedded into the target program. During runtime, dynamic analysis is performed on the RISC-V-compatible program to detect memory overflow vulnerabilities. This approach does improve code overflow vulnerability detection capabilities to a certain extent, but since most software is distributed in binary form and source code is unavailable, source code-based overflow vulnerability detection has significant limitations.

[0008] In summary, the main drawback of current methods for dynamic program analysis on RISC-V hardware is that, due to the influence of input data, some memory overflow vulnerabilities do not cause program or system crashes, making them difficult for analysts to locate and debug. Existing analysis methods based on debugging tools have significant limitations. Although some work has used compiler optimization techniques to insert analysis code into the source code, exploiting memory overflow vulnerabilities through the inserted code, the source code of many software programs is difficult to obtain, and source code-based methods also have significant limitations. Summary of the Invention

[0009] Existing methods for detecting memory overflow vulnerabilities in programs on RISC-V CPUs rely on manual analysis or source code implementation, requiring significant manpower and material resources, resulting in high time complexity and significant limitations. The present invention aims to provide a method and device for detecting memory overflow vulnerabilities in RISC-V CPUs based on hardware virtualization. This method, by modifying a hardware simulator, extracts and demarcates the memory area allocated by the process while translating and executing RISC-V instructions, monitors the STORE instructions of RISC-V instructions, and detects memory overflow vulnerabilities.

[0010] The technical solution of the present invention includes:

[0011] A RISC-V memory overflow vulnerability detection method based on hardware virtualization, comprising the following steps:

[0012] Reverse engineer the operating system kernel running on RISCV and obtain the process kernel data structure;

[0013] Simulate the RISC-V CPU based on the hardware simulator and build the basic process list of the operating system and a memory area occupancy record table;

[0014] Use the sptbr register and the process kernel data structure to obtain the characteristic information of the new process, and filter the characteristic information according to the basic process list to obtain the target process;

[0015] A corresponding table header is created in the memory area occupancy record table, and the contents of the memory area occupancy record table are filled with the API detection result of the target process, so as to obtain a memory area list according to the occupancy of the allocated memory blocks;

[0016] Based on the instruction analysis results of the target process, memory access data is obtained;

[0017] Compare the memory access data with the memory area list to obtain the overflow vulnerability detection results.

[0018] Furthermore, the operating system includes: a Linux operating system or a Windows operating system.

[0019] Furthermore, the types of the hardware simulator include: Qemu hardware simulator.

[0020] Furthermore, the characteristic information of the new process is obtained through the following steps:

[0021] 1) Monitor the changes of the sptbr register and get the new process when a new address appears;

[0022] 2) Then, starting from the physical page pointed to by sptbr, the feature information of the new process is obtained by searching the process kernel data structure through features.

[0023] Furthermore, the characteristic information includes: module loading address, length, thread information and memory information.

[0024] Further, the API test results are obtained through the following steps:

[0025] 1) Obtain the process information and dynamic operation process information of the target process;

[0026] 2) intercepting all ecall instructions and obtaining API information, wherein the API information includes: the address of the API call, the function name, the input / output parameters, and the return value;

[0027] 3) Determine whether the function corresponding to the API call address is a memory allocation / release function:

[0028] If so, the process name, the starting address of the memory area, and the length of the memory area configured by the user are used as the API detection result;

[0029] If not, the current operation has nothing to do with memory and no processing is performed.

[0030] Furthermore, the process information of the target process includes: process structure address, page table physical address, process name, module structure information list and process current module structure pointer.

[0031] Furthermore, the memory access data is obtained by the following steps:

[0032] 1) Intercept all STORE instructions;

[0033] 2) Obtain the instruction's opcode, operands, registers, memory addresses, and memory contents;

[0034] 3) Based on the memory address location operated by the STOR instruction, the memory access data is obtained.

[0035] A storage medium stores a computer program, wherein the computer program is configured to execute the above method when running.

[0036] An electronic device includes a memory and a processor, wherein the memory stores a program for executing the above method.

[0037] The advantages and positive effects of the present invention are as follows:

[0038] The present invention can completely and transparently monitor the entire process of binary program execution on the RISC-V CPU, provide a configurable memory overflow vulnerability configuration interface, and the monitoring process does not rely on the functions or interfaces provided by the system. It can realize transparent process monitoring and memory overflow vulnerability detection, effectively improving the memory overflow vulnerability detection capability and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a flow chart of a RISC-V memory overflow detection method based on hardware virtualization of the present invention. DETAILED DESCRIPTION

[0040] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0041] The RISC memory overflow detection method of the present invention comprises:

[0042] Install the operating system on the Qemu hardware emulator;

[0043] Based on the Qemu hardware simulator, it uses the virtual sptbr register as a clue to distinguish different processes;

[0044] Based on the Qemu hardware simulator, build virtual process kernel data structure registers, parse physical memory contents, and search process kernel data structures;

[0045] Based on the Qemu hardware simulator, by modifying the decoding engine, when executing the ecall instruction in user mode, it detects whether the memory allocation / release operation is implemented, demarcates the memory area, and builds a memory area list;

[0046] Based on the Qemu hardware simulator, it provides a user-mode interface, allowing users to define the memory area to be monitored;

[0047] Based on the Qemu hardware simulator, by modifying the decoding engine and adding callback functions before and after the STORE instruction, we can detect memory overflow vulnerabilities based on the memory area interval and instruction write location.

[0048] Output memory overflow vulnerability detection results in JSON file format.

[0049] Specifically, if Figure 1 As shown, the steps of the method of the present invention are described as follows:

[0050] 1) Manually reverse engineer the operating system kernel running on RISC-V and parse the kernel data structure. The relevant data structures are mainly used in physical memory. Multi-level pointer mutual verification (operating system kernel data structures are connected using a bidirectional linked list. Whether the two values ​​in the kernel data structure point to the associated legal address can be used to detect whether it is a legal kernel data structure) is used to find the process kernel data structure, and then proceed to step 2).

[0051] 2) Based on the RISC-V CPU simulated by the Qemu hardware simulator and the Linux operating system, record the basic processes that need to be started by a general Linux operating system and build a basic process list. In the subsequent analysis, these processes are not monitored and go to step 3);

[0052] 3) Start the Linux operating system and the target process, build the process kernel data structure register, and proceed to step 4);

[0053] 4) Monitor changes in the sptbr register in the system: When a new address appears, it is considered that a new process has appeared. Then, starting from the physical page pointed to by sptbr, the process kernel data structure is searched through features to obtain the characteristic information of the current process, including module load address, length, thread information, memory information, etc. Based on this characteristic information, it is determined whether the process belongs to the basic process list. If it does, it is ignored. If not, the process information is recorded, which includes: process structure address, page table physical address, process name, module structure information list, and the process current module structure pointer, and then proceed to step 5);

[0054] 5) Modify the decoding engine for the target process and add API detection and instruction analysis code to Qemu's decoding mechanism. When Qemu is actually executed, in addition to process information, further extract dynamic running process information and proceed to step 6);

[0055] 6) Build the process kernel data structure register, starting from the physical page pointed to by sptbr, search the process kernel data structure through features, obtain the current process information, including module loading address, length, thread information, memory information, etc., and proceed to step 7).

[0056] 7) In a similar way to the system page table Build Memory area occupancy record table. By modifying the code of the Qemu virtual machine and monitoring the changes of sptbr, when a new value appears in the sptbr register, a header of the memory area occupancy record table is created in the virtual machine (the content of the table is added and deleted according to the parameters and return values ​​of the memory allocation and release functions such as malloc and free called by the process, and updated according to the parameters and return values ​​of functions such as realloc). If the memory area is occupied, the corresponding areas in the memory area occupancy record table are all set to 1 to indicate that the memory block is occupied. The content of the record table follows the memory allocation, release and other operations, and is allocated and released as needed. Go to step 8)

[0057] 8) For the target process, intercept all ecall instructions, obtain the API call address, function name, input / output parameters, and return value, and determine whether the function corresponding to the API call address is a memory allocation / release function: if so, update the memory area list according to the function return value and proceed to step 9); if not, proceed to step 10);

[0058] 9) The user enters the command line through the provided interface to configure the process name, the starting address of the memory area, the length of the memory area, and other information to add, delete, modify, and query the memory area list. Go to step 9)

[0059] 10) For the target process, intercept the STORE instruction of RISC V2. Obtain information such as the instruction's opcode, operand, register operated on, memory address operated on, and memory contents operated on. Compare the memory address location operated on by the instruction with the previous memory area occupancy record table to determine whether the access exceeds the occupied area range and whether a memory overflow has occurred. If so, output the overflow vulnerability detection result and proceed to step 10.

[0060] 11) Determine whether the target process has exited. If so, output the dynamic information in the form of a JSON file. If not, proceed to step 6)

[0061] Furthermore, the operating system is installed on the Qemu hardware emulator. Since Windows does not yet support RISC-V CPUs, it is currently only supported on Linux systems. However, the monitoring process for Windows operating systems is consistent with the monitoring process for Linux systems, and this patented method can also support Windows operating systems.

[0062] Furthermore, the Qemu hardware simulator uses the virtual sptbr register as a clue to distinguish different processes, where sptbr is the physical address of the page table of each process. Since different processes use different page tables, the page table information can uniquely identify the process. The process information is recorded by constructing a HASH table indexed by the page table address in the memory.

[0063] Furthermore, the Qemu hardware simulator is based on virtual kernel data structure registers, and a linked list is traversed in the physical memory to search for the kernel process data structure to extract process information.

[0064] Furthermore, the Qemu hardware simulator, by modifying the decoding engine, detects whether the target address of the instruction is a memory allocation / release function when the program executes the ecall instruction, and records the address and range of the memory area.

[0065] Furthermore, the Qemu hardware simulator adds a user interface, allowing the user to define the address and range of the memory area in the target process by inputting commands.

[0066] Furthermore, the Qemu hardware simulator is based on modifying the decoding engine and adding callback functions before and after the STORE instruction to implement analysis, thereby realizing analysis of the memory address and length of the instruction read and write, and judging whether the operation has caused a memory overflow vulnerability based on the address and length of the memory area. The present invention proposes a method for modifying the hardware simulator for RISCV CPU, analyzing the registers in the virtual CPU, locating and reading the key data structures of the operating system in the physical memory, identifying the process, intercepting the function calls and executed instructions of the process, and detecting memory overflow vulnerabilities occurring during the process operation. The present invention can completely and transparently monitor the entire process of program execution on the RISCV CPU, provide a configurable memory overflow vulnerability configuration interface, and the monitoring process does not rely on the functions or interfaces provided by the system. It can realize transparent process monitoring and memory overflow vulnerability detection, effectively improving the memory overflow vulnerability detection capability and accuracy.

[0067] Although the specific embodiments and drawings of the present invention are disclosed for illustrative purposes and are intended to facilitate understanding and implementation of the present invention, those skilled in the art will appreciate that various substitutions, changes, and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the preferred embodiments and the drawings, and the scope of protection claimed by the present invention shall be determined by the scope defined in the claims.

Claims

1. A RISC-V memory overflow vulnerability detection method based on hardware virtualization, comprising the following steps: Reverse engineer the operating system kernel running on RISCV and obtain the process kernel data structure; Simulate the RISC-V CPU based on the hardware simulator and build the basic process list of the operating system and a memory area occupancy record table; Use the sptbr register and the process kernel data structure to obtain the characteristic information of the new process, and filter the characteristic information according to the basic process list to obtain the target process; wherein, the characteristic information of the new process is obtained through the following steps: Monitor the changes of the sptbr register and get the new process when a new address appears; Starting from the physical page pointed to by sptbr, the feature information of the new process is obtained by searching the process kernel data structure through features. A corresponding table header is created in the memory area occupancy record table, and the contents of the memory area occupancy record table are filled with the API detection result of the target process, so as to obtain a memory area list according to the occupancy of the allocated memory blocks; wherein, the API detection result is obtained through the following steps: Get the process information and dynamic running process information of the target process; Intercept all ecall instructions and obtain API information, wherein the API information includes: API call address, function name, input / output parameters and return value; Determine whether the function corresponding to the API call address is a memory allocation / release function: If so, use the user-configured process name, the starting address of the memory area, and the length of the memory area as the API detection result; if not, use the current shadow page table content as the API detection result; Based on the instruction analysis results of the target process, memory access data is obtained; Compare the memory access data with the memory area list to obtain the overflow vulnerability detection results.

2. The method according to claim 1, wherein The operating system includes: Linux operating system or Windows operating system.

3. The method according to claim 1, wherein The types of the hardware simulator include: Qemu hardware simulator.

4. The method according to claim 1, wherein The characteristic information includes: module loading address, length, thread information and memory information.

5. The method according to claim 1, wherein The process information of the target process includes: process structure address, page table physical address, process name, module structure information list and process current module structure pointer.

6. The method according to claim 1, wherein Get the memory access data by following the steps below: 1) Intercept all STORE instructions; 2) Obtain the instruction's opcode, operands, registers, memory addresses, and memory contents; 3) Based on the memory address location operated by the STOR instruction, the memory access data is obtained.

7. A storage medium storing a computer program, wherein: The computer program is configured to execute the method according to any one of claims 1 to 6 when executed.

8. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 6.

Images