Aplicación del procedimiento de evaluación del impacto de la capacitación en el

Our framework requires two special features from the hypervisor: protection of User OS components and specialized inter-VM communications. The hypervisor modifications re- quired to support these features are small, based on our implementation, which reduces the probability of introducing vulnerabilities into our TCB.

3.4.4.1 Guest OS Component Protection

The protection mechanism is one of the key pieces of Turret, as it guarantees the integrity of the user-space components of the framework. Unlike other framework components such as the VMI library and security application, which are isolated by the framework’s inher- ent design, the hooks and the trampoline are situated in the User OS’s untrusted kernel. Therefore these components require special protection to prevent an intruder from tamper- ing with their behavior. This type of tampering could involve the omission or forgery of events, or disabling the monitoring solution. Because the trampoline is self-contained and the hooks are jumps or function pointers, marking each hook’s memory as read-only is

sufficient to prevent tampering.

A straightforward solution adopted by several OSes to write-protect memory regions is to simply guarantee that the corresponding entries in the page tables used by processes are marked with the appropriate permission – read-only, in this case. Although useful to prevent certain classes of failures, such as memory corruption bugs, this approach is not suitable for a security scenario. As we assume that the intruder can take control of the kernel, she can simply modify the page tables to disable these protections. Going a step further, if a protection agent is used by the OS to prevent direct modifications to page tables, the intruder could instead disable the agent to then alter the page tables. This argument can be inductively generalized to any number of protection stages and the bottom-line is simple: if the protection mechanism is based entirely in a single domain that is controlled by the attacker (e.g., the User OS kernel), it can be disabled.

In a virtualized architecture, the hypervisor is an ideal place to implement such pro- tections for two reasons. First, as we assume it is part of our TCB, it cannot be tampered by a malicious user. Second, as part of its job in virtualizing the hardware, the hypervisor has complete mediation power over the memory mappings used by the VMs running on top of it. Our framework leverages this control to obtain a flexible, fine-grained memory protection mechanism. It is used to write-protect the hooks and the trampoline in the User OS’s memory, so that no tampering can occur with these components. A graphical repre- sentation of this protection is shown in Figure 2. The strength of this protection derives from the strength of the TCB itself: the only way an attacker could undo it would be to compromise the hypervisor, which we assume cannot be done.

Our approach of protecting the hooks and the trampoline inside the User VM is generic. It does not rely on any features provided by the User OS. The complete mediation capability

of the hypervisor over memory mappings of the User OS is sufficient. However, since the

placement of the hooks may vary between different User OSes for the same events, the

solution must take OS-specific architecture into account, and depending on the placement

of hooks and the trampoline, different memory locations and data structures would need to

be protected.

3.4.4.2 Inter-VM Communication

As our framework requires components located in different VMs to communicate, inter-

VM communication functionality is needed. The trampoline code in the User VM must send the events it captures from the hooks to the Security VM, and the reverse path must also be traversed by replies sent from the Security VM. As virtualization inherently pre- vents VMs from directly interacting with each other, the implementation of such functional- ity must involve the hypervisor. The key property of the Turret communication mechanism

that makes it different from existing generic mechanisms is that in Turret, the hypervisor

benefit of this design is that the User OS will not be executing while we process the hook, which provides stronger guarantees for the system.

3.4.4.3 Related Work: Page-Level Memory Trapping

The Turret framework provides for fine-grained active monitoring using hooks placed in- side the User VM. It also allows for active monitoring based on interposable hardware events in the Security VM. A related form of active monitoring allows the security appli- cation to set page-level trap events for User VM memory. This technique results in the security application being notified when the User VM accessing a given page a memory in a given way (e.g., accessing a page directory with write permissions). While not as fine- grained as placing hooks directly inside the User VM, this technique has the advantage of being easier to secure and easier to deploy across a wide variety of user operating systems. Page-level memory trapping has been demonstrated in the Ether malware analysis research project [50] and is available in VMSafe [173], a VMI library for VMWare products.

Page-level memory trapping could be easily integrated into the Turret framework. It would involve an additional change to the hypervisor, along with a supporting API within the Security VM. Once in place, it could serve as yet another active monitoring technique that could be leveraged by security applications.