How will microvirtualisation change the security field, if at all?

Question

Will this reduce the number of exploitable vulnerabilities in common operating systems? Will the only path in be to exploit the VM itself? Marketing blurb from Bromium's website below.

... transforms information and infrastructure protection with a revolutionary new architecture that isolates and defeats advanced threats targeting the corporate endpoint through web, email and documents. vSentry protects desktops without requiring patches or updates, defeating and automatically discarding malware, and eliminating costly remediation.

... uses hardware level isolation to stop even “undetectable” attacks without disrupting the user.

... built on ... a security-focused hypervisor that automatically, instantly and invisibly hardware-isolates each vulnerable Windows task in a micro-VM that cannot modify Windows or gain access to enterprise data or network infrastructure.

Answer 1

My name is Tal Klein and I'm a director of products at Bromium. I'm glad to see the discussion, but I'm sad to see so many people jumping to incorrect conclusions. I hope to answer the question here, but if you have follow-on questions let me know - we can use this thread to address them. We also have a bunch of blogs at blogs.bromium.com that dive deeper into our technology as well as our philosophy.

First: We don't isolate the browser, or any application for that matter. We isolate user tasks. That's an important premise to understand, and it's a bit tricky to think about because we're used to thinking about security in monolithic terms: Protecting the device, protecting the operating system, protecting the application, protecting the data, protecting the network, etc. - Today IT deploys a myriad of tools that try to address the security needs of their company, but all of them focus on some piece of the infrastructure, rather than on the things users actually do within and outside of that infrastructure. As some of the commentators on this thread astutely pointed out: Sandboxing the browser doesn't solve the problem. Not only is there the possibility that something breaks out of the sandbox, but it also allows attacks to persist from one browser tab to another. If I drop a keylogger when you visit site x, that keylogger is now in that sandbox and will get the credentials I type into site y (and don't get me started on cross-site scripting and man-in-the-browser attacks).

Our approach is to isolate every user task which we define as the most granular unit of computation, initiated on behalf of a user, that can completely and successfully execute with the least possible resource access. Resources here mean files, network services, sharing mechanisms, interaction with the user, or any devices. A good example of this is url redirects, like bit.ly or t.co - if I only sandbox the browser, or even just the tab, an attack that starts on one of the hops I'm being redirected through can follow me to my destination. For us that's unacceptable. We will create a micro-VM for each redirect until I reach my final destination. Then if I click away from there or close the tab, then that micro-VM is destroyed and a new one is created for whatever my next task may be.

Our micro-VM's are particularly sturdier than sandboxes. The single biggest difference between micro-virtualization and sandboxing is that the latter is a software-based approach, whereas micro-virtualization relies on hardware isolation. This can be stated thus: “If the software sandbox is compromised (eg: thus), what protections remain?” For all sandboxes, the answer is “the standard OS protections”. For micro-virtualization the answer is “virtualization hardware, the Microvisor and standard OS protections”. More succinctly: software sandboxed applications are a good idea. You ought to protect them using micro-virtualization.

Sandboxes aim to isolate an application (typically a process) from other applications and the OS kernel, whereas micro-virtualization isolates tasks from each other and the rest of the system. A task includes all user space and kernel execution for the isolated code. This is crucial to the vSentry protection model: If malware escapes into the kernel via a zero-day it will still be completely contained, whereas a zero-day escape from a sandbox leads to complete compromise of the system.

Applications often have to be adapted in some way to run in a sandbox – for example through vendor-specific implementations, installing the application in the sandbox, re-linking or re-packaging the app (eg: App-V, which serves app-delivery needs and is not intended for security). Micro-VMs can run any application natively – the application / OS interface is not modified in any way.

Who’s sharing your sandbox? Applications that interact with each other need to be co-resident in the same sandbox, leaving one application vulnerable to a successful compromise of another. For example a key-logger that compromises the browser will also have access to any other application that cohabits the sandbox, such as the email client.

Granularity: Sandboxes contain entire applications, such as the browser. A compromise from one malicious site can therefore follow the user to all other websites visited. By contrast, micro-VMs are used to isolate arbitrarily granular sub-application entities such as individual sites in a browser, or documents in Word or Excel. We aim to make it impossible for a single compromised task to compromise any other activity on the desktop. The vulnerability of any system is proportional to its code size. To protect the OS from a malicious process a sandbox must to limit access to the entire system call interface and to any other mechanisms (COM, OLE, clipboard) that can be used for IPC or to gain access to OS services. By way of example, the Chrome browser counts about 5 MLOC, of which about 1 MLOC are for the Webkit renderer. The isolation layer between OS and process is of O(1 MLOC).

More code = more vulnerabilities. Humans leave bugs. Sandboxing is a dream. Complex code interfaces can be inadvertently broken by OS patches Better sandboxes are typically less general purpose – for example Chrome’s, which will only ever serve the Chrome browser but after 12 years of development is certainly the best More general purpose sandboxes such as Sandboxie are invasive of the user experience, and change OS semantics (eg: saving downloaded files from a browser sandbox session requires the user to specially copy them, and applications that interact need to cohabit the same sandbox). They tend to have more limitations than application-specific sandboxes. vSentry adds a tiny amount of (untrusted) code to standard OS service interfaces (eg: file system filter drivers) and instead relies on Intel VT to do the hard work of isolation: It is impossible for a micro-VM to access any controlled system resource (its files, network services, devices, clipboard) or interact with the user at the keyboard without being stopped by hardware (a VM_EXIT), whereupon the Microvisor is given the CPU to implement mandatory access control.

Perhaps as importantly, the resource view from within the micro-VM is task-specific and implements the principle of least privilege: The PDF renderer only has one file: the PDF document it needs to render; it can’t turn on the webcam, or access the enterprise network or any enterprise data.

Bottom line on sandboxing vs micro-VM's: Humans write bad code, even when they are writing sandboxes. Sandboxing is a useful approach, but it won’t save you. Hardware based isolation is the only approach that minimizes the vulnerability surface, and micro-virtualization protects you even when malware escapes and takes advantage of a zero day.

Lastly, there is the end-user experience. We do all of the above without requiring the end-user to change contexts. At the end of the day any security solution that gets in the user's way either numbs the user to the threat (have you ever clicked on anything but "Yes" on a Windows UAC alert?) or drives the user to circumvent IT infrastructure in search of productivity (Shadow IT/Consumerization). Our approach significantly decreases the attack surface of the endpoint (and along with it corporate infrastructure) without changing the end-user experience. That is what we mean when we say "a desktop that is utterly secure and a joy to use."

Answer 2

Isolating the browser in a specific jail that it cannot escape is meant to contain damage: if the browser is hijacked, at least the attacker will not obtain immediate access to the rest of the machine. However, whoever hijacks a Web browser can do everything that the Web browser normally does, including accessing your Web secrets (cookies, stored passwords), grabbing everything you type in the browser (including passwords on Web sites), and contacting arbitrary external servers. Everything you do through the browser is then at risk, and, nowadays, this is probably most of what you do at all with your computer.

In other words, the sandbox provided by Bromium protects everything, except that which is essential. It is not bad, at least conceptually, but it would be a mistake to believe that it makes everything safe.

The best that Bromium can achieve is the software equivalent of having a specific, dedicated, air-gapped machine for Web browsing -- and that's assuming that the isolation layer is "perfect", which is a bold claim. Also, this is inconvenient: when you browse the Web, you sometimes want to, e.g., save files locally and then use them. A useful jail necessarily includes some doors, which are, inherently, ways to escape the jail.

As a corollary, this will not change much the security industry.

Answer 3

It's like Sandboxie, but with better isolation, implemented using hardware virtualization extensions inside CPU. You can already achieve the same effect if you run each application in its own VM and use Unity mode to have all application windows on the same desktop. It seems Bromium solution will simplify this and make it easier to use. There are many advanced security features that would prevent or severely limit breaches in security, but they are not used by the majority of system administrators. Examples are Sandboxie, AppLocker, EMET and tightly configured application firewall. Based on that fact, I don't think Bromium will change the security of majority of computers. IMO, it will only be used in places where security is paramount and with competent IT administrators. At the same time, I think we will see something similar integrated into future versions of operating systems, but not anytime soon.

Answer 4

Y'know I've heard a lot about how virtualization will just fix things. It annoys me a tad - because it's just using the word "virtual" to say "oh it's not real so you can do no damage". Extending from Thomas's answer, then:

Preliminaries

The x86 architecture already features an application isolation mechanism called privilege levels which determine what applications can access. No doubt you've heard of ring 0 and ring 3? Well, ring 0 is allowed to modify virtual memory, configure the processor etc. Ring 3 can't. However - yes, you've guessed it, there are two other rings, ring 1 and ring 2, and they remain unused for most operating systems, including Windows.

What does this get us?

Every ring 3 application, hereafter called userland, can do absolutely nothing much useful on its own. It needs the operating system to talk to hardware, to save files, to access the internet and so on.

As such, every executing application in userland must pass through the kernel on its way to greater glory. This allows the kernel to implement access control, to decide what applications can or cannot do.

Applications in userland are also isolated from each other - except by asking the kernel for connections to other applications. Again, this allows for access control.

What we have, as is then, is an isolation strategy for applications. It's simple: they each believe they have their own address space, they each can only persuade the kernel to do things if they have permission to do so.

How does virtualization of the hardware variety work in a security context?

Essentially by multiplexing the processor. Is that even a word? Probably not. Ok, basically, you set up a number of virtual CPUs by setting up their respective tables in the processor, then you press go. You get to map memory just as you do for applications, so you can map new, blank space - or existing space.

The long and the short of this is that it is possible to map an existing operating system into a new virtual machine, You can then do the Linux of equivalent MAP_PRIVATE; that is, these pages are copy on write. If anything writes back to this VM, you duplicate it, hold it whilst working and discard it when done.

What does this mean? Well, your userland application might trigger lots of other things to happen, such as royally destroying the system. But that's ok, since all this happened inside a copy on write simulated version of the OS - so you've just installed a fancy rootkit in something that's... whoops, sorry chaps, closed the browser and the vm went with it.

Right, great, but I've decided I actually want this file to persist because I like this pictcha of a kitty. So how does your fangle dangle vm thing handle that?

Fundamentally, it comes down to this: somewhere, some part of the system must be trusted, and some applications must be authorised to talk to it. It (the trusted part) must make some access control decisions and decide what to allow and what to deny.

Wait, doesn't the kernel already do that?

Yep. fundamentally, you still have the problem of access control.

Access control... problem?

One of the major complaints against systems such as SELinux is their complexity. These systems offer rules and configurations that control the implementation details of the OS to a fine grained level, far beyond what traditional DAC-like systems do. And this is complicated - especially in terms of knowing what should and should not be allowed. This problem extends to the simpler DAC/RBAC model - it's really very difficult to ensure all permissions everywhere reflect what you intended to allow and do not cause a security breach.

The other issue with access control is privilege escalation. In short, this occurs when something you have trusted can be exploited to do arbitrary things based on untrusted input: typically launching a process as an administrative role. If you require trust of this component, and yet this component leaves you vulnerable, you have potentially introduced an exploit that even with a virtualization communication layer thing will not help, since this component is trusted in all it does.

Ok, so aside from getting the security policy/access to the securo-visor thingy right, what else might be a problem?

• Hypervisors don't currently nest, at least not in a way that gives you acceptable performance. VMware's hypervisor will nest, but it's about the only one that will (at the time of writing and that I know of). Essentially, this means no virtualisation for you, cause bromie stole your vmm.
• In practise, large complex pieces of third party software can't be operated day to day in sandbox throw away when done mode, because users expect their cookies to persist. They expect their history to persist. They want to save files. AND THEY WANT TO BE SAFE TOO, DAMMIT! This means some form of integration with the third party software, e.g. the browser - and this means knowing about it and keeping up. In practise, end users don't like waiting too long for the latest and greatest, especially if the delay reason is just to keep them safe (cause hey, who wants that anyway). Thomas has essentially said the same thing here, I'm just repeating it.
• There is a lot of software to customise like this. That, or the system will be mostly unusable for anything interesting.
• Some stuff just doesn't lend itself well to this type of thing. Imagine how much pain would be involved in isolating say Visual Studio. Don't, and it's another attack vector. Do, and you've got to make damn certain you can still debug everything VS could...
• You still don't prevent social engineering, XSS etc (again, Thomas).

Conclusions

• We already use virtualization of the address space with access control for our standard security model. It would actually be possible to produce COW snapshots of an OS using existing, unvirtualised OSes, but performance means nobody would, in practise, do this.
• CPU virtualization doesn't aid security. It's the memory mapping OS clone technique which does. Fundamentally, it's a von neumann architecture. Memory is king.
• Access control and what we trust (and how much) remain problems.
• It's not massively user friendly. This is a perennial enemy to security, but in this case the trade off is likely to be huge to make the system work.

Will micro-virtualisation affect security in any way?

No. Access control is still a hard problem regardless of how you enforce the boundaries.

---

Further notes

• Ring 1 and Ring 2 usage would make an awful lot of sense. Not being able to alter critical structures, or run privileged commands, would prevent many rootkit techniques from working well. Unfortunately, x86 and a handful of other architectures were the only ones providing these four modes - ARM processors, for example, only offer supervisor and user modes (ring 0/ring 3 in x86 terms). So operating systems that strive for portability can't make use of the other rings.
• The memory mapping technique to run an OS inside a hypervisor is the technique behind blue pill. Specifically, I am referring to on the fly remapping the running OS to a VM. You can also just boot the hypervisor first. SubVirt did this at the time.
• SELinux and the like fall down when they have to start protecting things like X. Which, urgh, runs as root and lets applications communicate with each other and is therefore a gaping security issue potentially. X.org has published XACE which is to X as LSM is to Linux; that is, it lets plugin writers build a security framework. Again, however, you have the problem of complexity. This is a good example of where a security policy cannot be applied to a large working application clearly.
• If you put the word "cyber" in front of it, it actually makes it the solution to life, the universe and everything.

Answer 5

This really falls under the concept of defense in depth. To a greater or lesser extend, this kind of thing has been used for some time, just the isolation provided keeps improving. This is effectively an extension of the idea of sandboxing plugins and JavaScript in browsers to prevent abuse. To add another layer of defense, they are running the browser application itself in a VM. This is something that security researchers have frequently done for a while to make easy to build and analyze systems that they can intentionally allow to be compromised and easily blow away any changes that were made, simply by not saving the changes from a particular session back to the virtual hard disk on the host.

It still isn't a foolproof means of protection as there do exist tricks for escaping from a virtual machine and accessing the host, but it provides another level of protection since not only does an attacker have to bypass the browser's security, but they also have to bypass the protection of the VM to get to the host.

This is also where virtualization gets interesting because for virtualization to be the most effective as a security tool, it needs to isolate the process from information that it shouldn't be able to access. The idea is that anything in the VM is considered untrusted, but then, sometimes, the VM needs access to information that would be trusted (such as stored passwords, browser history etc.)

The options are to either put the data within a VM as something that would be compromised if the VM is compromised (which doesn't add any security for that data) or it can be put outside the VM and requested by it. The problem is, the more ways you make for the VM to talk to the host, the more potential ways the host can be compromised by the VM, so the traditional usability vs security dynamic stays the same too.