“Mind the Gap!” – The Limitations of VM Introspection”

“Mind the Gap!” – The Limitations of VM Introspection”:

I was at VMWorld in Cannes in 2007 when VMware, having acquired Determina, claimed that through a process called “introspection” their hypervisor – the ascendant “data center OS” of the server world – could deliver insights that  would uniquely enable it to detect malware in a VM.  They later announced VMSafe – an API to permit security vendors to get access to this information (though to be honest the API really only provided only hooks into the virtual switch in the hypervisor).  On stage for the VMSafe announcement were the CTOs of the major endpoint security vendors, who while paying homage to this breakthrough must have been horrified to realize that VMware could (as it subsequently did) compete against them.  For a while the industry savored this glorious moment, foolishly imagining that the bad guys could be vanquished forever.
Fast forward five years to 2012: The security “ecosystem” around VMSafe is in full retreat: Whether because customers are not ready for it, or because operationalizing security in virtualized environments challenges existing enterprise practices, or because customers believe virtualized environments are inherently more secure, the “virtsec” category has thus far rather miserably failed to launch. This is not VMware’s fault:  At Citrix I worked with leading endpoint security vendors to help them ready their products for desktop virtualization, but even for the desktop use case – where endpoint security is clearly needed – adoption has been disappointing to say the least.
There is a huge gap between expectations and reality: To date there have been no reports of real-world deployments of introspection-based security solutions for virtualized endpoints.   Virtuata – a promising vendor that took advantage of the Xen® Introspection capabilities – was quietly acquired by Cisco before anyone learned much about it.  Intel/McAfee DeepSAFE, announced a year ago, represents the most comprehensive approach to date using introspection for the cause of security but their approach has yet to win broad approval.  DeepSAFE:

[… has] moved critical security processes into the hardware. This includes encryption, authentication, manageability and platform cleansing […]  DeepSAFE uses Intel VT to load a hypervisor before the OS, boot drivers, or other software.  This provides a vantage point on security well before any kernel mode root kit can get a foothold and subsequently hide malware.

Introspection is a nice idea, but  a hypervisor that introspects a traditional VM faces many severe challenges:

• A VM contains a full OS and one or more applications – comprising many processes and threads.  This leaves the hypervisor with a daunting task when trying to associate specific changes in the OS with specific applications, code, and causes. By way of example, when you insert a USB key into your PC, new device drivers are dynamically patched into the IDT– changing the kernel.   From the hypervisor’s perspective a code change in the kernel could be an attack, or could be legitimate, and it is nearly impossible to decide.
• The objects which cross the hypervisor/guest boundary are not semantically rich enough to assist in the identification of malware.  For example the hypervisor might see blocks being written to a virtual hard disk, or packets being sent to a virtual NIC.  The hypervisor  manages virtual memory, not OS or application data structures.  It’s view is too low level to assist the task of trying to identify malware.

These limitations are referred to as the “semantic gap” in the academic literature.  (Here are some additional pointers to recent research.)   Bromium has for the first time addressed this challenge. Micro-virtualization bridges the semantic gap with three new, powerful architectural capabilities:

• Micro-virtualization works at the task level.   The Microvisor hardware-isolates each vulnerable task in its own micro-VM, so the execution context and state within a micro-VM is unique to the task.  Moreover the specific task in any given micro-VM is known eg: a PDF renderer for a specific document , or an IE browser tab for a known URL.
• The constructs used by a micro-VM to access protected resources are semantically rich: The micro-VM will take a CPU-forced VM_EXIT when it attempts to save a file in its file system, resolve a DNS query, use the clipboard, or execute a new process, for example.  This task level information is extremely useful in malware analysis.
• Finally, because its architecture it protects the system by design, vSentry (which uses the Microvisor for introspection into micro-VMs) can dispense with the ball-and-chain that burdens today’s AV vendors – the need to detect in order to protect.
  
  • If detection is a pre-requisite for protection, then the system must detect early, to avoid compromise. Moreover since failure to detect is catastrophic, even slightly aberrant behavior must be regarded as a potential attack. And these combine to increase the chance of false alarms.
  • By allowing malware to execute to the point where it actually compromises the system (over-writing registry entries, kernel memory, a Windows file, or dropping and executing a payload) vSentry can spot malware with great accuracy – without false positives.

Whereas Introspection of traditional VMs is extremely difficult – perhaps impossible, its power is clear and applicability obvious in the context of micro-VMs.  Micro-virtualization offers the industry for the first time a very real opportunity to use hardware features to dramatically improve platform security.  With a simpler, less expansive use of virtualization – focused solely on security – it is possible to combine a powerful platform for insight into execution with a “protect first” architecture that blocks attacks by design.