In a previous post I highlighted recent insights from Gartner on a new approach to security, namely execution isolation for untrusted code or data. I described how the hardware-enforced isolation of individual tasks by the Bromium Microvisor offers the most robust possible protection against malware: To break it you effectively need to break the CPU.

A core issue, highlighted by Neil MacDonald, is that different technologies afford different granularity of execution isolation. At opposite ends of the hardware-isolation spectrum are traditional VMs (each with an OS and its apps), and micro-VMs (each of which contains only a single user task). Neil also highlights sandboxing, which uses software to isolate an executing application, to protect the OS kernel from attack.

In this post I aim to provide the rationale for our choice of a user-task (an activity initiated by the user) as the execution construct that should be isolated, both to maximize security and to deliver a compelling end-user experience.

If you’re a security geek and want the cliff notes: The Microvisor implements a Least Privilege Separation Kernel (LPSK) between untrusted tasks and the desktop OS. It is the only Separation Kernel of which I’m aware that takes advantage of the tiny code-base of a security-specialized hypervisor to dynamically apply Least Privilege [versus statically] at a granular level between tasks within a single running OS instance. It relies principally on hardware-isolation for tasks because this offers the most robust barrier to any attack. Finally, it is the first general purpose Separation Kernel that can protect existing, widely deployed OSes and their applications, and that can be deployed and managed using today’s management tools (SCCM, AD or a security console like McAfee ePO).

Our goal is to identify what execution constructto isolate (OS, application, or perhaps even a thread) in order to maximize security and deliver an optimal end-user experience.

Unfortunately neither hypervisor-based OS virtualization nor application sandboxing can adequately secure an endpoint during execution: (Note: it is not my intention to criticize vendors, their products or their legitimate use cases. This classification is solely from the perspective of their ability to offer run-time protection through isolation, in response to Neil MacDonald’s research note)

An alternative approach is to run each vulnerable application in its own VM, and use graphical “tricks” to make the VM appear to be a normal application (eg: Microsoft MED-V (used for app compatibility), Qubes OS, and early versions of Invincea). This approach is complex to manage, and also doesn’t solve the security problem: If my browser VM is compromised when I click on a bad site, then when I navigate to my bank, my session is vulnerable to attack.

Application isolation is another approach. Sandboxing is frequently used to protect the OS kernel from a malicious or compromised application– for example a browser. Of course in this case the isolation is software based, but let’s assume that it, in combination with other software protection mechanisms are as robust as hardware isolation (One can conceive of application isolation approaches that use VT.
For example, see Microsoft Research Drawbridge which may be relevant in future OSes. But using today’s technology, let’s assume we use every process isolation technique at once: IE and its sandbox on top of an OS improvement sandbox such as Sandboxie, further strengthened by Microsoft EMET (a powerful free ASLR tool) and running on a system with the full complement of legacy endpoint protection).Unfortunately, as my colleagues Rahul Kashyap and Rafal Wojtczuk demonstrated this year at Black Hat Europe and this week at InfoSec Europe, if a malicious application compromises the kernel directly (without needing to jump from user space into the kernel) it can compromise the entire system – bypassing all protection. For example on an unpatched Windows desktop, navigating to a web site that causes the kernel to parse a poisoned font file on behalf of the browser is sufficient. And there is a long and growing list of kernel CVEs.

This is a huge “gotcha” – neither application sandboxes (eg: Adobe, Microsoft, Google) nor OS improvement sandboxes (Invincea, Sandboxie, Trustware Bufferzone, ZeroVulnerabilityLabs) can block such attacks. Once again, this is not a criticism: These are powerful technologies that substantially improve system security, but this attack completely bypasses them, and so they are unable to meet our requirement for rigorous isolation of untrusted tasks.

What can we conclude from this? Well, we must assume that the OS kernel will be compromised by a malicious task, so if we are to isolate its computation, we must also isolate all of its kernel activity. Sandboxing is a non-starter. But VM’s can’t solve this problem either.

In the Bromium architecture, the Microvisor hardware-isolates both user-space and kernel activity of each untrusted task. But note that the moment we start to talk about kernel activity, we need to recognize that a kernel compromise will expose all system resources controlled by the kernel, so somehow we need to extend the isolation to include all task-relevant, kernel controlled resources.

Remember that we need to assume that an attack will occur, and that any part of the system, including the kernel, will be compromised. When this occurs the set of system resources available (visible to, and accessible by) the task must be minimal – and indeed must not permit the attacker to succeed in any way – stealing valuable information, or penetrating into an enterprise network.

We identify the boundaries of a task and the minimal set of resources it needs based on the well understood concept of “Need to Know“, (also called the Principle of Least Privilege). Least Privilege dictates the minimum set of system resources (network, file system, desktop) that any task requires to work correctly: For example, in the context of the browser, a task is an application context defined by a site (its TLD), so each browser tab is a different task.

What resources does facebook.com really need? It needs its cookie, and access to the untrusted web. If the browser tab for facebook.com is compromised (say the user clicks on a poisoned advertisement), we can tolerate loss of the cookie. We can live with the fact that malware will have access to the untrusted Internet. The system will still be safe if:

The malware cannot see any user keystrokes, mouse input or gain access to the screen (to steal pixels from the display, or display content to the user).

The malware cannot access any files other than the Facebook cookie

The malware cannot gain access to any valuable networks or sites (eg: SaaS sites, or the Intranet).

The malware cannot gain access to any devices (for example – it cannot turn on the webcam)

But what about a user who wants to upload a photograph to Facebook? Dynamic application of Least Privilege is the key to delivering an unchanged, compelling user experience whilst maintaining security. As an untrusted application, facebook.com must only have access to its cookie and the web. But if the application logic of Facebook dynamically requests access to additional resources (eg: user clicks on “upload a file”), the Microvisor can decide to grant access to an additional resource, in a granular fashion- but only under precise policy control (Dynamic LP), and with the explicit involvement of the user, and only for the minimum duration necessary. For example (there are many more, but the key take-away is that we can deliver an unchanged user experience whilst dynamically enforcing LP):

If the user wants to upload a photo to Facebook, she can select the photo (in the usual way) on the desktop, and then (only) the selected file will be injected into the hardware-isolated task for the facebook.com browser tab.

If the user wants to download a file, it can be allowed to persist outside the confines of the isolated task, but only if we remember the fact that it is untrusted, so that it can only ever be accessed in another hardware-isolated task.

It uses Intel VT to hardware-isolate task execution of both user-space and kernel activity, but unlike hypervisor-based virtualization, it does not need to virtualize device hardware, which is controlled by the desktop kernel.

Instead, it virtualizes access to all shared system resources in such a way as to enforce mutual isolation of all tasks and the desktop, using interfaces and primitives that are task-relevant. They include the file system, registry, network services, and desktop services such as the clipboard, display, and user input. The isolation is achieved using light-weight “task-level enlightenments” that build on standard OS APIs.

Execution is non-persistent: all changes (to any system resource) made by a task during execution are saved in an ephemeral, throw-away cache that is discarded as soon as the user terminates the task.

Summary

Micro-virtualization is the only technology that can dynamically isolate all untrusted activity of an application at a granular level, protecting the system even when the kernel is attacked.

Its incredible robustness results from hardware-isolated execution, the “throw-away cache” of all changes, and granular, dynamic application of the principle of least privilege to ensure that no data, networks, devices or user activity of value is exposed in the context of untrusted execution.

Micro-virtualization can be straightforwardly applied to today’s deployed OSes and applications on any modern PC or server.