Method and device for protecting memory in response to use-after-free vulnerability via opportunistic page-level sweeping

Abstract

A method and device for protecting a memory in response to use-after-free vulnerability, according to one embodiment, may comprise the steps of: releasing a physical page on the basis of a request for deallocation of heap memory transmitted from a user application and maintaining a virtual page in page metadata such that deallocation of the virtual page is delayed; performing simultaneous marking by simultaneously creating a free map in which information on one or more virtual pages maintained in the page metadata is recorded through a marker, and a mark map in which pointers found by scanning the memory are indicated; performing synchronous marking by modifying the mark map generated by the simultaneous marking by rescanning the memory on the basis of a dirty page generated during the simultaneous marking when the user application does not operate; searching for a virtual page requiring deallocation on the basis of the free map through a sweeper; and deallocating the searched virtual page when it is confirmed whether a pointer exists in the searched virtual page on the basis of the mark map.

Description

Method and device for protecting memory against use-after-free vulnerabilities through opportunistic page-level sweeping

[0001] Below, a technique is presented for protecting memory against use-after-free vulnerabilities through opportunistic page-level sweeping.

[0002] A programming language is a means of communication between a computer, which understands only machine language, and humans, who speak natural language. Programming languages ​​can include high-level and low-level languages.

[0003] High-level programming languages ​​have human-friendly characteristics because they use English-like syntax. Furthermore, this human-friendly nature makes them easy to learn, making programming in them fast and efficient. Furthermore, programs using these languages ​​can be portable across platforms with little or no modification. Examples of high-level programming languages ​​include JavaScript, Python, Java, Visual Basic, Perl, Ruby, and C#. However, programs using these languages ​​can abstract away many hardware details and give the programmer less control over computer resources. Furthermore, high-level programming languages ​​require translation into machine code, necessitating an intermediary such as a compiler or interpreter. This translation can consume significant system resources, including memory and processing power, and can be slow. Furthermore, high-level programming languages ​​must store user-initiated commands, which can take up additional memory.

[0004] On the other hand, low-level programming languages ​​have machine-friendly characteristics because they use binary and hexadecimal strings. For example, low-level programming languages ​​can include machine code, assembly language, C, and C++. Programs written in these low-level programming languages ​​can run quickly because they do not require a compiler or interpreter to translate the code. Furthermore, programs written in these languages ​​can be efficient in terms of memory usage because their small code size does not require storing a lot of data, making them suitable for environments with limited storage space. Furthermore, low-level programming languages ​​give programmers complete control over the hardware, allowing them to better utilize the processor and memory. They can also directly manipulate computer registers and storage devices, providing a high degree of control over program behavior.

[0005] The background technology described above is technology that the inventor possessed or acquired in the process of deriving the disclosure of the present application, and cannot necessarily be said to be publicly known technology disclosed to the general public prior to the present application.

[0006] A method and device for protecting memory against a use-after-free vulnerability according to one embodiment may configure a heap allocator that does not immediately reuse freed chunks and performs page-level sweeping and opportunistic mark sweeping.

[0007] A method and device for protecting memory against a use-after-free vulnerability according to one embodiment can perform concurrent marking and synchronous marking in a marking step of a mark sweep operation.

[0008] A method and device for protecting memory against a use-after-free vulnerability according to one embodiment can comprehensively scan the entire memory, including anonymous pages, during marking.

[0009] However, technical challenges are not limited to the technical challenges described above, and other technical challenges may exist.

[0010] A method for protecting memory against a use-after-free vulnerability according to one embodiment may include the steps of: releasing a physical page based on a deallocation request of heap memory transmitted from a user application, and maintaining a virtual page in page metadata so that deallocation of the virtual page is delayed; performing simultaneous marking by simultaneously creating a free map in which information on one or more virtual pages maintained in the page metadata is recorded through a marker and a mark map in which pointers found by scanning memory are indicated; performing synchronous marking by rescanning the memory based on a dirty page generated during the simultaneous marking when the user application is not running, and modifying the mark map created by the simultaneous marking; searching for a virtual page requiring deallocation based on the free map through a sweeper; and, when checking whether a pointer exists in the searched virtual page based on the mark map, dealinglocating the searched virtual page.

[0011] The method may further include a step of initializing the mark map implemented as a bitmap and a step of initializing all dirty bits in the page table prior to performing the simultaneous marking.

[0012] The step of performing the above simultaneous marking may include a step of considering a predetermined byte value as the pointer and marking it in the mark map if the predetermined byte value is greater than or equal to the lowest virtual address and less than the highest virtual address allocated by the operating system based on a dirty page that referenced the page table while creating the free map.

[0013] The step of releasing the allocation of the virtual page may include a step of releasing the allocation of the searched virtual page if there are no bits for the searched virtual page in the mark map.

[0014] The method may further include a step of receiving a heap memory allocation request from the user application before deallocating the virtual page, a step of allocating data based on the received heap memory allocation request to heap memory excluding the heap memory for which the virtual page has been requested to be deallocated through a heap allocator, and a step of delivering a pointer indicating virtual page information for the allocated heap memory to the user application.

[0015] The step of allocating the heap memory may include the step of finding an available area within the heap memory and allocating a memory chunk of a size based on the received heap memory allocation request, and the step of creating a pointer to the allocated memory chunk.

[0016] The above method may further include a step of sweeping pages with empty chunks among the pages in use through the sweeper to a reusable state.

[0017] The above mark map can be created based on metadata generated by linearly scanning the entire memory, including anonymous pages.

[0018] In response to a use-after-free vulnerability according to one embodiment, a device for protecting memory may include a processor for releasing a physical page based on a deallocation request of a heap memory transmitted from a user application, maintaining virtual pages in page metadata to delay deallocation of the virtual pages, performing simultaneous marking by simultaneously creating a free map in which information on one or more virtual pages maintained in the page metadata is recorded through a marker and a mark map in which pointers found by scanning memory are indicated, performing synchronous marking by modifying the mark map created by the simultaneous marking by rescanning the memory based on a dirty page generated during the simultaneous marking when the user application is not operating, searching for a virtual page requiring deallocation based on the free map through a sweeper, and, when confirming whether a pointer exists in the searched virtual page based on the mark map, deallocating the searched virtual page.

[0019] The processor may initialize the mark map implemented as a bitmap and initialize all dirty bits in the page table before performing the concurrent marking.

[0020] The processor, when performing the simultaneous marking, may, at the same time as creating the free map, mark a predetermined byte value as the pointer and display it in the mark map if the predetermined byte value is greater than or equal to the lowest virtual address and less than the highest virtual address allocated by the operating system based on a dirty page that references the page table.

[0021] The processor may, when releasing the allocation of the virtual page, release the allocation of the searched virtual page if there are no bits for the searched virtual page in the mark map.

[0022] The processor may receive a heap memory allocation request from the user application before deallocating the virtual page, allocate data based on the received heap memory allocation request to heap memory excluding the heap memory for which the virtual page has been requested to be deallocated through a heap allocator, and transmit a pointer indicating virtual page information for the allocated heap memory to the user application.

[0023] The processor, when allocating the heap memory, can find an available area within the heap memory, allocate a memory chunk of a size based on the received heap memory allocation request, and create a pointer to the allocated memory chunk.

[0024] The above processor can sweep pages with empty chunks among the pages in use through the sweeper to a reusable state.

[0025] The above mark map can be created based on metadata generated by linearly scanning the entire memory, including anonymous pages.

[0026] A method and device for protecting memory against a use-after-free vulnerability according to one embodiment of the present invention can safely counter use-after-free vulnerabilities regardless of the lifespan of an application, without additional performance degradation, with low overhead, by configuring a heap allocator that does not immediately reuse freed chunks and performing page-level sweeping and opportunistic mark sweeping.

[0027] A method and device for protecting memory against a use-after-free vulnerability according to one embodiment can reduce overhead due to marking by performing simultaneous marking and synchronous marking in a marking step of a mark sweep operation.

[0028] A method and device for protecting memory against a use-after-free vulnerability according to one embodiment can perform a secure mark sweep by comprehensively scanning the entire memory including anonymous pages during marking.

[0029] FIG. 1 illustrates a block diagram of a device that protects memory against a use-after-free vulnerability according to one embodiment.

[0030] FIG. 2 illustrates an exemplary operation mechanism of a device that protects memory against a use-after-free vulnerability according to one embodiment.

[0031] FIG. 3 illustrates a flowchart of a method for protecting memory against a use-after-free vulnerability according to one embodiment.

[0032] FIG. 4 illustrates an example of a method for protecting memory against a use-after-free vulnerability according to one embodiment and execution time and memory usage results of other methods for responding to a use-after-free vulnerability.

[0033] Specific structural or functional descriptions of the embodiments are disclosed for illustrative purposes only and may be modified and implemented in various forms. Therefore, the actual implementation is not limited to the specific embodiments disclosed, and the scope of this specification includes modifications, equivalents, or alternatives within the technical concepts described in the embodiments.

[0034] Although terms such as "first" or "second" may be used to describe various components, these terms should be interpreted solely to distinguish one component from another. For example, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component.

[0035] When it is said that a component is "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but there may also be other components in between.

[0036] Singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, the terms "comprises" or "has" should be understood to indicate the presence of a described feature, number, step, operation, component, part, or combination thereof, but not to exclude the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0037] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art. Terms defined in commonly used dictionaries should be interpreted to have a meaning consistent with their meaning in the context of the relevant technology, and will not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0038] Hereinafter, embodiments will be described in detail with reference to the attached drawings. In the description with reference to the attached drawings, identical components are assigned the same reference numerals regardless of the drawing numbers, and redundant descriptions thereof will be omitted.

[0039] The C language, a foundational language for many other languages, offers ease of programming due to its minimal technical limitations, though it can be difficult to detect program errors. Furthermore, C++, an extension of C, is optimized for creating large-scale applications. Due to these advantages, C / C++ is widely used to implement core programs such as web browsers and operating systems. However, systems programmed in C / C++ are increasingly vulnerable to memory safety issues, and research into solutions to address these issues is also increasing.

[0040] Memory safety issues can include, for example, Use-After-Free (UAF), Buffer Overflow, Out-of-Boundary (OOB), and Format String Bug (FSB). A Use-After-Free can occur when a pointer to an already deallocated heap area is accidentally left in memory and then used by other code. If an attacker can identify such a leftover pointer, the attacker can reallocate the leftover pointer to gain kernel-level access, and based on this, the attacker can obtain or modify information about data, thereby performing incorrect system control such as privilege escalation or information disclosure.

[0041] The first solution to prevent the aforementioned problem is to label all memory devices to determine whether the memory has been allocated or deallocated. However, the first solution can incur high overhead that can impact program performance. A second solution that improves this problem can defend against use-after-free with relatively low overhead by periodically traversing the heap space to check for the existence of pointers pointing to the requested freed heap space, and only allowing reuse of the heap space if there are no pointers pointing to the requested freed heap space. However, the second solution requires a stop-the-world process, which involves stopping the process and reading the memory, and this process is also known to cause significant performance degradation. Another solution to counter use-after-free vulnerabilities is the One-Time Allocation (OTA) technique, which performs delayed deallocation under the assumption that the application's lifespan is short. A third solution, based on a one-time allocation technique, creates a unique virtual shadow page for each object, places each shadow page in the same physical frame, and frees the unique page corresponding to the object upon deallocation. Furthermore, a fourth solution, based on another one-time allocation technique, provides OTA without virtual address reuse, thereby addressing use-after-free vulnerabilities. However, both solutions suffer from the limitation that they only support short-lived applications.

[0042] Accordingly, a device for protecting memory against use-after-free vulnerabilities according to one embodiment utilizes a heap allocator configuration that does not immediately reuse freed chunks and performs page-level sweeping and opportunistic mark sweeping, thereby providing low overhead and no additional performance degradation, and safely responding to use-after-free vulnerabilities regardless of the lifespan of an application.

[0043] FIG. 1 illustrates a block diagram of a device that protects memory against a use-after-free vulnerability according to one embodiment.

[0044] FIG. 2 illustrates an exemplary operation mechanism of a device that protects memory against a use-after-free vulnerability according to one embodiment.

[0045] The device (100) may include a processor (110) and memory (120).

[0046] The processor (110) can free a physical page based on a request for deallocation of heap memory transmitted from a user application (210) and maintain (13) a virtual page in the page metadata (221) so that deallocation of the virtual page is delayed. The user application (210) can request deallocation of the heap memory using a free function (212). In addition, the processor (110) can perform simultaneous marking by simultaneously creating (14, 15) a free map in which information on one or more virtual pages maintained in the page metadata is recorded through a marker (222) and a mark map in which pointers found by scanning the memory are displayed. In addition, the processor (110) can perform synchronous marking by modifying (15) the mark map generated by the simultaneous marking by rescanning the memory based on a dirty page generated during the simultaneous marking when the user application (210) is not operating. The processor (110) can reduce the overhead due to marking by performing concurrent marking and synchronous marking. The processor (110) searches for a virtual page requiring deallocation based on a free map through a sweeper (223), and if it verifies (16) whether a pointer exists in the virtual page searched for requiring deallocation based on the mark map, the searched virtual page can be deallocated (17). Since the processor (110) does not use the heap area until there is no pointer pointing to the heap area for which deallocation has been requested through the heap allocator (230), it can safely not reuse chunks for which deallocation has not been completed. In addition, the runtime area (220) may include page metadata (221), a marker (222), and a sweeper (223).The runtime area (220) is located between the user application (210) and the heap allocator (230) and can be involved in allocating heap memory requested through the Malloc function (211) and releasing heap memory requested through the free function (212).

[0047] The processor (110) can perform a mark sweep by releasing physical pages of physical memory and leaving only virtual pages of virtual memory with metadata in the page metadata (221). For example, the processor (110) can release physical pages during deallocation and newly allocate and maintain only virtual pages in the form of metadata. Through this, the virtual pages left behind during deallocation may have different purposes and forms than the page metadata stored during memory allocation. This may mean that even if a memory leak occurs due to an unsafe deallocation process, a virtual memory address, not a physical memory address, is leaked. Furthermore, the operating system can only return physical memory initialized to 0 (zero) when accessing a virtual address with no physical memory or a released physical address. Consequently, accessing a leaked virtual memory address may return a page initialized to 0 (zero) because it is an access to already released physical memory. Based on this, the memory leak issue can result in a relatively less impactful outcome. Furthermore, since virtual memory addresses can be processed with relatively fewer resources than physical memory addresses, the overhead of processing them can also be reduced.

[0048] The processor (110) can initialize a mark map implemented as a bitmap and initialize all dirty bits in the page table before performing simultaneous marking. For example, the processor (110) can initialize the mark map to a 0 (zero) value, and if it is confirmed that a pointer pointing to a specific chunk exists during the marking process, it can change the value to 1 (one) for the corresponding area. In addition, the processor (110) can initialize the dirty bit in order to utilize the dirty bit in which changes are recorded during the simultaneous marking process in synchronous marking.

[0049] To explain simultaneous marking in more detail, the processor (110) can linearly scan the entire memory including anonymous pages. Thereafter, when performing simultaneous marking, the processor (110) can, at the same time as creating a free map (14), mark the mark map (15) by considering a predetermined byte value as a pointer based on a dirty page that references the page table if the value is greater than or equal to the lowest virtual address and less than the highest virtual address allocated by the operating system. This allows the processor (110) to selectively read only information about the corresponding page by directly referencing the page table without having to read unnecessary files through a marker (222) with kernel privileges. For example, the processor (110) can generate metadata based on pointers discovered by the linear scan and create a mark map based on the generated metadata. At this time, the processor (110) can perform a safe mark sweep by comprehensively scanning the entire memory during marking. In addition, the processor (110) can continuously add information about chunks whose release is delayed to the free map through the marker (222) while creating the mark map. The mark map and the free map can be stored in the page metadata (221). In addition, synchronous marking can rescan the memory through the marker (222), and like concurrent marking, it can find and read the dirty page generated during concurrent marking by referencing the page table. Accordingly, synchronous marking can also modify the mark map generated by concurrent marking by selectively reading only the information about the corresponding page by directly referencing the page table without having to read unnecessary files.

[0050] Additionally, the processor (110) can opportunistically perform marking when the processor of the application (210) is paused. For example, the processor (110) can initiate simultaneous marking during the marking process when the application process has free resources. Thereafter, the processor (110) can check whether the application process is running for synchronous marking, and if so, can pause it and perform synchronous marking. This can mean performing a mark sweep operation for use-after-free defense when the user application is not running, to reduce the overhead caused by scanning memory during the marking phase, which consumes a lot of resources.

[0051] In addition, the processor (110) may receive a heap memory allocation request from the user application (210) before deallocating a virtual page. The user application (210) may request allocation of heap memory using the Malloc function (211). This may mean that allocation cannot be made in the corresponding heap area because the processor (110) delays the allocation deallocation request until there is no pointer pointing to the heap area for which deallocation has been requested. For example, since the deallocation request for a previously allocated chunk (e.g., object A) is delayed, a new allocation (e.g., object B) may have a new address. Accordingly, the processor (110) may allocate data based on the heap memory allocation request received through the heap allocator (230) to the heap memory excluding the heap memory for which deallocation of the virtual page has been requested. This means that the processor (110) does not use the heap area until there is no pointer pointing to the heap area for which allocation has been requested through the heap allocator (230), so that chunks for which allocation has not been safely completed may not be reused. When allocating heap memory, the processor (110) may find an available area in the heap memory, allocate a memory chunk of a size based on the received heap memory allocation request, and generate a pointer to the allocated memory chunk. Thereafter, the processor (110) may transmit (11) a pointer indicating virtual page information for the heap memory allocated from the heap allocator (230) to the user application (210). In addition, the processor (110) may receive (12) information on virtual pages or small memory chunks that can be safely reused from page metadata (221) before allocating heap memory. The processor (110) may allocate memory chunks in the aforementioned manner based on the received information on virtual pages or small memory chunks that can be safely reused.

[0052] In addition, when the processor (110) deallocates a virtual page, if there are no bits for the found virtual page in the mark map, the processor (110) can deallocate the found virtual page. This means that no dangling pointers exist in the memory and registers, so that the corresponding heap chunk can be reused when an allocation request is made from the user application (210). In addition, the processor (110) can quickly perform a mark sweep operation by performing page-level sweeping through the sweeper (223). In addition, the processor (110) can sweep pages with empty chunks among the pages in use through the sweeper (223) to a reusable state. This reuses small chunks by utilizing internal empty spaces so that page-level sweeping is not hindered, thereby reducing internal fragmentation.

[0053] According to various embodiments, the memory (120) may be implemented as a volatile memory device or a nonvolatile memory device. The volatile memory device may be implemented as a dynamic random access memory (DRAM), a static random access memory (SRAM), a thyristor RAM (T-RAM), a zero capacitor RAM (Z-RAM), or a twin transistor RAM (TTRAM). The nonvolatile memory device may be implemented as an Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, Magnetic RAM (MRAM), Spin-Transfer Torque (STT)-MRAM, Conductive Bridging RAM (CBRAM), Ferroelectric RAM (FeRAM), Phase change RAM (PRAM), Resistive RAM (RRAM), Nanotube RRAM, Polymer RAM (PoRAM), Nano Floating Gate Memory (NFGM), holographic memory, Molecular Electronic Memory Device, and / or Insulator Resistance Change Memory.

[0054] According to various embodiments, the processor (110) may execute computer-readable code (e.g., software) stored in the memory (120) and instructions generated by the processor (110). The processor (110) may be a hardware-implemented data processing device having a circuit having a physical structure for executing desired operations. The desired operations may include, for example, code or instructions included in a program. The hardware-implemented data processing device may include, for example, a microprocessor, a central processing unit, a processor core, a multi-core processor, a multiprocessor, an application-specific integrated circuit (ASIC), and a field programmable gate array (FPGA).

[0055] FIG. 3 illustrates a flowchart of a method for protecting memory against a use-after-free vulnerability according to one embodiment.

[0056] In step (310), the processor may free physical pages based on a heap memory deallocation request received from a user application, and may maintain virtual pages in page metadata to delay the deallocation of virtual pages. The processor may initialize a mark map implemented as a bitmap and initialize all dirty bits in the page table before performing concurrent marking.

[0057] In step (320), the processor may perform simultaneous marking, which simultaneously creates a free map in which information on one or more virtual pages maintained in page metadata is recorded through markers, and a mark map in which pointers found by scanning the memory are displayed. While creating the free map, the processor may mark a predetermined byte value as a pointer in the mark map if it is greater than or equal to the lowest virtual address and less than the highest virtual address allocated by the operating system based on a dirty page that references the page table. In another method, the mark map may be created based on metadata generated by linearly scanning the entire memory, including anonymous pages.

[0058] In step (330), the processor may perform synchronous marking to modify the mark map generated by concurrent marking by rescanning the memory based on dirty pages generated during concurrent marking when the user application is not running.

[0059] At step (340), the processor can search for virtual pages that require deallocation based on the free map through a sweeper.

[0060] In step (350), if the processor determines whether a pointer exists in the searched virtual page based on the mark map, the processor may deallocate the searched virtual page. If there are no bits for the searched virtual page in the mark map, the processor may deallocate the searched virtual page.

[0061] In addition, the processor may receive a heap memory allocation request from a user application before deallocating a virtual page, and allocate data based on the heap memory allocation request received through a heap allocator to heap memory excluding the heap memory for which the virtual page allocation has been requested, and may deliver a pointer indicating virtual page information for the allocated heap memory to the user application. The processor may find an available area within the heap memory, allocate a memory block of a size based on the received heap memory allocation request, and create a pointer to the allocated memory block.

[0062] Additionally, the processor can sweep pages with empty chunks among the pages in use into a reusable state through the sweeper.

[0063] FIG. 4 illustrates an example of a method for protecting memory against a use-after-free vulnerability according to one embodiment and execution time and memory usage results of other methods for responding to a use-after-free vulnerability.

[0064] MarkUs is the second scheme mentioned above, FFmalloc is the fourth scheme mentioned above, and HushVac is a method and device for protecting memory against use-after-free vulnerabilities according to one embodiment. (410) represents the normalized execution time for each benchmark, and (420) can represent the normalized memory usage for the same benchmark as (410). In (410), MarkUs shows that it has the longest execution time, which is 11.4% on average, and FFmalloc shows that it has the shortest execution time, which is -2.1% on average. In addition, in (420), MarkUs shows that it has the smallest memory usage, which is 25.1% on average, and FFmalloc shows that it has the largest memory usage, which is 115% on average. Accordingly, while MarkUs and FFmalloc each show extreme performance, Hush Vac, a method and device of one embodiment, shows stable execution time and memory usage with an average execution time of 4.7% and a memory usage of 57.2%.

[0065] The embodiments described above may be implemented using hardware components, software components, and / or a combination of hardware components and software components. For example, the devices, methods, and components described in the embodiments may be implemented using a general-purpose computer or a special-purpose computer, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing instructions and responding to them. The processing device may execute an operating system (OS) and software applications running on the operating system. Furthermore, the processing device may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing device is sometimes described as being used alone; however, those skilled in the art will appreciate that the processing device may include multiple processing elements and / or multiple types of processing elements. For example, the processing device may include multiple processors, or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are also possible.

[0066] Software may include a computer program, code, instructions, or a combination of one or more of these, and may configure a processing device to perform a desired operation or may independently or collectively command the processing device. The software and / or data may be stored on any type of machine, component, physical device, virtual equipment, computer storage medium, or device for interpretation by the processing device or for providing instructions or data to the processing device. The software may also be distributed over networked computer systems and stored or executed in a distributed manner. The software and data may be stored on a computer-readable recording medium.

[0067] The method according to the embodiment may be implemented in the form of program commands that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program commands, data files, data structures, etc., alone or in combination, and the program commands recorded on the medium may be those specially designed and configured for the embodiment or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program commands such as ROMs, RAMs, and flash memories. Examples of program commands include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc.

[0068] The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

[0069] Although the embodiments described above have been described with limited drawings, those skilled in the art will appreciate that various technical modifications and variations can be applied based on the described embodiments. For example, appropriate results can still be achieved even if the described techniques are performed in a different order than described, and / or components of the described systems, structures, devices, circuits, etc. are combined or combined in a different manner than described, or are replaced or substituted with other components or equivalents.

[0070] Therefore, other implementations, other embodiments, and equivalents to the claims also fall within the scope of the claims described below.

Claims

1. A method for protecting memory against a use-after-free vulnerability by a processor, A step of releasing physical pages based on a deallocation request for heap memory transmitted from a user application and maintaining virtual pages in page metadata so that deallocation of virtual pages is delayed; A step of performing simultaneous marking by simultaneously creating a Free Map in which information of one or more virtual pages maintained in the page metadata is recorded through a Marker and a Mark Map in which pointers found by scanning the memory are displayed; When the user application is not running, performing synchronous marking to modify the mark map generated by the simultaneous marking by rescanning the memory based on dirty pages generated during the simultaneous marking; A step of searching for a virtual page that needs to be deallocated based on the free map through a sweeper; and A step of releasing the allocation of the searched virtual page when checking whether there is a pointer in the searched virtual page based on the mark map. How to include.

2. In paragraph 1, A step of initializing the mark map implemented as a bitmap before performing the above simultaneous marking; and Step to clear all dirty bits in the page table How to include more.

3. In paragraph 1, The step of performing the above simultaneous marking is: A step of considering a predetermined byte value as the pointer and displaying it in the mark map, if the predetermined byte value is greater than or equal to the lowest virtual address and less than the highest virtual address allocated by the operating system based on the dirty page that referenced the page table while creating the free map. How to include.

4. In paragraph 1, The step of deallocating the above virtual page is: A step of releasing the allocation of the searched virtual page if there are no bits for the searched virtual page in the mark map. How to include.

5. In paragraph 1, A step of receiving a heap memory allocation request from the user application before deallocating the virtual page; A step of allocating data based on the heap memory allocation request received through the heap allocator to heap memory excluding the heap memory for which allocation of the virtual page has been requested; and A step of passing a pointer representing virtual page information for the allocated heap memory to the user application. How to include more.

6. In paragraph 5, The step of allocating the above heap memory is: A step of finding an available area within the heap memory and allocating a memory chunk of a size based on the received heap memory allocation request; and A step of creating a pointer to the allocated memory chunk How to include.

7. In paragraph 1, A step of sweeping pages with empty chunks among the pages in use through the above sweeper to a reusable state. How to include more.

8. In paragraph 1, The above mark map is, It is created based on metadata generated by linearly scanning the entire memory, including anonymous pages. method.

9. A processor that releases a physical page based on a request for deallocation of heap memory transmitted from a user application, maintains a virtual page in page metadata to delay deallocation of the virtual page, performs simultaneous marking by simultaneously creating a free map in which information of one or more virtual pages maintained in the page metadata is recorded through a marker and a mark map in which pointers found by scanning memory are indicated, and performs synchronous marking by modifying the mark map created by the simultaneous marking by rescanning the memory based on a dirty page generated during the simultaneous marking when the user application is not in operation, searches for a virtual page requiring deallocation based on the free map through a sweeper, and, when checking whether a pointer exists in the searched virtual page based on the mark map, deals with the allocation of the searched virtual page. A device comprising:

10. In paragraph 9, The above processor, Initializing the mark map implemented as a bitmap and initializing all dirty bits in the page table before performing the above simultaneous marking. device.

11. In paragraph 9, The above processor, In performing the above simultaneous marking, if a predetermined byte value is greater than or equal to the lowest virtual address and less than the highest virtual address allocated by the operating system based on a dirty page that referenced the page table while creating the free map, the predetermined byte value is regarded as the pointer and displayed in the mark map. device.

12. In paragraph 9, The above processor, When releasing the allocation of the virtual page, if there is no bit for the searched virtual page in the mark map, the allocation of the searched virtual page is released. device.

13. In paragraph 9, The above processor, Before deallocating the virtual page, a heap memory allocation request is received from the user application, and data based on the received heap memory allocation request is allocated to heap memory excluding the heap memory for which the virtual page has been requested to be deallocated through a heap allocator, and a pointer indicating virtual page information for the allocated heap memory is delivered to the user application. device.

14. In paragraph 13, The above processor, When allocating the heap memory, an available area within the heap memory is found, a memory chunk of a size based on the received heap memory allocation request is allocated, and a pointer to the allocated memory chunk is created. device.

15. In paragraph 9, The above processor, Sweeping pages with empty chunks among the pages in use through the above sweeper to a reusable state. device.

16. In paragraph 9, The above mark map is, It is created based on metadata generated by linearly scanning the entire memory, including anonymous pages. device.

Images