A system and method in one embodiment includes modules for detecting an access attempt to a critical address space (CAS) of a guest operating system (OS) that has implemented address space layout randomization in a hypervisor environment, identifying a process attempting the access, and taking an action if the process is not permitted to access the CAS. The action can be selected from: reporting the access to a management console of the hypervisor, providing a recommendation to the guest OS, and automatically taking an action within the guest OS. Other embodiments include identifying a machine address corresponding to the CAS by forcing a page fault in the guest OS, resolving a guest physical address from a guest virtual address corresponding to the CAS, and mapping the machine address to the guest physical address.
TECHNICAL FIELD
This disclosure relates in general to the field of computer networks and, more particularly, to a system and a method for critical address space protection in a hypervisor environment.
BACKGROUND
The field of computer network security has become increasingly important and complicated in today's society. Computer network environments are configured for virtually every enterprise or organization, typically with multiple interconnected computers (e.g., end user computers, laptops, servers, printing devices, etc.). Moreover, cloud service providers (and other organizations that run multiple applications and operating systems) may use hypervisor technology to run various different guest operating systems concurrently on a host device. A hypervisor is computer software/hardware platform virtualization software that allows multiple operating systems to run on a host computer concurrently. Security threats can originate externally and internally in the hypervisor environment. These threats in the hypervisor environment can present further challenges to IT administrators.
BRIEF DESCRIPTION OF THE DRAWINGS
To provide a more complete understanding of the present disclosure and features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying figures, wherein like reference numerals represent like parts, in which:
FIG. 1 is a simplified block diagram illustrating components of a system for critical address space protection in a hypervisor environment according to an example embodiment;
FIG. 2 is a simplified block diagram illustrating additional details of the system according to an example embodiment; and
FIG. 3 is a simplified flow-chart illustrating example operational steps that may be associated with embodiments of the present disclosure.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS
Overview
A system and method in one embodiment includes modules for detecting an access attempt to a critical address space (CAS) of a guest operating system (OS) that implements address space layout randomization (ASLR) in a hypervisor environment, identifying a process attempting the access, and taking at least one action if the action is not permitted. The action may be one or more of: reporting the access to a management console of the hypervisor, providing a recommendation to the guest OS, and automatically taking an action within the guest OS. Reporting the access to a management console of the hypervisor includes flagging a status of the guest OS as infected. Providing a recommendation to the guest OS includes recommending that the process be blacklisted, until it is scanned and whitelisted by a security tool, and/or running an anti-virus on the process. Taking an action within the guest OS includes running an anti-virus program in the guest OS and/or shutting down or saving a state of the guest OS for offline scanning.
More specific embodiments include the detecting the access attempt by generating page table entries (PTEs) for pages corresponding to the CAS in a shadow page table of the hypervisor and marking the PTEs such that the access attempt results in a page fault. The process attempting the access may be identified by reading a CR3 register corresponding to the process.
Other embodiments include validating the access attempt using a policy, including denying the access if the process is executing from a writeable area of a memory element, and permitting the access if the process is executing from a read-only area of the memory element. Other example embodiments include identifying a machine address corresponding to the CAS by forcing a page fault in the guest OS, resolving a guest physical address from a guest virtual address corresponding to the CAS, and mapping the machine address to the guest physical address and other features.
EXAMPLE EMBODIMENTS
FIG. 1 is a simplified block diagram illustrating an example implementation of a system 10 for critical address space protection in a hypervisor environment. As used herein, a "hypervisor" is a hardware virtualization entity that allows one or more operating systems (OSs), termed "guest OSs," to run concurrently on a host device (e.g., computer). In an example embodiment, a hypervisor can run directly on the host device's hardware to control the hardware and to manage guest OSs. In an alternate embodiment, a hypervisor can run within a conventional OS environment (such as Linux OS) as a software layer supporting one or more guest OSs running on a higher level. Virtualization allows the guest OSs to run unmodified on isolated virtual environments (typically referred to as virtual machines or guests), where the host device's physical characteristics and behaviors are reproduced. More specifically, a guest can represent an isolated, virtual environment equipped with virtual hardware (processor, memory, disks, network interfaces, etc.). According to the embodiment illustrated in FIG. 1, system 10 comprises a hypervisor 12, which provides a virtualization environment to a guest 14. Any number of guests may be hosted on hypervisor 12 within the broad scope of the present disclosure. A single guest is representatively illustrated in FIG. 1 for ease of explanation.
Hypervisor 12 controls and manages hardware 16 of a host device (not shown) that is allocated for use by guest 14. Guest 14 may run a guest OS 18 on hypervisor 12. Guest OS 18 may support one or more applications 20. Hypervisor 12 may manage access of one or more applications 20 (referred to herein in the singular as application 20 to refer to one of the applications) to underlying hardware 16, such as a processor 22 and a machine memory 24. As used herein, "machine memory" refers to a memory element that is visible to hypervisor 12 as available on the host device. Guest OS 18 may present to applications 20 a guest virtual memory 26, which accesses a guest physical memory 28. As used herein, "guest virtual memory" refers to a substantially continuous virtual address space that is visible to applications 20 running inside guest 14. An address space refers to a range of discrete addresses, each of which may correspond to a memory location (i.e., address) at which an application (e.g., application 20) can store data and retrieve data later. "Guest physical memory" refers to the virtual memory that is visible to guest OS 18.
Guest 14 includes a virtual control register, namely, CR3 register 30, which points to the beginning of a page table of a process of application 20. A process is an instance of an application (or a portion thereof), whose instructions are being executed. Application 20 in guest OS 18 may consist of a number of processes. Each process can have its own (unique) process address space. Each process address space has a corresponding page table. A page table is a data structure used by guest OS 18 to store a mapping between virtual addresses and physical addresses. For example, CR3 register 30 may uniquely identify a process that attempts to access a protected area of memory in guest OS 18 called critical address space (CAS), which includes system libraries (e.g., kernel32.dll).
Guest OS 18 includes an agent 32 (as part of a guest image) that communicates with a hyperCASP module 34 in hypervisor 12. HyperCASP module 34 may also communicate with guest physical memory 28, CR3 register30 and machine memory 24. HyperCASP module 34 may protect guest 14against potential malware attacks by trapping access attempts to the CAS and examining the context from which the access attempt occurs inside the hypervisor environment.
Hypervisor 12 may be managed using a management console 36. Management console 36 may provide a unified interface to manage guest 14 on hypervisor12. Management console 36 may provide a means for an administrator to configure hypervisor 12, including storage, controlling aspects of guest behavior, and setting up virtual networks. In an example embodiment, management console 36 may provide an interface for the administrator to view a status of guest 14, including whether it is under attack by malware and/or other unwanted applications.
According to embodiments of the present disclosure, components of system 10may detect an access attempt to the CAS of guest OS 18, identify the process that performs the access attempt, determine whether the access is permitted, and if the access is not permitted, take one or more protective actions such as report the access attempt to management console 36, provide a recommendation to guest OS 18, automatically take an action within guest OS18, etc.
For purposes of illustrating the techniques of system 10, it is important to understand the activities and security concerns that may be present in a given system such as the system shown in FIG. 1. The following foundational information may be viewed as a basis from which the present disclosure may be properly explained. Such information is offered earnestly for purposes of explanation only and, accordingly, should not be construed in any way to limit the broad scope of the present disclosure and its potential applications.
In one method of managing physical memory, memory may be divided into blocks or pages that cover a continuous range of memory addresses. Each block or page is given attributes that includes whether the memory is read-only, read/write or write-only. When an application or a library (including a dynamically linked library such as kernel32.dll) is loaded into memory, the corresponding code instructions are loaded into read-only memory and data is loaded into writable memory. Thus, code instructions may be read and executed from read-only memory. Some memory, such as that containing executable code (e.g., instructions), is typically read-only memory; the operating system may not allow a process to write data over its executable code. By contrast, (non-malware) pages containing data can be written to, but attempts to execute that memory as instructions may fail.
However, malicious code may be configured to be loaded or injected into data, and may be configured to execute from writable memory, and not read-only memory, as expected. Detection of code running in writable memory space may be an indication that the code is malicious. For example, buffers used in networking are overflowed to inject malicious code. Web servers receiving service requests with data from untrusted hosts can be infected with malicious code embedded in the request and loaded by overflowing the web server's buffer. A predominant characteristic of malicious code loaded by buffer overflows (or by other improper techniques) is that the code is loaded into (and executed from) memory that is writeable.
In computer security, executable space protection can be used to mark certain memory regions (e.g., stack and heap memory) as non-executable, such that an attempt to execute machine code in these regions can cause an exception, or page fault. A page fault is a trap when a program accesses a page that is mapped in the virtual memory (e.g., guest virtual memory in hypervisor environments), but not loaded in the physical memory (e.g., machine memory in hypervisor environments). Such an approach helps to prevent certain buffer overflow attacks from succeeding, particularly those that inject and execute code. These attacks rely on some part of memory, usually the stack, being both writeable and executable. One method of detecting execution of malicious code is to check the memory attribute from which every processor instruction executes. However, such an approach may require large processing overhead to check memory attributes of every executed instruction, degrading computer performance.
Another technique to protect against malware execution is by controlling access to the CAS. CAS protection (CASP) protects against buffer overflow and stack overflow attacks by trapping access attempts to the CAS and examining the context from which the access attempt occurs. For example, most malware performs a lookup of kernel32.dll for function resolution (e.g., export functions). Kernel32.dll is a central module that contains core processes of an operating system, such as memory management, input/output operations, interrupts etc. Accordingly, CASP techniques can protect against attacks such as buffer overflow and stack overflow attacks by trapping access attempts to kernel32.dll.
Address space layout randomization (ASLR) is another technique that may be used to prevent security attacks by making it more difficult for an attacker to predict target addresses. ASLR moves executable images (i.e., units of program code in a format executable by a processor, such as files in DLL format or EXE format) into random locations when an operating system boots, making it harder for exploit code to operate predictably. The intention of ASLR is to protect physical memory from viruses and other malware. With ASLR, the OS (e.g., guest OS 18 in a hypervisor environment) randomly arranges positions of key data areas, including positions of libraries, heap and stack in a process's virtual address space. Without the use of ASLR, an attack could use hardcoded addresses of known locations in a process's address space (e.g., specific library functions) to perform its functions.
In an example, when an application creates a heap, the heap manager of the OS creates that heap at a random location in the process address space to help reduce the chance of success of a heap-based buffer overrun exploit. In another example, when a thread starts in a process, the OS (e.g., guest OS 18) moves the thread's stack to a random location in the process address space to help reduce the chance of success of a stack-based buffer overrun exploit. In yet another example, ASLR may cause each execution of a program to result in a different memory space layout, which causes dynamically loaded libraries (DLLs) to get loaded into different locations each time. Many malware attacks rely on a programmer's ability to accurately identify where specific processes or system functions reside in memory. With ASLR, address positions are randomized, making it harder for malware code to execute successfully.
For example, in Windows Vista OS, when loading an executable image that has elected to participate in ASLR, the OS uses a random global image offset selected once per reboot from a range of 256 values. Executable images loaded together into a process, including the EXEs and DLLs, are loaded one after another at this offset. When executing a program whose executable image has been marked for ASLR, the memory layout of the process is further randomized by placing the thread stack and the process heaps randomly. The stack address is selected first from a range of 32 possible locations. Once the stack has been placed, the initial stack pointer is further randomized by a random amount (e.g., chosen from one of 16,384 possible values on an IA32 system). Once the stack address has been selected, the process heaps are selected. Each heap is allocated from a range of 32 different locations. The location of the first heap is chosen to avoid the previously placed stack, and each of the heaps following must be allocated to avoid those that come before. In Windows Vista, some address space layout parameters, such as Process Environment Block, stack, and heap locations, are selected once per program execution. Other parameters, such as the location of the program code, data segment, and libraries, change only between reboots.
In a hypervisor environment, effects of an attack may be more severe than in a non-virtualized environment. One infected guest could infect all other guests on the host device. For example, an attacker can get administrator privileges on the hardware through infecting a guest, and can move from one guest to another over the hypervisor environment. In situations where the hypervisor hosts tens of hundreds of guests, such a guest-to-guest attack could have catastrophic results.
Turning to some preliminary information associated with how virtual memory systems are configured in the hypervisor, when running a guest, the hypervisor creates a contiguous addressable memory space for the guest. This memory space has the same properties as the guest virtual memory. This allows the hypervisor to run multiple virtual machines simultaneously while protecting the memory of each virtual machine from being accessed by others. Therefore, from the view of the application running inside the guest, the hypervisor adds an extra level of address translation that maps a guest physical address to a machine address. Communication between the guest OS and hypervisor happens via hypercalls, which may set up parameters in the guest physical address, and the hypervisor may decode the parameters, map the guest physical address to the machine address and perform the requested action.
The guest physical memory (e.g., guest physical memory 28) is merely an abstraction utilized by the hypervisor (e.g., hypervisor 12) for maintaining correct mapping to the host physical address (also called machine address). Shadow page tables are used by the hypervisor (e.g., hypervisor 12) to map the guest physical memory (e.g., guest physical memory 28) to the machine memory (e.g., machine memory 24). Typically, there is no guarantee that any pages, to which the guest page tables point, are present in machine memory. The hypervisor (e.g., hypervisor 12) is configured to enable a page fault every time there is an attempt by the guest OS (e.g., guest OS 18) to access a not-present page. Upon triggering a page fault, a page fault handler in the hypervisor facilitates loading the appropriate page (e.g., from disk) into machine memory, and updates the hypervisor's shadow page tables to reflect the changes. Execution of the instruction that caused the page fault resumes after the page has been loaded into machine memory and the paging tables appropriately point to the correct page. The hypervisor's paging tables reflect which pages are actually (i.e., physically) loaded in machine memory, while the guest paging tables are merely virtual.
Turning to process memory management, in many processors (not necessarily running hypervisors), a control register called CR3 register (e.g., CR3 register 30) contains the physical address of the root (i.e., the beginning) of the current page table (called the page directory). In a hypervisor environment, the CR3 register in the guest may be virtualized and may point to the guest physical address of the root of the current guest page table. The physical processor (e.g., processor 22) uses another CR3 register (not shown), and not the guest CR3 register (e.g., CR3 register 30), to address machine memory 24. The processor's CR3 register points to the hypervisor's page directory, not to the guest page directory. In contrast, the guest CR3 register (e.g., CR3 register 30) points to the guest page directory, which points to the guest page tables. Thus, with the virtual guest address converted to machine address through the sequence of guest CR3 register to guest page directory to guest page table to shadow page table to physical page, the current instruction can be executed.
Content of guest CR3 register 30 is updated by the kernel of the guest OS (e.g., guest OS 18) to point to appropriate page tables used by the currently executing process. Thus, the guest OS (e.g., guest OS 18) switches between processes by changing the value of the guest CR3 register (e.g., CR3 register 30). In virtual machines (e.g., guest 14), the hypervisor (e.g., hypervisor 12) intercepts any access to the CR3 register (e.g., CR3 register 30) and thereby determines the page to be fetched from machine memory 24 for the currently executing process.
Turning back to malware protection techniques, vulnerabilities in the hypervisor may undermine the effectiveness of ASLR. For example, a known vulnerability in a hypervisor makes otherwise in accessible portions of machine memory available for read/write access to applications running in the guest OS. Malware could exploit this vulnerability to gain control of the machine memory, despite ASLR. While CASP can be implemented inside the guest OS (e.g., guest OS 18) in the hypervisor environment, CASP in the guest OS cannot protect against vulnerabilities in the hypervisor. Moreover, a hypervisor-based implementation can provide an OS agnostic solution. There is value to the end user in such a solution because security software need not be installed individually inside each guest. Malware attacking the guest is oblivious to this security layer running inside the hypervisor. One of the challenges in implementing CASP in the hypervisor with ASLR implemented by guest OSs is that the hypervisor may not know the critical addresses to protect because the CAS is randomized by ASLR within the guest physical memory every time an application loads or there is a reboot of the guest operating system. Another challenge is to uniquely identify the guest process context from which the attack originates, so that appropriate protective action may be taken.
A system for critical address space protection in a hypervisor environment outlined by FIG. 1 can resolve these issues, among others. Embodiments of the present disclosure seek to vastly improve capabilities of existing technologies to allow for a more robust solution. In example embodiments, components of system 10 may detect access to the CAS of guest OS 18 in the hypervisor environment, wherein guest OS 18 implements ASLR, identify the process requesting the access, determine whether the access is permitted, and if the access is not permitted, take one or more protective actions.
As illustrated in FIG. 1, hyperCASP module 34 may communicate with agent 32 to identify the machine addresses corresponding to guest physical addresses of the CAS. Agent 32 may force a page fault in guest OS 18 by deliberately reading from the CAS addresses, and resolve the guest physical address from the guest virtual address. For example, the page fault may cause hypervisor 12 to intercept the page fault event and agent 32 may check the guest page table to determine the guest physical address of the corresponding guest virtual address. In another example, a page fault handler in hypervisor 12 may monitor the mapping of the guest physical page and may establish a corresponding mapping to the machine page in response to the page fault (e.g., by trapping accesses to the guest page tables).
Agent 32 may communicate the CAS guest physical addresses to hyperCASP module 34, which may map the machine addresses to the corresponding guest physical addresses. Thus, hyperCASP module 34 identifies the machine addresses to be protected. A page fault handler in hypervisor 12 may make an entry for those pages point to the corresponding pages in machine memory 24. In one example embodiment, agent 32 may communicate the CAS addresses to hyperCASP module 34 using a two way communication channel. By protecting the address space in machine memory 24corresponding to the CAS in guest virtual memory 28, hypervisor 12 can protect against malware attacks from within guest OS 18, for example, malware attempting to access the CAS.
According to embodiments of the present disclosure, hyperCASP module 34 may the detect an access attempt to the CAS by generating page table entries (PTEs) for pages corresponding to the CAS in the shadow page table of the hypervisor, marking the pages as NOT_PRESENT in the PTEs, such that substantially every access attempt results in a page fault. The page fault transfers control to hypervisor 12, so that hypervisor 12 can identify the process that accesses the CAS.
In one example embodiment, hyperCASP module 34 may read CR3 register 30 to identify the process attempting to access the CAS. Generally, hypervisors that use shadow page tables (like hypervisor 12) (e.g., shadow page tables implemented and accelerated using hardware support like Extended Page Tables/Nested Page Tables (EPT/NPT)) may trap CR3 register accesses for proper operation of guest 14. Thus, changes to CR3 register 30 may be trapped by hyperCASP module 34 to uniquely identify the process running in guest 14 that accesses the CAS. CR3 register 30 can identify the process by maintaining the root of the guest page tables of the current task. For example, a malware process may attempt to execute a task. The task has a context, which is a set of registers and values that are unique to the task. One such register is CR3 register 30, which contains the address of the malware process' page directory. Every time there is a CAS access within guest OS 18, hyperCASP module 34 may check to see if it is an attack (e.g., buffer/stack overflow) by looking at the page protection bits of an applicable instruction (of the process) that is currently executing.
HyperCASP module 34 may determine whether the access is permitted using a policy, such as a policy to deny the access if the access is from the writeable area of a memory element such as guest virtual memory, and a policy to permit the access if the access is from the read-only area of the memory element. For example, if a PTE shows that the access to the CAS in guest OS 18 came from a PTE in guest 14 with a write bit set, and a policy indicates that such status for the write bit is not permitted, the access may be illegal as it could be a result of a malware attack on the stack or heap of the process. In an example embodiment, hyperCASP module 34 may use the same bit (e.g., write bit) status value to allow bypassing of protection checks for false positives to allow legitimate access.
HyperCASP module 34 may take various protective actions to prevent execution of malware code. In an example embodiment, hyperCASP module 34 may report the access attempt to management console 36. An administrator can get a view of one or more guests (e.g., guest 14) running in system 10 (or in a set of systems, depending upon the environment), and hyperCASP module 34 may cause a flag to be set to mark the status of any infected guests. In another example embodiment, hyperCASP module 34 may provide a recommendation to guest OS 18 to blacklist the process until it is scanned and marked as clean (e.g., whitelisted) by an anti-virus or another security tool. In yet another example embodiment, hyperCASP module 34 may cause agent 32 to automatically take an action within guest OS 18, for example, run an anti-virus (initiated automatically) on detection of an attack within guest OS 18, or shutdown/save a state of the affected guest for offline scanning, etc.
Turning to FIG. 2, FIG. 2 is a simplified block diagram illustrating additional details of the system according to an example embodiment. A challenge in implementing a hypervisor based solution to CASP is to identify the machine address corresponding to the CAS (like kernel32.dll). The addresses of the CAS may be resolved using two levels of paging, one in guest 14 and another in hypervisor 12.
Processor 22 accesses memory addresses to fetch instructions or to fetch and store data as it executes application 20. In a virtual memory system such as guest OS 18, all of the addresses are guest virtual addresses (GVAs) and not guest physical addresses (GPAs). The virtual addresses are converted into physical addresses by guest OS 18 based on information held in a set of guest page tables. The guest page table maps the process's guest virtual pages into guest physical pages in memory. Hypervisor 12 maintains a shadow page table, corresponding to each guest page table. Each page table (including guest page table and shadow page table) comprises a list of PTEs. When guest OS 18 launches a process, it creates a PTE for the CAS, along with other PTE entries; correspondingly, hypervisor 12 updates its shadow page table as well.
An example set of address spaces are shown in FIG. 2. Assume a process X (e.g., in application 20) runs in guest OS 18and has a guest virtual address space 38 that maps into a corresponding guest physical address space 40 in guest OS 18. Each address space may be divided into a user space and the CAS such as kernel space. For example purposes and ease of explanation, the CAS in guest virtual address space 38 is indicated as CAS 60. Guest physical address space 40 maps into a machine address space 42. For example, a GVA 44 in guest virtual address space 38 may be mapped to a corresponding GPA 46 in guest physical address space 40, which in turn may be mapped to a machine address (MA) 48in machine address space 42. Each of these mappings are protected by suitable PTEs in corresponding page tables. For example, GVA 44 may be mapped to GPA 46 through PTEs in a guest page table 50. Hypervisor 12 may create a shadow page table 51 to map GPA 46 to MA 48. Shadow page table 51 may contain PTEs in a format similar to the format of PTEs in guest page table 50.
An example PTE 51 a of shadow page table 51 is shown in an exploded view in FIG. 2. PTE 51 a comprises a physical page address 52 (e.g., MA 48) of a page, a present bit 54, a write bit 56 and a read bit 58. HyperCASP module 34 may use the information in present bit 54, write bit 56 and read bit 58 to determine if the CAS is being accessed by malware. From the status of present bit 54, hyperCASP module 34 can determine whether a page corresponding to a particular address is present or not. In one example, assume GPA 46 of 100 translates to MA 48 of 5000. HyperCASP module 34would look at a PTE corresponding to 5000 and see if the process has access to MA 48 by reading present bit 54. If the process has access, present bit 54 would be set to 1. If present bit 54 is set to 0 (i.e., page is marked as NOT_PRESENT), indicating that the page is not present, a page fault may be raised. Control is then passed (by processor 22) to hypervisor12 to fix the fault. In another example, code instructions that access the CAS may have read bit 58 set, and write bit 56may not be set, indicating that the instructions are read-only (and not writable) and therefore permitted to have access.
When application 20 runs in guest OS 18, addresses of CAS 60 in guest virtual memory 26 may not necessarily be known to hypervisor 12, because addresses of CAS 60 may be randomized for security using ASLR by guest OS 18. When guest14 starts up, agent 32 may force a fault inside guest OS 18 and resolve it so that mapping is established from GVAs (e.g., GVA 44) to GPAs (e.g., GPA 46) corresponding to CAS 60 (e.g., kernel32.dll). Agent 32 may trap a first access attempt to CAS 60 (e.g., by setting the present bit to 0 (i.e., marking a page as NOT_PRESENT) in a PTE for CAS 60), so that every subsequent access may be trapped. Trapping the first access attempt to CAS 60 may ensure that further access to CAS60 can result in a page fault, because, if the present bit is established (or set to 1) for the corresponding GVAs (e.g., GVA44), processor 22 will not create any faults for additional access attempts to the GVAs (e.g., GVA 44).
Agent 32 may communicate addresses of CAS 60 to hyperCASP module 34 using a two way communication channel. GVAs (e.g., GVA 44) corresponding to CAS 60 may be translated to GPAs (e.g., GPA 46) using guest page table 50, and to MAs (e.g., MA 48) using shadow page table 51. At this time, hypervisor 12 has identified the MAs (e.g., MA 48) to protect against attacks using CASP methods. HyperCASP module 34 may generate PTEs (e.g., PTE 51 a) for pages corresponding to CAS 60 in shadow page table 51. HyperCASP module 34 may mark the pages as NOT_PRESENT in the PTEs (e.g., by setting present bit 54 to 0) to indicate that an access to CAS 60 results in a page fault 62. When an access to CAS 60 is detected through page fault 62, control passes to hypervisor 12 (through hyperCASP module 34), which may check if it is an attack (buffer/stack overflow). In an example embodiment, hyperCASP module 34 may run one or more checks (e.g., a predetermined set of checks) to see if the access is coming from a permitted process. Hypervisor12 may transparently inspect activity within guest OS 18 without knowledge of guest OS 18.
To determine which process is attacking CAS 60, hyperCASP module 34 may use CR3 register 30. Typically, hypervisor12 is not aware of tasks running inside guest OS 18. In an example embodiment, a malware 64 in process X may reside in guest virtual address space 38 and may attempt to access CAS 60 (e.g., kernel32.dll). Access to CAS 60 may result in page fault 62. Each task run by a process (e.g., process X) in guest OS 18, may be associated with a corresponding CR3 register 30, which comprises a task context that uniquely corresponds to the process that is performing the task. CR3 register 30 may point to a beginning of guest page table 50. HyperCASP module 34 may read CR3 register 30 and determine that process X is accessing CAS 60.
HyperCASP module 34 may validate the access attempt using a policy, including denying the access if the access is from a writeable area of a memory element (e.g., guest virtual address space 38) and permitting the access if the access is from a read-only area of the memory element. In an example embodiment, hyperCASP module 34 may read PTE 51 a in shadow page table 51 corresponding to the instruction that is currently executing. Because malware typically resides in user space (and not kernel space), write bit 56 of PTE 51 a may be set, indicating that the instruction is not read-only, and therefore may be illegal (e.g., indicating an attack on a stack or heap of process X).
Once hyperCASP module 34 identifies the attack, it may perform one or more protective actions. For example, if hypervisor 12 is running multiple guests, hyperCASP module 34 may flag the status of a guest as infected to management console 36. Alternatively, or additionally, hyperCASP module 34 may send one or more messages to agent 32 to offline (e.g., shut down) guest 14 or start an anti-virus (e.g., targeting the particular process and flagged host or hosts for cleaning) and/or inform guest OS 18 about the process that is infected. In an example embodiment, a recommendation may include blacklisting the process until it is scanned and marked as clean (i.e., whitelisted) by an anti-virus or another security tool (e.g., program for testing and/or fixing vulnerabilities in computer software and/or hardware).
Turning to FIG. 3, FIG. 3 is a simplified flow-chart illustrating example operational steps that may be associated with embodiments of the present disclosure. Operations 100 begin in 102, when hyperCASP module 34 and agent 32 are activated. In 104, agent 32 forces a page fault 62 in guest OS 18 by deliberately reading from the CAS addresses. In 106, agent 32 resolves the GPAs (e.g., GPA 46) corresponding to CAS 60. In 108, the GPAs (e.g., GPA 46) is mapped to the corresponding MAs (e.g., MA 48) using shadow page table 51. In 110, access attempts to the MAs (e.g., MA 48) is monitored by hyperCASP module 34, for example, by marking the pages corresponding to CAS 60 as NOT_PRESENT in PTEs (e.g., PTE 51 a) of shadow page table 51.
Any access attempt to CAS 60 may be detected in 112, for example, because an access attempt to CAS 60 results in page fault 62. If an access attempt is not detected (e.g., no page fault is generated), the process may loop back to monitoring in 110. When an access attempt is detected, however, control passes to hypervisor 12 in the form of page fault62. In 114, the process attempting the access may be identified, for example, using CR3 register 30. HyperCASP module34 may read CR3 register 30 to identify guest page table 50 corresponding to the process attempting the access. In 116, the access attempt may be validated using a policy. An example policy may indicate that write bit 56 is not set for valid access to CAS 60. If the policy does not permit access, as determined in 118, an attack may be indicated.
HyperCASP module 34 may take one or more protective actions in response, for example, reporting the access to management console 36 in 120; or automatically taking action within guest OS 18 in 122 (e.g., cause agent 32 to automatically initiate an anti-virus in guest OS 18; offline/shut down guest 14; save a state of guest OS 18 for offline scanning, etc.); or providing a recommendation to guest OS 18 in 124 (e.g., blacklist process, run anti-virus on the process, etc.). Similar actions may be taken for other resources used by the infected process like network sockets/file handles, etc. If the policy permits access, as determined in 118, the operations may end in 126.
Software for protecting address space (as well as inhibiting dangerous code from being executed) can be provided at various locations (e.g., within hyperCASP module 34). In one example implementation, this software is resident in a computer sought to be protected from a security attack (or protected from unwanted, or unauthorized manipulations of a writeable memory area). In a more detailed configuration, this software is specifically resident in a security layer of a hypervisor, which may include (or otherwise interface with) the components depicted by FIG. 1. In still other embodiments, software could be received or downloaded from a web server (e.g., in the context of purchasing individual end-user licenses for separate devices, separate virtual machines, hypervisors, servers, etc.) in order to provide this address space protection.
In other examples, the critical address space protection functions could involve a proprietary element (e.g., as part of an antivirus solution), which could be provided in (or be proximate to) these identified elements, or be provided in any other device, server, network appliance, console, firewall, switch, information technology (IT) device, etc., or be provided as a complementary solution (e.g., in conjunction with a firewall), or provisioned somewhere in the network. As used herein in this Specification, the term 'computer' is meant to encompass these possible elements (VMMs, hypervisors, Xen devices, virtual devices, network appliances, routers, switches, gateway, processors, servers, load balancers, firewalls, or any other suitable device, component, element, or object) operable to affect or process electronic information in a security environment. Moreover, this computer may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective protection of a critical address space. In addition, the critical address space protection functions can be consolidated in any suitable manner. Along similar design alternatives, any of the illustrated modules and components of the various FIGURES may be combined in various possible configurations: all of which are clearly within the broad scope of this Specification.