Security VM Components

Most of the software necessary to support the Turret framework resides in the Security VM. The only software not in the Security VM is that responsible for installing and protecting fine-grained hooks in the User VM. Applications that do not require this fine-grained active monitoring can operate completely within the Security VM. The key benefit to placing

software in the Security VM is that it is more difficult for malicious software in the User

VM to attack it.

Each VM is largely isolated from other VMs through software-based isolation provided by the hypervisor. However, this isolation must not be complete because the Security VM requires access to the User VM’s runtime state. Furthermore, the User VM requires some

interface with the hypervisor in order to interact with the system’s hardware. Different

deployment scenarios (e.g., home user versus military installation) operate under different

threat models. For the most secure settings, these interfaces must be minimized and audited

to maintain the security of the Turret framework. For less secure settings, it may be suffi-

cient to deploy Turret using an off-the-shelf virtualization solution. In either case, we refer

to the isolation between VMs as controlled isolation to emphasize that it is not absolute and that it must be managed to ensure adequate security.

This controlled isolation makes it very challenging to deploy useful security tools in the Security VM. This section describes how the Turret framework overcomes the challenges related to accessing the information needed to support security applications, including both active and passive monitoring techniques.

3.4.2.1 Virtual Machine Introspection

Virtual machine introspection (VMI) is the technique of viewing information about one VM from inside another VM. In the case of the Turret framework, it is used to view information about the User VM from within the Security VM. This is strictly a passive monitoring technique, so it can be used either for a polling-based application (e.g., to periodically

XenAccess Library

XenControl

Library XenStore

Library

Security VM Kernel + Drivers

Xen Hypervisor Monitor App #1 Monitor App #2 Monitor App #3 Memory Analysis

This software is available as part of the open source Xen virtualization platform. Section 3.4.2.1 introduces the XenAccess virtual machine introspection library. Chapter 4 discusses memory analysis. Chapters 5-6 discuss applications that utilize the Turret framework.

Figure 3: Turret’s virtual machine introspection capabilities are provided by the XenAc- cess Library. We originally created XenAccess to support this research, it is now available as an open source project at http://www.xenaccess.org.

scan memory for viruses) or to supplement event information for an active monitoring application.

In order to provide VMI capabilities to the Turret framework, we developed the Xe- nAccess Library. As shown in Figure 3, the XenAccess library is designed to operate in the Security VM using the XenControl and XenStore libraries that are provided with Xen. Building on top of these libraries, XenAccess provides both read and write access to the runtime memory state of the User VM. Applications using XenAccess can access this mem- ory using virtual addresses from the User VM’s kernel or from any of its applications (i.e., by specifying both the virtual address and the process identifier).

After requesting a specific virtual address, applications receive a pointer to the re-

quested page of memory, mapped from the User VM, along with the offset into that page

for the requested address. This low-level access leaves the application to interpret the data within each page of memory. A better solution, as depicted in Figure 3, is to place another layer of abstraction between XenAccess and the application. This memory analysis library can use domain-specific knowledge to extract useful information from the User VMs mem- ory as described in Chapter 4.

3.4.2.2 Hook Event Listener

Hook events are the notifications that originate when the User VM triggers a hook installed in its kernel space. Section 3.4.3 provides details about how the hooks are installed and protected. In this section, we consider the complementary software that receives these notifications.

The Security VM contains the back-end components for processing hook events. This includes a kernel-level driver and a user-space security application that receives the hook events. The security application is where the decision-making functionality of the monitor- ing solution is implemented. It can be any software component that makes use of Turret, such as an anti-virus tool or a host-based IDS. The kernel-level driver is the communica- tions agent responsible for relaying hook events between the User VM and the security application. These include hook notifications transmitted by the User VM and relayed by the hypervisor, and decisions sent by the security application to the User VM.

3.4.2.3 User-Initiated Hardware Event Interposition

As stated above, the Turret framework requires the ability to interpose on hardware events for one form of active monitoring. Virtualization has a similar requirement because these events must be multiplexed between the virtual machines running on a single computer.

Building off of this invariant, the framework taps into the location where this multiplexing

occurs. This ensures that applications using the framework have access to every hardware event. This mechanism amounts to a keystroke (and mouse event) logger running in the Security VM. However, unlike many keystroke loggers that are designed with malicious intent, we utilize knowledge of these events to improve the system’s security.

It is important to emphasize that the hardware events received by the framework come

directlyfrom the hardware without passing through the User VM first. In most virtualiza-

hypervisor runs directly on the hardware), the hardware interrupts go directly to the hy- pervisor and then they are either multiplexed from within the hypervisor or passed to a special virtual machine that multiplexes the events. In Type II virtualization (where a host operating system runs directly on the hardware), the host operating system receives the hardware interrupts and then multiplexes them to the virtual machines that are simply run- ning as processes within the host operating system. Either way, the key point is that these hardware interrupts are received by the framework before being received by the User VM. This means that malicious software in the User VM will not be able to forge or modify any hardware events. The Turret framework builds on this property to ensure the overall security of the system.

3.4.2.4 Transparent Network Interposition

The final type of active monitoring supported by Turret is driven by network traffic. This

traffic is redirected to a transparent proxy. The proxy can perform content analysis on

the outgoing network traffic at the network layer or the application layer. It can use the

receipt of a particular network packet as an active monitoring event. It can also determine

if outgoing network traffic is authorized to leave the system. Similarly, Turret can analyze

incoming network traffic; both for generating active monitoring events and for enforcing a

security policy.