Metadata-based memory leak detection method, system, device and storage medium
By segmenting the program's virtual address into Unusable, ID, and offset entries, and combining metadata and timestamps, the shortcomings of existing memory vulnerability detection technologies are addressed, enabling efficient cross-platform, multi-threaded memory vulnerability detection and protection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING YUAN NIAO TECH CO LTD
- Filing Date
- 2022-09-28
- Publication Date
- 2026-06-23
Smart Images
Figure CN115600210B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the fields of network security, software security, software testing technology, and software reliability, and particularly relates to a method, system, electronic device, and computer-readable storage medium for detecting memory vulnerabilities based on metadata. Background Technology
[0002] Traditionally, software quality is considered the lifeline of a software product. However, software defects, to varying degrees, can cause unexpected behaviors during runtime. These defects can range from impairing the program's intended functionality to causing it to crash and malfunction. In more serious cases, these defects can be exploited by malicious programs, leading to malicious intrusion into the host machine and resulting in serious consequences such as data leaks and loss of control.
[0003] Among various software defects, memory-related defects are the most widespread and fatal. On the one hand, memory defects can cause programs to corrupt existing data during execution, resulting in unexpected behavior and severely damaging software quality. On the other hand, memory defects are very easy for attackers to exploit. The most classic attack pattern against software is to use memory vulnerabilities to achieve buffer overflows, thereby gaining root privileges and executing malicious code. The defense against memory security has been ongoing for over 30 years, and various memory protection methods have been widely used: write protection, canary protection, address randomization, data execution protection, etc., but these still cannot completely prevent memory security attacks. Even today, memory vulnerabilities still account for a large proportion of software vulnerabilities. At the 2019 Israel Security Conference, Microsoft security engineers stated that 70% of all vulnerabilities patched by Microsoft products in the past 12 years were memory security issues. The detection and protection against memory vulnerabilities are crucial for improving software quality and security.
[0004] Memory vulnerabilities can be broadly categorized into two types: spatial and temporal. These include, but are not limited to, the following types:
[0005] UMA (Uninitialized Memory Access): Accessing uninitialized memory.
[0006] (Memory)Overflow: Memory access exceeds the boundary of the memory region.
[0007] NPD (Null Pointer Dereference): Dereferences a null pointer.
[0008] UAF (Use After Free): When a memory region is freed, the pointer that is still accessible to that memory region is called a dangling pointer. UAF occurs when a dangling pointer is dereferenced.
[0009] DF (Double Free): Frees up memory that has already been freed.
[0010] Traditional software vulnerability detection techniques are mainly divided into two categories: static detection techniques and dynamic detection techniques. Static detection techniques analyze and detect vulnerabilities in the program's source code, while dynamic detection techniques utilize runtime information. Since memory vulnerabilities often involve pointers and are highly complex, static analysis is difficult; therefore, current memory vulnerability detection techniques primarily rely on dynamic detection techniques. Typical methods include CCured, SoftBound+CETS, Valgrind, Intel MPX, and AddressSanitizer. However, existing methods all have certain limitations. CCured and Intel MPX cannot detect time-related memory vulnerabilities; Valgrind has extremely high performance overhead and cannot provide real-time protection; AddressSanitizer also has significant overhead, and its detection mechanism has flaws that result in a considerable number of false negatives; SoftBound+CETS performs well in terms of performance and vulnerability detection effectiveness, but it cannot be scaled to multi-threaded programs.
[0011] In view of the above, this application is hereby submitted. Summary of the Invention
[0012] This application provides a metadata-based memory vulnerability detection method, system, electronic device, and computer-readable storage medium, which can comprehensively, cross-platformly, and with high scalability detect memory vulnerabilities.
[0013] In a first aspect, embodiments of this application provide a memory vulnerability detection method based on metadata, including:
[0014] The program's virtual address is divided into Unusable, ID, and offset entries arranged from high to low bits.
[0015] During the execution of the target program, metadata is maintained, and for instructions involving memory access operations, the corresponding metadata is loaded according to the ID value contained in the target address;
[0016] Memory vulnerabilities are detected based on the offset value in the metadata and the target address, as well as the timestamp corresponding to the ID.
[0017] Furthermore, after detecting memory vulnerabilities, the method also includes:
[0018] If the memory vulnerability detection result is no memory vulnerability, the target program will be executed normally;
[0019] If the memory vulnerability detection result indicates the presence of a memory vulnerability, the exception handler will be triggered.
[0020] Furthermore, the number of bits occupied by the ID field can be adjusted;
[0021] ID entries are divided into different categories based on the number of bits they occupy.
[0022] There can be one or more categories existing simultaneously.
[0023] Furthermore, the ID field consists of two parts: the ID Kind field and the ID Number field.
[0024] The ID Kind field is used to mark the type of ID field, and the number of bits occupied by the ID Kind field at runtime can be dynamically adjusted.
[0025] The number of bits occupied by the ID Number and Offset fields varies depending on the ID Kind field; the ID Number field has [0, N] bits, where N is a user-defined positive integer.
[0026] Furthermore, the metadata includes the boundary values of the memory region corresponding to the ID, initialization information, and memory identification data; among which, the memory identification data includes at least the timestamp corresponding to the ID.
[0027] Furthermore, the categories of detectable memory vulnerabilities include at least: UMA, Overflow, NPD, UAF, and DF.
[0028] Furthermore, based on the offset value in the metadata and the timestamp corresponding to the ID in the target address, memory vulnerability detection is performed, including:
[0029] When the memory vulnerability is a UMA, check whether the target address of the memory access operation has been initialized; if the target address has not been initialized, a UMA exception is triggered.
[0030] When the memory vulnerability is Overflow, the offset value contained in the target address of the memory access operation is compared with the boundary value stored in the metadata; if the target address exceeds the boundary, an out of bound exception is triggered.
[0031] When the memory vulnerability is NPD, convert the NPD memory vulnerability detection to Overflow memory vulnerability detection;
[0032] When the memory vulnerability is a User-Avoided Memory (UAF) vulnerability, if the memory region is released but not reallocated, the memory vulnerability detection of UAF is converted to memory vulnerability detection of Overflow; if the memory region is released and reallocated, a timestamp corresponding to each ID is introduced, and the validity of each timestamp is checked to perform memory vulnerability detection.
[0033] When the memory vulnerability is DF, the memory vulnerability detection of DF is converted to memory vulnerability detection of Overflow.
[0034] Secondly, embodiments of this application provide a metadata-based memory vulnerability detection system, including:
[0035] The memory management module is used to divide the program's virtual address into Unusable, ID, and offset entries arranged sequentially from high to low bits.
[0036] The metadata management module is used to maintain metadata during the execution of the target program and load the corresponding metadata based on the ID value contained in the target address for instructions involving memory access operations.
[0037] The memory vulnerability detection module is used to detect memory vulnerabilities based on the offset value in the metadata and the target address and the timestamp corresponding to the ID.
[0038] Furthermore, the system also includes:
[0039] The normal processing module is used to execute the target program normally if the memory vulnerability detection result is no memory vulnerability after the memory vulnerability detection is performed.
[0040] The exception handling module is used to trigger the exception handling program if the memory vulnerability detection result indicates that a memory vulnerability exists after the memory vulnerability detection is performed.
[0041] Furthermore, the number of bits occupied by the ID field can be adjusted;
[0042] ID entries are divided into different categories based on the number of bits they occupy.
[0043] There can be one or more categories existing simultaneously.
[0044] Furthermore, the ID field consists of two parts: the ID Kind field and the ID Number field.
[0045] The ID Kind field is used to mark the type of ID field, and the number of bits occupied by the ID Kind field at runtime can be dynamically adjusted.
[0046] The number of bits occupied by the ID Number and Offset fields varies depending on the ID Kind field; the ID Number field has [0, N] bits, where N is a user-defined positive integer.
[0047] Furthermore, the metadata includes the boundary values of the memory region corresponding to the ID, initialization information, and memory identification data; among which, the memory identification data includes at least the timestamp corresponding to the ID.
[0048] Furthermore, the categories of detectable memory vulnerabilities include at least: UMA, Overflow, NPD, UAF, and DF.
[0049] Furthermore, the memory vulnerability detection module is used for:
[0050] When the memory vulnerability is a UMA, check whether the target address of the memory access operation has been initialized; if the target address has not been initialized, a UMA exception is triggered.
[0051] When the memory vulnerability is Overflow, the offset value contained in the target address of the memory access operation is compared with the boundary value stored in the metadata; if the target address exceeds the boundary, an out of bound exception is triggered.
[0052] When the memory vulnerability is NPD, convert the NPD memory vulnerability detection to Overflow memory vulnerability detection;
[0053] When the memory vulnerability is a User-Avoided Memory (UAF) vulnerability, if the memory region is released but not reallocated, the memory vulnerability detection of UAF is converted to memory vulnerability detection of Overflow; if the memory region is released and reallocated, a timestamp corresponding to each ID is introduced, and the validity of each timestamp is checked to perform memory vulnerability detection.
[0054] When the memory vulnerability is DF, the memory vulnerability detection of DF is converted to memory vulnerability detection of Overflow.
[0055] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;
[0056] When the processor executes computer program instructions, it implements a metadata-based memory vulnerability detection method as described in the first aspect.
[0057] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the metadata-based memory vulnerability detection method as described in the first aspect.
[0058] The metadata-based memory vulnerability detection method, system, electronic device, and computer-readable storage medium of this application embodiment can comprehensively, cross-platformly, and with high scalability detect memory vulnerabilities.
[0059] This metadata-based memory vulnerability detection method first divides the program's virtual address into Unusable, ID, and offset entries arranged from high to low bits. Then, during the target program's execution, it maintains the metadata and loads the corresponding metadata based on the ID value contained in the target address for instructions involving memory access operations. Finally, it detects memory vulnerabilities based on the metadata, the offset value in the target address, and the timestamp corresponding to the ID.
[0060] Since the ID is built into the address, given a memory address, this method can directly use the ID to perform calculations and obtain the storage location of the metadata without requiring additional memory access operations. Furthermore, the ID is passed in a bound manner with pointer operations, so any modification to the pointer will be reflected in the memory corresponding to its ID, avoiding concurrency issues caused by the disconnect between metadata index passing and pointer operations. Therefore, this method's design ensures applicability to multi-threaded programs.
[0061] Compared with existing memory vulnerability detection technologies, this method has better effectiveness in memory vulnerability detection and lower performance overhead. It can provide real-time memory protection for software and can be extended to hardware implementation to further reduce overhead. At the same time, this method is applicable to multi-threaded programs and supports multiple architectures, making it far more practical than other similar methods.
[0062] Therefore, this method performs well in terms of comprehensiveness, effectiveness, performance overhead, and multi-threading support in memory vulnerability detection, and can perform memory vulnerability detection comprehensively, cross-platform, and with high scalability. Attached Figure Description
[0063] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0064] Figure 1 This is a flowchart illustrating a metadata-based memory vulnerability detection method provided in one embodiment of this application;
[0065] Figure 2 This is a schematic diagram of program virtual address segmentation provided in one embodiment of this application;
[0066] Figure 3 This is a schematic diagram of a UAF vulnerability provided in one embodiment of this application;
[0067] Figure 4This is a schematic diagram of the structure of a metadata-based memory vulnerability detection system provided in one embodiment of this application;
[0068] Figure 5 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation
[0069] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.
[0070] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.
[0071] To address the problems of existing technologies, embodiments of this application provide a method, system, device, and computer-readable storage medium for memory vulnerability detection based on metadata. The metadata-based memory vulnerability detection method provided in this application will be described first.
[0072] Figure 1 This illustration shows a flowchart of a metadata-based memory vulnerability detection method according to an embodiment of this application. This method can be implemented at the software level or at the hardware level (including a hardware simulator), or a combination of both. The following description primarily focuses on the software level, such as... Figure 1 As shown, this metadata-based memory vulnerability detection method includes:
[0073] S101. Divide the program's virtual address into Unusable, ID, and offset entries arranged sequentially from high to low bits;
[0074] This application reorganizes memory in principle. Without changing the underlying memory, it detects whether there are defects or vulnerabilities in the program's memory access behavior by controlling the mapping relationship between CPU address (i.e., virtual address) and physical address during memory access.
[0075] To achieve the above objectives, this application will use an x86 64-bit CPU as an example for explanation. It is assumed that the x86 64-bit CPU uses a page table-based addressing method, and that a four-level page table is used in the translation from CPU address to physical address. Each level uses 9 bits to look up the page table; that is, the lowest 12 bits are used for addressing within the page (each page size is 4KB, corresponding to a 12-bit addressing capability), and the remaining four 9-bit bits (36 bits in total) correspond to the addressing of the first to fourth level pages respectively. In the 64-bit address, apart from these 48 bits (12 bits + 36 bits), the remaining higher bits are assumed not to participate in the addressing process.
[0076] This application records corresponding metadata information (including boundary information and timestamp information) for each dynamically allocated memory region. This is done to map addresses to metadata, such as... Figure 2 As shown, this application segments the program's virtual address, arranging the Unusable item, ID item, and offset item (i.e., from high to low bits) in that order. Figure 2 The ID and Offset entries are combined and their corresponding data is set in the page table. The Unusable entry can have any number of significant bits, including zero bits. To accommodate existing memory addressing processes such as x86, this application combines the ID and Offset entries and sets the corresponding data in the relevant page table.
[0077] The ID field is obtained by combining several digits and is used for indexing metadata. The number of digits occupied by the ID field is adjustable; based on the number of digits occupied by the ID field, the ID field is divided into different categories; there can be one or more categories at the same time, meaning that multiple categories of ID fields can exist simultaneously.
[0078] The ID field consists of two parts: the ID Kind field and the ID Number field.
[0079] The ID Kind field is used to mark the type of ID field, and the number of bits occupied by the ID Kind field at runtime can be dynamically adjusted.
[0080] The number of bits occupied by the ID Number and Offset fields varies depending on the ID Kind field; the ID Number field has [0, N] bits, where N is a user-defined positive integer. When the ID Number field has 0 bits, it means that the field has no bits.
[0081] Corresponding to the ID types, dynamically allocated memory regions are divided into different categories based on their size, with each category corresponding to a specific ID. During dynamic memory allocation, the ID entry and offset value are combined to form the virtual address of the memory region, and the ID is used as an index for storing and retrieving metadata. The division of memory region categories is highly scalable; in this implementation, memory regions are divided into three categories, corresponding to three types of IDs.
[0082] S102. During the execution of the target program, maintain metadata and load the corresponding metadata based on the ID value contained in the target address for instructions involving memory access operations.
[0083] In one embodiment, the metadata includes the boundary values of the memory region corresponding to the ID, initialization information, and memory identification data; wherein the memory identification data includes at least the timestamp corresponding to the ID. This module updates the above metadata during memory allocation and deallocation.
[0084] Specifically, vulnerability detection code can be used to load corresponding metadata based on the ID value contained in the target address.
[0085] When implemented at the software level, the vulnerability detection code is built into the target program or the virtual environment in which the target program runs, providing real-time memory protection when the target program is executed.
[0086] When implemented at the hardware level, under the configuration of the memory management module, information such as the ID in the address is obtained through hardware, and the hardware automatically determines whether the current memory access instruction will cause a vulnerability or error during or before the instruction is executed.
[0087] S103. Detect memory vulnerabilities based on the offset value in the metadata and the target address and the timestamp corresponding to the ID.
[0088] In one embodiment, the detectable memory vulnerability categories include at least: UMA, Overflow, NPD, UAF, and DF. Therefore, this application can detect a variety of memory vulnerabilities.
[0089] In one embodiment, after detecting memory vulnerabilities, the method further includes:
[0090] If the memory vulnerability detection result is no memory vulnerability, the target program will be executed normally;
[0091] If the memory vulnerability detection result indicates the presence of a memory vulnerability, the exception handler will be triggered.
[0092] In one embodiment, memory vulnerability detection is performed based on the timestamp corresponding to the offset value in the target address and the ID in the metadata, including:
[0093] When the memory vulnerability is a UMA, check whether the target address of the memory access operation has been initialized; if the target address has not been initialized, a UMA exception is triggered.
[0094] Specifically, because uninitialized memory may contain malicious code that could be used as pointers, instructions, etc., this application addresses vulnerabilities like UMA by marking the corresponding memory during each memory allocation and indexing it by ID. If the memory has not been initialized during subsequent accesses (i.e., no write operation has occurred before the read operation), the access is considered an uninitialized memory access.
[0095] When the memory vulnerability is Overflow, the offset value contained in the target address of the memory access operation is compared with the boundary value stored in the metadata; if the target address exceeds the boundary, an out of bound exception is triggered.
[0096] Specifically, since memory overflow is one of the main sources of software vulnerabilities, accessing memory regions beyond their boundaries can lead to anything from program crashes and data overwriting to the execution of malicious code and loss of control. To address this Overflow vulnerability, this application retrieves the boundary value of the target memory region based on the ID contained in the target address each time memory is accessed, and checks whether the access is out of bounds. Once an out-of-bounds error is triggered, an exception handler is executed.
[0097] When the memory vulnerability is NPD, the memory vulnerability detection of NPD is converted to memory vulnerability detection of Overflow. The boundary value in the metadata loaded based on the NULL pointer makes the boundary check of any address trigger an out ofbound exception.
[0098] Specifically, dereferencing a null pointer dereference program that dereferences a pointer variable with a value of NULL will cause the program to crash abnormally. Traditional methods for detecting NPD (Non-Descriptive Disturbance) involve adding a conditional check to determine if the pointer is null before dereferencing it. This application, however, transforms the NPD check into an Overflow check, effectively detecting this vulnerability using boundary checks.
[0099] When the memory vulnerability is a User-Avoided Memory (UAF) vulnerability, if the memory region is not reallocated after being freed, the memory vulnerability detection of UAF will be converted to memory vulnerability detection of Overflow.
[0100] UAF (Unbounded Default Error) detection employs different methods for different scenarios. Specifically, in the first scenario, after freeing a pointer, it is directly dereferenced again. For this situation, this application transforms the detection of this vulnerability into an Overflow check. This application ensures that after each memory region is freed, the boundary value corresponding to the relevant ID is set to null, and transforms UAF detection into a boundary check. This ensures that when a dangling pointer is dereferenced, an out-of-bounds exception is triggered through the boundary check, thereby executing the exception handler.
[0101] When the memory vulnerability is a UAF (Use-Away From Memory) vulnerability, in the case of memory area being released and reallocated, a timestamp corresponding to each ID is introduced, and the validity of each timestamp is checked to detect the memory vulnerability.
[0102] Specifically, in the second case, such as Figure 3 As shown, the original pointer p points to a structure. After the structure is released, the pointer p is not set to NULL. At this time, the program allocates a new memory area, and the address of the newly allocated area just intersects with the address of the pointer p. Based on this, when the program dereferences the pointer p again, no exception will be triggered, but the memory area pointed to by the pointer p has been logically changed, which will cause the program to have logical behavior errors. An attacker can use the pointer p to carry out an attack.
[0103] Since this application divides the address into parts such as ID and offset, the above situation will only occur if both ID and offset collide. In order to detect this vulnerability, this application introduces a corresponding timestamp for each ID. By performing a validity check on the timestamp, this vulnerability can be successfully detected.
[0104] When the memory vulnerability is DF, the memory vulnerability detection of DF is converted to memory vulnerability detection of Overflow.
[0105] Specifically, Double Free refers to performing multiple free operations on the same memory region. When freeing a heap block, the `free` function uses an implicit linked list to determine if adjacent heap blocks are free. If a block is free, it is merged, and the free block is removed from the Unsorted bin using the Unlink mechanism. If a user-constructed fake heap block is unlinked, it can easily cause a fixed-address write to be converted into an arbitrary-address read / write, thereby controlling program execution.
[0106] Essentially, DF is a special case of the first type of UAF. This application adopts the same detection method as the first type of UAF, transforming the detection of DF into the detection of Overflow.
[0107] In summary, the objective of this application is to provide a comprehensive method for real-time detection and protection against memory vulnerabilities. This method can simultaneously detect memory vulnerabilities such as UMA, Overflow, NPD, UAF, and DF, avoiding false positives and false negatives while minimizing performance overhead. Furthermore, this method provides support for multi-threaded programs and is applicable to various architectures, including x86, ARM, and RISC-V. This method can be implemented at either the software or hardware level. Moreover, it provides real-time protection for target programs, performs vulnerability and defect detection, and can be used to enhance other analysis techniques, such as taint analysis and symbolic execution.
[0108] Since the ID is built into the address, given a memory address, this method can directly use the ID to perform calculations and obtain the storage location of the metadata without requiring additional memory access operations. Furthermore, the ID is passed in a bound manner with pointer operations, so any modification to the pointer will be reflected in the memory corresponding to its ID, avoiding concurrency issues caused by the disconnect between metadata index passing and pointer operations. Therefore, this method's design ensures applicability to multi-threaded programs.
[0109] Compared with existing memory vulnerability detection technologies, this method has better effectiveness in memory vulnerability detection and lower performance overhead. It can provide real-time memory protection for software and can be extended to hardware implementation to further reduce overhead. At the same time, this method is applicable to multi-threaded programs and supports multiple architectures, making it far more practical than other similar methods.
[0110] Therefore, this method performs well in terms of comprehensiveness, effectiveness, performance overhead, and multi-threading support in memory vulnerability detection, and can perform memory vulnerability detection comprehensively, cross-platform, and with high scalability.
[0111] Figure 4 A schematic diagram of the structure of a metadata-based memory vulnerability detection system provided in an embodiment of this application is shown. Figure 4 As shown, this metadata-based memory vulnerability detection system includes:
[0112] The memory management module 401 is used to divide the program's virtual address into Unusable, ID, and offset entries arranged sequentially from high to low bits; this memory management module 401 can adjust the address space and is responsible for the management of memory addresses and metadata;
[0113] Metadata management module 402 is used to maintain metadata during the execution of the target program and load the corresponding metadata based on the ID value contained in the target address for instructions involving memory access operations.
[0114] The memory vulnerability detection module 403 is used to detect memory vulnerabilities based on the offset value in the metadata and the timestamp corresponding to the ID in the target address. This memory vulnerability detection module 403 can provide real-time vulnerability detection and protection functions during target program runtime.
[0115] In one embodiment, the system further includes:
[0116] The normal processing module is used to execute the target program normally if the memory vulnerability detection result is no memory vulnerability after the memory vulnerability detection is performed.
[0117] The exception handling module is used to trigger an exception handler if a memory vulnerability is detected after a memory vulnerability check. This exception handling module can be customized to determine how to handle each type of memory vulnerability.
[0118] In one embodiment, the number of bits occupied by the ID item can be adjusted;
[0119] ID entries are divided into different categories based on the number of bits they occupy.
[0120] There can be one or more categories existing simultaneously.
[0121] In one embodiment, the ID field comprises an ID Kind field and an ID Number field;
[0122] The ID Kind field is used to mark the type of ID field, and the number of bits occupied by the ID Kind field at runtime can be dynamically adjusted.
[0123] The number of bits occupied by the ID Number and Offset fields varies depending on the ID Kind field; the ID Number field has [0, N] bits, where N is a user-defined positive integer.
[0124] In one embodiment, the metadata includes the boundary value of the memory region corresponding to the ID, initialization information, and memory identification data; wherein the memory identification data includes at least the timestamp corresponding to the ID.
[0125] In one embodiment, the categories of detectable memory vulnerabilities include at least: UMA, Overflow, NPD, UAF, and DF.
[0126] In one embodiment, the memory vulnerability detection module 403 is used for:
[0127] When the memory vulnerability is a UMA, check whether the target address of the memory access operation has been initialized; if the target address has not been initialized, a UMA exception is triggered.
[0128] When the memory vulnerability is Overflow, the offset value contained in the target address of the memory access operation is compared with the boundary value stored in the metadata; if the target address exceeds the boundary, an out of bound exception is triggered.
[0129] When the memory vulnerability is NPD, convert the NPD memory vulnerability detection to Overflow memory vulnerability detection;
[0130] When the memory vulnerability is a User-Avoided Memory (UAF) vulnerability, if the memory region is released but not reallocated, the memory vulnerability detection of UAF is converted to memory vulnerability detection of Overflow; if the memory region is released and reallocated, a timestamp corresponding to each ID is introduced, and the validity of each timestamp is checked to perform memory vulnerability detection.
[0131] When the memory vulnerability is DF, the memory vulnerability detection of DF is converted to memory vulnerability detection of Overflow.
[0132] In one embodiment, under the above memory address encoding, the mapping from virtual address to physical address and the mapping from ID to corresponding metadata can both be implemented by modifying the page table mapping in the Memory Management Unit (MMU).
[0133] Figure 4 Each module in the system shown has an implementation Figure 1 The functions of each step in the process and their corresponding technical effects are described briefly and will not be elaborated here.
[0134] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown.
[0135] The electronic device may include a processor 501 and a memory 502 storing computer program instructions.
[0136] Specifically, the processor 501 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.
[0137] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to an electronic device. In a particular embodiment, memory 502 may be a non-volatile solid-state memory.
[0138] In one embodiment, memory 502 may be read-only memory (ROM). In one embodiment, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.
[0139] The processor 501 reads and executes computer program instructions stored in the memory 502 to implement any of the metadata-based memory vulnerability detection methods in the above embodiments.
[0140] In one example, the electronic device may also include a communication interface 503 and a bus 510. Wherein, as... Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.
[0141] The communication interface 503 is mainly used to realize communication between various modules, units and / or devices in the embodiments of this application.
[0142] Bus 510 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.
[0143] Furthermore, in conjunction with the metadata-based memory vulnerability detection methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the metadata-based memory vulnerability detection methods in the above embodiments.
[0144] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.
[0145] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.
[0146] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.
[0147] The foregoing flowcharts and / or block diagrams of methods, systems, and computer program products according to embodiments of this application have described various aspects of the present application. It should be understood that each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, or other programmable data processing processor to produce a machine such that these instructions, executable via the computer or other programmable data processing processor, enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.
[0148] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.
Claims
1. A memory vulnerability detection method based on metadata, characterized in that, include: The program's virtual address is divided into Unusable, ID, and offset entries arranged from high to low bits. During the execution of the target program, metadata is maintained, and for instructions involving memory access operations, the corresponding metadata is loaded according to the ID value contained in the target address; Memory vulnerabilities are detected based on the metadata, the offset value in the target address, and the timestamp corresponding to the ID. The metadata includes the boundary values of the memory region corresponding to the ID, initialization information, and memory identification data; wherein, the memory identification data includes at least the timestamp corresponding to the ID; The detection of memory vulnerabilities based on the metadata, the offset value in the target address, and the timestamp corresponding to the ID includes: When the memory vulnerability is a UMA, it is checked whether the target address of the memory access operation has been initialized; if the target address has not been initialized, a UMA exception is triggered. When the memory vulnerability is Overflow, the offset value contained in the target address of the memory access operation is compared with the boundary value stored in the metadata; if the target address exceeds the boundary, an out of bound exception is triggered. When the memory vulnerability is NPD, the memory vulnerability detection of NPD is converted to the memory vulnerability detection of Overflow; When the memory vulnerability is a User-Agent Free (UAF), if the memory region is released but not reallocated, the memory vulnerability detection of the UAF is converted to the memory vulnerability detection of the Overflow; if the memory region is released and reallocated, a timestamp corresponding to each ID is introduced, and the validity of each timestamp is checked to perform memory vulnerability detection. When the memory vulnerability is a DF (Device Defender), the memory vulnerability detection of the DF is converted to the memory vulnerability detection of the Overflow.
2. The metadata-based memory vulnerability detection method according to claim 1, characterized in that, After performing memory vulnerability detection, the method further includes: If the memory vulnerability detection result is no memory vulnerability, then the target program will be executed normally; If the memory vulnerability detection result indicates the presence of a memory vulnerability, the exception handler will be triggered.
3. The metadata-based memory vulnerability detection method according to claim 1, characterized in that, The number of bits occupied by the ID item is adjustable; The ID entries are divided into different categories based on the number of bits they occupy. There can be one or more categories existing simultaneously.
4. The metadata-based memory vulnerability detection method according to claim 3, characterized in that, The ID field comprises: an ID Kind field and an ID Number field; The ID Kind item is used to mark the type of the ID item, and the number of bits occupied by the ID Kind item at runtime can be dynamically adjusted; The number of bits occupied by the ID Number item and the offset item varies depending on the ID Kind item; the number of bits in the IDNumber item is [0, N], where N is a user-defined positive integer.
5. The metadata-based memory vulnerability detection method according to claim 1, characterized in that, The categories of detectable memory vulnerabilities include at least: UMA, Overflow, NPD, UAF, and DF.
6. A memory vulnerability detection system based on metadata, characterized in that, include: The memory management module is used to divide the program's virtual address into Unusable, ID, and offset entries arranged sequentially from high to low bits. The metadata management module is used to maintain metadata during the execution of the target program and load the corresponding metadata based on the ID value contained in the target address for instructions involving memory access operations. The memory vulnerability detection module is used to detect memory vulnerabilities based on the timestamp corresponding to the offset value and ID in the target address and the metadata. The metadata includes the boundary values of the memory region corresponding to the ID, initialization information, and memory identification data; wherein, the memory identification data includes at least the timestamp corresponding to the ID; The memory vulnerability detection module is used for: When the memory vulnerability is a UMA, it is checked whether the target address of the memory access operation has been initialized; if the target address has not been initialized, a UMA exception is triggered. When the memory vulnerability is Overflow, the offset value contained in the target address of the memory access operation is compared with the boundary value stored in the metadata; if the target address exceeds the boundary, an out of bound exception is triggered. When the memory vulnerability is NPD, the memory vulnerability detection of NPD is converted to the memory vulnerability detection of Overflow; When the memory vulnerability is a User-Agent Free (UAF), if the memory region is released but not reallocated, the memory vulnerability detection of the UAF is converted to the memory vulnerability detection of the Overflow; if the memory region is released and reallocated, a timestamp corresponding to each ID is introduced, and the validity of each timestamp is checked to perform memory vulnerability detection. When the memory vulnerability is a DF (Device Defender), the memory vulnerability detection of the DF is converted to the memory vulnerability detection of the Overflow.
7. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the metadata-based memory vulnerability detection method as described in any one of claims 1-5.
8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the metadata-based memory vulnerability detection method as described in any one of claims 1-5.