标签：des style blog http color os io ar strong
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.
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.
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.
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.
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.
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.
SRC=https://www.google.com.hk/patents/US8694738
System and method for critical address space protection in a hypervisor environment
标签：des style blog http color os io ar strong
原文地址：http://www.cnblogs.com/coryxie/p/3962876.html
