Method, system and computer program for buffer overflow trapping (Buffer Overflow Trapping)

A translation table with strategically placed gaps redirects buffer overflows to overflow memory for analysis, preventing unauthorized access and enhancing security by collecting data for malicious program identification.

JP7790824B2Active Publication Date: 2025-12-23INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2021167124
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2020-10-13
Filing Date
2021-10-12
Publication Date
2025-12-23
Estimated Expiration
2041-10-12

AI Technical Summary

Technical Problem

Existing memory management systems fail to prevent buffer overflows, allowing programs to access unallocated memory, which can cause errors, crashes, and potential malicious attacks by notifying attackers of invalid memory addresses.

Method used

Implement a translation table with strategically placed gaps to redirect buffer overflows to overflow memory, where data is written and analyzed for potential malicious activity, while maintaining program execution transparency.

Benefits of technology

Prevents unauthorized memory access, reduces system errors, and collects data for analysis to identify and prevent future malicious programs, enhancing security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007790824000001
    Figure 0007790824000001
  • Figure 0007790824000002
    Figure 0007790824000002
  • Figure 0007790824000003
    Figure 0007790824000003
Patent Text Reader

Abstract

To provide a method for buffer overflow trapping, system and computer program product.SOLUTION: In an operating system which executes a process of buffer overflow trapping on a processor, a method includes receiving a write request from a program to write data to a memory. The write request includes a virtual memory address and the data. It is determined that the virtual memory address is not assigned to a physical memory address. Based on the determining, the unassigned virtual memory address is assigned to a physical memory address in an overflow memory. The data is written to the physical memory address in the overflow memory and an indication that the write data was successfully written is returned to the program. Future requests by the program to access the virtual memory address are directed to the physical memory address in the overflow memory.SELECTED DRAWING: Figure 3
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates generally to buffer overflow trapping, and more particularly to an unsupported memory honeypot for buffer overflow trapping. [Background technology]

[0002] Memory management is the process of controlling and regulating a computer's memory, including allocating portions of memory to various running programs. Memory management functions can exist in computer hardware, the operating system (OS), programs, and applications. A buffer overflow occurs when a program running on a computer begins accessing (reading or writing) a portion of memory that is not allocated to the program. The portion of memory not allocated to the program may be allocated to another program running on the computer. A buffer overflow can be caused by human error, such as a programming error. A buffer overflow can also be intentionally executed to execute malicious code. Summary of the Invention [Problem to be solved by the invention]

[0003] A method, system and computer program product for buffer overflow trapping is provided. [Means for solving the problem]

[0004] Embodiments of the present invention relate to buffer overflow trapping. A non-limiting example of a computer-implemented method includes, in an operating system executing on a processor, receiving a write request from a program that writes data to memory. The write request includes a virtual memory address and data. The method determines that the virtual memory address is not assigned to a physical memory address. Based on the determination, the virtual memory address is assigned to a physical memory address in overflow memory. The data is written to the physical memory address in overflow memory, and an indication is returned to the program indicating that the write data was successfully written. Subsequent access requests by the program to the virtual memory address are directed to the physical memory address in overflow memory. Other embodiments of the present invention implement features of the above methods in computer systems and computer program products.

[0005] Further technical features and advantages are realized through the techniques of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, reference is made to the detailed specification and drawings.

[0006] The particulars of the exclusive rights set forth herein are particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The above-discussed and other features and advantages of embodiments of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a block diagram illustrating a system for buffer overflow trapping in accordance with one or more embodiments of the present invention. [Figure 2] FIG. 1 is a block diagram illustrating components of buffer overflow trapping in accordance with one or more embodiments of the present invention. [Figure 3]1 is a flowchart illustrating a process of buffer overflow trapping in accordance with one or more embodiments of the present invention. [Figure 4] FIG. 1 illustrates a cloud computing environment in accordance with one or more embodiments of the present invention. [Figure 5] FIG. 1 illustrates abstraction model layers in accordance with one or more embodiments of the present invention. [Figure 6] FIG. 1 illustrates a system for buffer overflow trapping in accordance with one or more embodiments of the present invention.

[0008] The diagrams shown herein are exemplary. There may be many variations in the diagrams or the operations described therein without departing from the spirit of the invention. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Additionally, the term "coupled," and variations thereof, indicates that there is a communication path between two elements, and does not imply a direct connection between elements with no intervening elements / connections between them. All of these variations are considered part of the specification. DETAILED DESCRIPTION OF THE INVENTION

[0009] One or more embodiments of the present invention provide a defense mechanism against buffer overflows by artificially inserting holes in normally contiguous memory allocations. According to one or more embodiments of the present invention, a translation table is used to map virtual memory addresses to physical addresses, and strategic holes are placed in the translation table mapping to force buffer overflows into areas that are likely to be open. Open areas of the translation table contain virtual addresses that are not assigned to physical memory addresses and are therefore not backed by physical memory. According to one or more embodiments of the present invention, a program that crosses its memory boundary by requesting access to an unbacked virtual memory address through the translation table operates the computer system's memory manager to obtain the requested virtual address. The data is then placed in a memory area referred to herein as overflow or honeypot memory.

[0010] An overflow or honeypot memory can be implemented by a pool of known, controlled memory regions within a computer system. According to one or more embodiments of the present invention, the overflow memory region is configured to prevent its contents from being executable by a program. This can be achieved, for example, by setting an instruction execution protection (IEP) bit to prevent code in each storage block of the overflow memory from being executed. While the overflow memory is being written, an intensive recording process can simultaneously collect information about the programs and / or data being written. The collected information can be stored and analyzed.

[0011] As known to those skilled in the art, the term "honeypot" refers to a computer security mechanism configured to detect, deflect, or in some way thwart attempts at unauthorized use of an information system. Generally, a honeypot contains data that appears to be a legitimate portion of a site or application but is actually segregated and monitored. The honeypot appears to contain information or resources of value to an attacker, who is subsequently blocked. The terms honeypot memory and overflow memory are used interchangeably herein to refer to a portion of memory utilized by one or more embodiments of the present invention when a program attempts to access a memory location not allocated to that program.

[0012] When computer programs utilize different regions of the same physical memory, it is important to keep the computer programs executing within their allocated memory regions. Software programs at higher levels (e.g., source code level) typically have checks that keep all program execution and data in organized locations within their allocated memory regions. However, at the microcode (or assembly) level, these built-in checks are often unavailable. This can occur for a variety of reasons, the most important of which are efficiency and / or performance considerations. Because the system trusts that the information provided in the microcode or assembly instructions is valid, these operations often do not check for data integrity. This allows these operations to be performed as quickly as possible.

[0013] For many of these low-level operations, the system utilizes a memory manager to mediate requests between a particular program's virtual memory and the physical or real memory where the data is stored. As noted above, in modern systems, the memory manager typically executes memory access requests without checking their ramifications, since checks performed by software layers above it ensure proper execution. Because the memory manager does not check for buffer overflows, a particular program may access areas of virtual or physical memory that it should not be able to access. Buffer overflows can occur due to human error or can be intentionally performed for malicious reasons. Buffer overflows often occur due to a miscalculation of an address or memory offset, resulting in a request to a memory location outside the requesting program's memory bounds, as defined by the arbitration function (e.g., a hypervisor) in which the program is running. A buffer overflow can cause a particular program to overwrite or manipulate data used by another running program, potentially causing numerous errors, crashes, collisions, and potentially bringing the system down.

[0014] One or more embodiments of the present invention provide a technical improvement over current methods of providing access to memory that can result in buffer overflows. A drawback of modern approaches is that a program may access a memory area allocated to another program and cause an error during the execution of the other program, such as by overwriting a memory location used by the other program. This may be due, for example, to poor code structure or poor handling of data sizes, resulting in writing to a section of memory just outside the boundaries of a code library. Furthermore, accessing a memory area allocated to another program may cause an error in the program accessing the memory, for example, by causing the program to read and process possibly invalid data from the other program. Another drawback of modern approaches is that if a program requests access to a virtual memory address that is not backed by physical memory, the program is notified of an error. In the event of a malicious attack, the attacker is notified that the virtual address is invalid, and the attacker can attempt to access other virtual addresses until a memory-backed address is found.

[0015] One or more embodiments of the present invention provide a technical solution to one or more of these shortcomings by creating a translation table with strategically placed gaps where virtual addresses are not mapped to physical addresses (i.e., unbacked virtual memory addresses). When a program attempts to access one of the unbacked memory addresses, the memory manager directs the access to overflow memory (e.g., by associating the virtual memory address in the request with a physical address in the overflow memory) and allows the program to execute the access to the overflow memory. The redirection to the overflow area is transparent to the requesting program, so potential hackers or threat actors are unaware that the program is accessing a memory location in the overflow area. The redirection of memory access prevents the program from accessing data outside of its allocated memory area, reducing system errors. Furthermore, in response to detecting an access to overflow memory, one or more embodiments of the present invention collect state information about the program and / or data being written that can be used to identify and analyze the program. If the program is malicious, this information can be used to recognize the problematic program and / or prevent future programs using similar tactics from executing.

[0016] Referring now to FIG. 1, a block diagram overview of a system 100 for buffer overflow trapping is shown in accordance with one or more embodiments of the present invention. The system includes an operating system (OS) 102, a hypervisor 108, a memory 110, and an overflow memory 114. As shown in FIG. 1, the OS 102 includes a memory manager 106, a program 104 executed by the OS 102, and a system and memory analyzer 116. In the embodiment shown in FIG. 1, the memory manager 106 provides an interface between the program 104 and the hypervisor 108 for requesting access to the memory 110. Additionally, the memory manager 106 provides an interface for redirecting memory access requests from the program 104 to the overflow memory 114 when necessary to avoid a buffer overflow. The system and memory analyzer 116 shown in FIG. 1 collects state information about programs and / or data being written that can be used to identify and analyze programs requesting access to unbacked memory addresses.

[0017] According to one or more embodiments of the present invention, memory manager 106 receives virtual memory addresses from program 104 and translates them into physical memory addresses located in either program memory 112 or overflow memory 114. Memory manager 106 may include a translation lookaside buffer (TLB), as is known in the art, to perform this translation. A simple check can be used to identify when program 104 is attempting to access a memory location outside its originally allocated space. Valid virtual memory addresses have physical memory allocated to them, and if a program or process requests data from an unbacked memory location, memory manager 106 immediately recognizes that the address is incorrect and does not execute the request. The memory manager's 106 ability to detect these buffer overflows is utilized by one or more embodiments of the present invention as a mechanism for identifying potentially malicious programs.

[0018] In accordance with one or more embodiments of the present invention, overflow memory 114 is located in a different physical memory device (or memory module or memory system) than memory 110, which includes program memory 112. In one or more embodiments of the present invention, overflow memory 114 and memory 110 are located in different regions of the same memory device (or memory module or memory system).

[0019] According to one or more embodiments of the present invention, the program 104 sends a write request including a virtual memory address and data to the memory manager 106. The memory manager 106 forwards the request to the hypervisor 108, which instructs the memory 110 to write the data to a memory location in the memory 110 at the physical memory address associated with the virtual memory address. If the virtual memory address is an unbacked virtual memory address, the memory 110 returns an error indicating the unbacked condition to the hypervisor 108, which relays the error indication to the OS 102. The hypervisor 108 then allocates a region in the honeypot or overflow memory 114 for the buffer overflow of the program 104 and notifies the memory manager 106 of the allocation. The memory manager 106 can store correspondence between the virtual memory address in the write request from the program 104 and the physical memory address in the overflow memory 114 in the TLB or elsewhere. The hypervisor 108 writes the data to the location in the overflow memory 114. The overflow memory 114 indicates to the hypervisor 108 that the write was successful, and the hypervisor 108 communicates the successful write status to the program 104, and the program 104 continues execution. The next time the program requests access to an unbacked virtual memory address, the memory manager 106 directs the program 104 to access the allocated overflow memory 114. The memory translation error is completely hidden from the program 104. The memory manager 106 flags the request, sends back an address for a region in the overflow memory 114, and forwards all subsequent requests within that range (e.g., at that virtual memory address) there. The memory manager 106 can further flag requests for additional pages requested by the program 104 and send them to this region in the overflow memory 114.In accordance with one or more embodiments of the present invention, the size of overflow memory 114 is sufficiently large that when overflow memory 114 approaches full capacity, the contents of overflow memory 114 are written to a disk configured to capture all of the information.

[0020] It should be understood that the block diagram of FIG. 1 is not intended to indicate that system 100 includes all of the components shown in FIG. 1. Rather, system 100 may include any suitable fewer or additional components not shown in FIG. 1 (e.g., additional memory components, programs, functional blocks, connections between functional blocks, modules, inputs, outputs, etc.). For example, system and memory analyzer 116 may be included in memory manager 106. In another example, system and memory analyzer 116 may run on a different processor under a different OS 102 than memory manager 106. Furthermore, what is described herein with respect to system 100 may be implemented with any suitable logic, and logic referred to herein may include any suitable hardware (e.g., a processor, an embedded controller, or an application-specific integrated circuit, etc.), software (e.g., an application, among others), firmware, or any suitable combination of hardware, software, and firmware in various embodiments.

[0021] 2, a block diagram 200 of components for buffer overflow trapping is shown in accordance with one or more embodiments of the present invention. The block diagram 200 of FIG. 2 shows a high-level flow of interaction between the TLB 208, the system and memory analyzer 116, the memory manager 106, the overflow memory 114, and a person 206 (e.g., a system administrator or security analyst).

[0022] The block diagram 200 of Figure 2 includes a TLB 208 for use in translating virtual memory addresses to physical memory addresses. The TLB 208 shown in Figure 2 includes memory-backed virtual memory addresses 204a, 204b, and 204c, which correspond to physical memory addresses, collectively referred to herein as memory-backed virtual memory addresses 204. The TLB 208 also includes non-backed virtual memory addresses 202a, 202b, 202c, and 202d, which are not assigned to physical memory addresses, collectively referred to herein as non-backed virtual memory addresses 202. The placement of non-backed virtual memory addresses 202 among memory-backed virtual memory addresses 204 is an example of artificially placing holes in normally adjacent memory allocations (e.g., sparse memory placement).

[0023] The TLB 208 shown in Figure 2 includes strategically placed holes in the TLB's mapping to push problematic buffer overflows into areas that are more likely to be open. This mechanism for placing holes in the TLB mapping is referred to herein as configuring the TLB using "sparse memory allocation." According to one or more embodiments of the present invention, memory-backed virtual memory addresses 204a include all virtual memory addresses assigned to "program a," memory-backed virtual memory addresses 204b include all virtual memory addresses assigned to "program b," and memory-backed virtual memory addresses 204c include all virtual memory addresses assigned to "program c." As shown in the TLB 208 of Figure 2, memory allocation is strategically performed to allow large regions of space between virtual addresses assigned to programs, making it less likely that one program will overlap the memory of another program.

[0024] TLB 208 implementations are not limited to keeping all virtual addresses of a program in contiguous entries, as memory allocated to a program may be divided into multiple segments. One or more embodiments of the present invention may offset common memory segments (e.g., 512 megabyte (MB) or 2048 MB pages) and place unbacked memory segments at the beginning and end of each segment at known offsets. For example, if a page ends at memory address 0x000A, a hole may be placed in TLB 208 at location 0x000B. Any attempt by a program or process to access the memory segment here will result in an immediate failure. Without this scheme, if location 0x000B is in use (and therefore backed) by another program or process, an erroneous process could overwrite 0x000B all the way to the next unbacked memory location, throwing the entire page away and affecting the operation of many other processes.

[0025] Utilizing a memory system with many holes in its memory space, as shown in TLB 208 of FIG. 2, provides a unique defense against malicious buffer overflows by reducing the likelihood that a buffer overflow will bleed over into another program's memory. Additionally, one or more embodiments of the present invention utilize the virtual memory system's (e.g., memory manager 106) ability to know whether a page is backed to detect when a program has exceeded its boundaries. When a trigger occurs indicating that a program has exceeded its boundaries, memory manager 106 places the data being written into honeypot or overflow memory 114. Honeypots generally appear desirable to malicious individuals, but are actually traps to learn more about the attacker.

[0026] According to one or more embodiments of the present invention, the honeypot, or overflow memory 114, is located in a pool of known, controlled memory regions within the system. Each section of memory within the memory pool has an instruction execution protection (IEP) bit set to prevent execution of the code or computer instructions stored in that section. Because anything written to that location cannot be executed by the system, writes to that location can be permitted to examine the data contents. When the memory manager 106 detects that a buffer overflow has occurred, it accesses the pool of memory regions and begins allowing programs to write to that memory (e.g., overflow memory 114), while simultaneously initiating an intensive recording process using the system and memory analyzer 116 to gather information about the programs or data being written. As shown in FIG. 2, a code buffer overflow is detected in an unbacked memory location 202c, and the overflow detection triggers the memory manager 106 to direct the data to a memory subpool that includes the overflow memory 114.

[0027] According to one or more embodiments of the present invention, the system and memory analyzer 116 records state information about programs and / or data, such as, but not limited to, an identifier for the program or process that caused the buffer overflow, the data being written, network activity, code style, a Message Digest Algorithm 5 (MD5) hash of the data (e.g., computer code) being written, addresses being accessed by the computer code being written, loaders associated with the execution of the computer code being written, and / or other statistics about the contents of memory, such as size and addresses the code requests access. The collected data can be saved (e.g., written to memory) and then analyzed. The analysis can be performed manually by a person 206, such as a system administrator or security analyst, or the analysis can be automated.

[0028] According to one or more embodiments of the present invention, information collected by the system and memory analyzer 116 (e.g., status information) may be checked against known attack frameworks, such as, but not limited to, Mitre Att&ck™, to determine whether the behavior and / or threat tools associated with MD5 hashes, statistics, addresses, etc., are associated with a known threat actor or pattern. A threat actor, as known in the art, refers to an entity that attempts or successfully performs malicious activity against an enterprise, whether intentionally or unintentionally. This information regarding whether a buffer overflow is associated with a known threat actor or pattern can be further used by a person 206, such as a system administrator or security analyst, to secure the machine and seek additional attack surfaces to further protect the enterprise. For example, a processor's security policy can be updated based on the status information. Examples of security policies include, but are not limited to, network signatures, log trails, programs allowed to run on the machine, data access, and identities used.

[0029] In accordance with one or more embodiments of the present invention, given all of the memory transfers and intensive recording of information, the system and memory analyzer 116 may be located within separate hardware to accelerate the response to such attacks. Additionally, all or part of the memory manager 106 may also be located on separate hardware.

[0030] Figure 3 illustrates an overview flowchart of a process 300 for buffer overflow trapping in accordance with one or more embodiments of the present invention. The process illustrated in Figure 3 may be performed by an operating system, such as OS 102 of Figure 1, running on a computer processor. The computer processor may be a standalone processor or a node in a cloud, such as node 10 of Figure 4.

[0031] At block 302, a write request is received from a program. The write request includes a virtual memory address and data to be written to memory. At block 304, it is determined that the virtual memory address is not assigned to a physical memory address, and that the virtual memory address is assigned to a physical memory address in the overflow memory. At block 306, the data is written to the physical memory address in the overflow memory. At block 308, an indication of successful completion of the data write request is returned to the program. In accordance with one or more embodiments of the present invention, the program is unaware that the data was written to the overflow location. An indicator that the data was successfully written to memory is returned to the program, and future access requests by the program to the virtual memory address are directed to the physical memory address in the overflow memory.

[0032] In accordance with one or more embodiments of the present invention, recording of state information regarding one or both of the data and the program is initiated in response to determining that the virtual address is not mapped to a physical memory address. The state information can be utilized to identify patterns associated with malicious programs or threat actors. In accordance with one or more embodiments of the present invention, a security policy of the processor is updated based at least in part on the state information.

[0033] In accordance with one or more embodiments of the present invention, the overflow location is configured to prevent computer code from being executed from the overflow location. In accordance with one or more embodiments of the present invention, a TLB is used to translate virtual memory addresses to physical memory addresses, and the TLB is configured using a sparse memory arrangement.

[0034] One or more embodiments of the present invention are implemented based on a buffer overflow mode of a processor. The buffer overflow mode of a processor can be determined, for example, based on the setting of a flag or other indicator, and the writing of data to the overflow memory location can be performed based on the buffer overflow mode of the processor, which is a first mode. Based on the buffer overflow mode, which is a second mode, blocks 304 and 306 can be skipped, and instead, an indication to the program that the write did not complete successfully is returned to the program. Additionally or alternatively, the buffer overflow mode can be associated with a particular program or group of programs. The buffer overflow mode of a processor is programmable and can be set automatically or by a system administrator, for example. In this manner, the writing to the overflow memory location and the analysis responsive to the detection of the buffer overflow condition can be selectively applied to programs running on a particular processor, specific programs, selected time frames, etc., during a particular lifecycle phase (e.g., during testing),

[0035] 3 is not intended to indicate that the operations of process 300 are performed in a particular order or that all operations of process 300 are included in all cases. Additionally, process 300 may include any suitable number of additional operations.

[0036] Although this disclosure includes detailed descriptions of cloud computing, implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the invention can be practiced in conjunction with any other type of computing environment now known or later developed.

[0037] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0038] The characteristics are as follows:

[0039] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0040] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs).

[0041] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, resulting in a sense of location independence. However, consumers may be able to determine location at a higher level of abstraction (e.g., country, state, data center).

[0042] Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly release to instantly scale in. To the consumer, the computing power available for provisioning often appears unlimited, and can be purchased at any time and in any quantity.

[0043] Metered Services: Cloud systems leverage measurement capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0044] The service model is as follows:

[0045] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functionality, except for limited user-specific application configuration settings.

[0046] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment.

[0047] Infrastructure as a Service (IaaS): The functionality offered to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which they can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0048] The deployment model is as follows:

[0049] Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise.

[0050] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises.

[0051] Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0052] Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent nuances but is bound by standards or specific technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0053] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0054] FIG. 4 illustrates an exemplary cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., PDAs or cell phones 54A, desktop computers 54B, laptop computers 54C, or automobile computer systems 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 50 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N illustrated in FIG. 4 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

[0055] A set of functional abstraction layers provided by the cloud computing environment 50 (FIG. 4) is now shown in FIG. 5. It should be understood in advance that the components, layers, and functions shown in FIG. 5 are merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0056] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0057] The virtualization layer 70 provides an abstraction layer from which the following virtual entities can be provided, for example: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0058] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment; Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources; By way of example, these resources may include application software licenses; Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources; User portal 83 provides consumers and system administrators with access to the cloud computing environment; Service level management 84 enables allocation and management of cloud computing resources so that requested service levels are met; Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future cloud computing resources required in accordance with SLAs.

[0059] The workload layer 90 provides examples of functionality available to a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and automated discovery and cataloging or inventorying of items or assets at a location or property 96.

[0060] It should be appreciated that one or more embodiments of the present invention may be practiced in conjunction with any other type of computing environment now known or later developed.

[0061] Referring to Figure 6, an overview of a computer system for buffer overflow trapping is shown in accordance with one or more embodiments of the present invention. The methods described herein can be implemented in hardware, software (e.g., firmware), or a combination thereof. In one or more exemplary embodiments of the present invention, the methods described herein are implemented in hardware as part of a microprocessor of a specialized or general-purpose digital computer, such as a personal computer, workstation, minicomputer, or mainframe computer. Thus, system 600 may include a general-purpose computer or mainframe 601 capable of simultaneously running multiple instances of an O / S.

[0062] With respect to hardware architecture, as shown in FIG. 6 , in one or more exemplary embodiments of the present invention, a computer 601 includes one or more processors 605, a memory 610 coupled to a memory controller 615, and one or more input and / or output (I / O) devices 640, 645 (or peripherals) communicatively coupled via a local input / output controller 635. The input / output controller 635 may be, for example, but not limited to, one or more buses or other wired or wireless connections as known in the art. The input / output controller 635 may have additional elements, omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers to enable communication. Furthermore, the local interface may include address, controller, and / or data connections to enable appropriate communication between the aforementioned components. The input / output controller 635 may include multiple sub-channels configured to access the output devices 640 and 645. The sub-channels may include fiber optic communication ports.

[0063] Processor 605 is a hardware device for executing software, particularly software stored in storage 620, such as cache storage or memory 610. Processor 605 may be any custom-made or commercially available processor, a central processing unit (CPU), a coprocessor among several processors associated with computer 601, a semiconductor-based microprocessor (in the form of a microchip or chipset), a microprocessor, or generally any device for executing instructions.

[0064] The memory 610 can include any one or combination of volatile memory elements (e.g., random access memory (RAM, e.g., DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (e.g., ROM, erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), tape, compact disc read-only memory (CD-ROM), disk, diskette, cartridge, cassette, etc.). Furthermore, the memory 610 can incorporate electronic, magnetic, optical, or other types or combinations of storage media. It should be noted that the memory 610 may have a distributed architecture in which various components are located remotely from each other, yet can be accessed by the processor 605.

[0065] The instructions in memory 610 may include one or more separate programs, each of which may include an ordered list of executable instructions for implementing a logical function. In the example of Figure 6, the instructions in memory 610 are a suitable operating system (OS) 611. The operating system 611 essentially controls the execution of other computer programs and provides scheduling, input / output control, file and data management, memory management, and communication control and related services.

[0066] According to one or more embodiments of the present invention, memory 610 may include multiple logical partitions (LPARs), each running an instance of an operating system. The LPARs may be managed by a hypervisor, which may be a program stored in memory 610 and executed by processor 605.

[0067] In one or more exemplary embodiments of the invention, a conventional keyboard 650 and mouse 655 may be coupled to the input / output controller 635. Other output devices, such as I / O devices 640, 645, may include input devices such as, but not limited to, printers, scanners, microphones, etc. Finally, the I / O devices 640, 645 may include devices that communicate both input and output, such as network interface cards (NICs) or modulators / demodulators (for accessing other files, devices, systems, or networks), radio frequency (RF) or other transceivers, telephone interfaces, bridges, routers, etc. The system 600 may further include a display controller 625 coupled to a display 630.

[0068] In one or more exemplary embodiments of the present invention, system 600 may further include a network interface 660 for coupling to a network 665. Network 665 may be an IP-based network for communication between computer 601 and any external servers, such as clients, via a broadband connection. Network 665 transmits and receives data between computer 601 and external systems. In exemplary embodiments, network 665 may be a managed IP network managed by a service provider. Network 665 may be implemented in a wireless manner using wireless protocols and technologies such as WiFi®, WiMax®, etc. Network 665 may also be a packet-switched network such as a local area network, wide area network, metropolitan area network, Internet network, or other similar type of network environment. Network 665 may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN), a personal area network (PAN), a virtual private network (VPN), an intranet, or other suitable network system, and includes equipment for transmitting and receiving signals.

[0069] If computer 601 is a PC, workstation, intelligent device, etc., the instructions in memory 610 may further include a basic input / output system (BIOS) (omitted from the diagram for simplicity). The BIOS is a set of essential software routines that initializes and tests hardware at startup, starts OS 611, and supports data transfer between hardware devices. The BIOS is stored in ROM so that the BIOS can be executed when computer 601 is turned on.

[0070] When computer 601 is operating, processor 605 is configured to execute instructions stored in memory 610, communicate data to and from memory 610, and generally control the operation of computer 601 in accordance with the instructions. In accordance with one or more embodiments of the present invention, computer 601 is an example of cloud computing node 10 of FIG. 4 .

[0071] Various embodiments of the present invention are described herein with reference to the associated drawings. Alternate embodiments of the present invention may be devised without departing from the scope of the present invention. In the following description and in the drawings, various connections and relationships (e.g., above, below, adjacent, etc.) between elements are shown. These connections and / or relationships may be direct or indirect unless otherwise specified, and the present invention is not intended to be limited in this respect. Thus, coupling of entities may refer to either direct or indirect coupling, and relationships between entities may be direct or indirect. Furthermore, various tasks and process steps described herein may be combined into a more comprehensive procedure or process having additional steps or functions not specifically described herein.

[0072] One or more of the methods described herein can be implemented with any one or combination of the following technologies known in the art: discreet logic circuits having logic gates for implementing logical functions on data signals, application specific integrated circuits (ASICs) having appropriate combinations of logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0073] For the sake of brevity, conventional techniques related to making and using aspects of the present invention may or may not be described in detail herein. In particular, various aspects of computing systems and specific computer programs for implementing various technical features described herein are well known. Thus, for the sake of brevity, many conventional implementation details are only briefly mentioned herein or are omitted entirely without providing details of well-known systems and / or processes.

[0074] In some embodiments, various functions or acts may be performed at a given location, or in connection with the operation of one or more devices or systems, or both. In some embodiments, a portion of a given function or act may be performed at a first device or location, and the remainder of the function or act may be performed at one or more additional devices or locations.

[0075] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. As used herein, the term "comprises" and / or "comprising" specifies the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but does not exclude the presence or addition of one or more other features, integers, steps, operations, element components, or groups or combinations thereof.

[0076] All corresponding structure, material, acts, and equivalent or step-plus-function elements in the following claims are intended to include any structure, material, or act for performing a function in combination with other claimed elements, as specifically claimed. This disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the disclosure. The embodiments were chosen and described to best explain the principles and practical applications of the disclosure and to enable those skilled in the art to understand the disclosure in various embodiments with various modifications suitable for the particular use contemplated.

[0077] The diagrams shown herein are exemplary. There may be many variations to the diagrams or the steps (or operations) described therein without departing from the spirit of the disclosure. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Also, the term "coupled" describes having a signal path between two elements and does not imply a direct connection between elements with no intervening elements / connections between them. All of these variations are considered part of the disclosure.

[0078] The following definitions and abbreviations are used in interpreting the claims and the specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," "containing," or any other variation thereof, are exclusive inclusions. For example, a composition, mixture, process, method, article, or device that includes a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed in such composition, mixture, process, method, article, or device.

[0079] Additionally, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" are understood to include one or more, i.e., any integer number such as 1, 2, 3, 4, etc. The term "plurality" is understood to include two or more, i.e., any integer number such as 2, 3, 4, 5, etc. The term "connected" can include both indirect and direct "connections."

[0080] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with measurement of a particular quantity based on equipment available at the time of filing. For example, "about" can include a range of ±8%, 5%, or 2% of a particular value.

[0081] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0082] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, by way of example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, mechanically encoded devices having instructions recorded on punch cards or ridge-in-groove structures, or the like, and suitable combinations thereof. Computer-readable storage devices, as used herein, should not be construed as ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0083] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, a LAN, a WAN, or a wireless network, or a combination thereof). The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computer / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computer / processing device for storage.

[0084] The computer-readable program instructions for carrying out the operations of the present invention can be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer-readable program instructions can execute entirely on the user's computer as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to customize the electronic circuitry for carrying out aspects of the present invention.

[0085] Aspects of the present invention are described herein with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. Each block of the flowchart and / or block diagrams, and combinations of blocks in the flowchart and / or block diagrams, can be implemented by computer-readable program instructions.

[0086] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the processor of such computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having the instructions stored thereon thereby constitutes an article of manufacture including instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0087] Computer-readable program instructions may also be loaded into a computer, other programmable device, or other device and a series of operational steps executed on the computer, other programmable device, or other device to create a computer-implemented process, whereby the instructions executing on the computer, other programmable device, or other device perform the functions / operations identified in one or more blocks in the flowcharts and / or block diagrams.

[0088] The flowcharts and block diagrams in the figures of this disclosure illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for performing a specific logical function. In some implementations, the functions depicted in the blocks may be performed in a different order than that depicted in the figures. For example, two blocks shown in succession may actually be accomplished as a single step, executed simultaneously or substantially simultaneously, executed in a partially or fully overlapping manner, or executed in reverse order, depending on the functionality involved. Note that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs a specific function or operation, or by a combination of dedicated hardware and computer instructions.

[0089] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments described herein.

Claims

1. receiving, in an operating system executing on a processor, a write request from a program that writes data to memory, the write request including a virtual memory address and the data; determining that the virtual memory address is not mapped to a physical memory address; based on said determining, assigning said virtual memory addresses to physical memory addresses in an overflow memory; writing the data to the physical memory address in the overflow memory; returning an indication to the program that the data was successfully written to the memory, such that subsequent access requests by the program to the virtual memory address will be directed to the physical memory address in the overflow memory; Including, The method further comprising initiating recording of state information regarding one or both of the data and the program in response to determining that the virtual memory address is not mapped to a physical memory address.

2. The method of claim 1 , wherein the state information is utilized to identify patterns associated with malicious programs or threat actors.

3. The method of claim 1 , wherein the processor's security policy is updated based at least in part on the state information.

4. 2. The method of claim 1, wherein the data comprises computer code, and the overflow location is configured to prevent the computer code from being executed from the overflow location.

5. 10. The method of claim 1, wherein a translation lookaside buffer (TLB) is used to translate virtual memory addresses to physical memory addresses, the TLB being configured using a sparse memory layout.

6. determining a buffer overflow mode of the processor, wherein the allocating, writing, and returning are performed based on the buffer overflow mode of the processor being a first mode; and in response to determining that the virtual memory address is not mapped to a physical memory address in the memory based on the buffer overflow mode, which is a second mode, returning an indication to the program that the write was not completed successfully. The method of claim 1 further comprising:

7. One or more processors for executing computer-readable instructions, the computer-readable instructions causing the one or more processors to: receiving, in an operating system executing on one of the one or more processors, a write request from a program that writes data to memory, the write request including a virtual memory address and the data; determining that the virtual memory address is not mapped to a physical memory address; based on said determining, assigning said virtual memory addresses to physical memory addresses in an overflow memory; writing the data to the physical memory address in the overflow memory; returning an indication to the program that the data was successfully written to the memory, such that subsequent access requests by the program to the virtual memory address will be directed to the physical memory address in the overflow memory; The operations further include initiating recording of state information regarding one or both of the data and the program in response to determining that the virtual memory address is not mapped to a physical memory address.

8. The system of claim 7 , wherein the state information is utilized to identify patterns associated with malicious programs or threat actors.

9. The system of claim 7 , wherein the processor's security policy is updated based at least in part on the state information.

10. 8. The system of claim 7, wherein the data comprises computer code, and the overflow location is configured to prevent the computer code from being executed from the overflow location.

11. 8. The system of claim 7, wherein a translation lookaside buffer (TLB) is used to translate virtual memory addresses to physical memory addresses, the TLB being configured using a sparse memory layout.

12. The operation further comprises: determining a buffer overflow mode of the processor, wherein the allocating, writing, and returning are performed based on the buffer overflow mode of the processor being a first mode; and in response to determining that the virtual memory address is not mapped to a physical memory address in the memory based on the buffer overflow mode, which is a second mode, returning an indication to the program that the write was not completed successfully. The system of claim 7 further comprising:

13. A computer program comprising program instructions executable by a processor, the program instructions causing the processor to: receiving, in an operating system executing on the processor, a write request from a program that writes data to memory, the write request including a virtual memory address and the data; determining that the virtual memory address is not mapped to a physical memory address; based on said determining, assigning said virtual memory addresses to physical memory addresses in an overflow memory; writing the data to the physical memory address in the overflow memory; returning an indication to the program that the data was successfully written to the memory, such that subsequent access requests by the program to the virtual memory address will be directed to the physical memory address in the overflow memory; Let the operation, including The computer program product, wherein the operations further include initiating recording of state information regarding one or both of the data and the program in response to determining that the virtual memory address is not mapped to a physical memory address.

14. The computer program product of claim 13 , wherein the processor's security policy is updated based at least in part on the state information.

15. 14. The computer program product of claim 13, wherein the data comprises computer code, and the overflow location is configured to prevent the computer code from being executed from the overflow location.

16. 14. The computer program product of claim 13, wherein a translation lookaside buffer (TLB) is used to translate virtual memory addresses to physical memory addresses, the TLB being configured using a sparse memory layout.

17. The operation further comprises: determining a buffer overflow mode of the processor, wherein the allocating, writing, and returning are performed based on the buffer overflow mode of the processor being a first mode; and in response to determining that the virtual memory address is not mapped to a physical memory address in the memory based on the buffer overflow mode, which is a second mode, returning an indication to the program that the write was not completed successfully.

14. The computer program of claim 13, further comprising:

Citation Information

Patent Citations

  • Buffer overflow detection method, buffer overflow detection program, and buffer overflow detection device

    JP2009259078A

  • Injecting trap code in an execution path of a process executing a program to generate a trap address range to detect potential malicious code

    US20190318081A1