Security in the World of Virtual Machines and Containers

Running an app in a VM in a public cloud may indeed be more secure than running the same app in a container, but that doesn't always mean you can sleep well at night knowing your apps and data are secure.

Let's talk about security in the world of virtual machines and their lightweight little brothers, containers. A virtual machine is more secure than a container, because a virtual machine offers more isolation. So they say.

And it's probably true, because an application running in a VM has its own operating system and is a self-contained unit running on the physical host.

Meanwhile, a containerized application enjoys no such self-containment. Instead it shares the host's kernel, and there's always the worry that a container process might escape into the host's kernelspace.

So if we put an application in a virtual machine in the cloud, nothing can go wrong, right?

Well, not exactly. There are a number of things that can go wrong, including:

VM Hopping: That's when the owner of one virtual machine figures out how to attack another guest machine on the same hypervisor

VM DoS: Just as it sounds, this involves a malicious guest administrator crashing the host machine and other guests' VMs from a guest VM

VM Escape: That's when a malicious guest VM user gains control of the underlying host

These days, with public cloud services offering machines that can be spun up and put to use in seconds, it's tempting to ignore the fact that there are security risks involved with any shared environment.

It may sound old-fashioned and a bit stick-in-the-mud to talk about the risks of running your business from servers in the cloud, but the security risks are real.

And this is nothing new. As far back as 2010 this column talked to Jonathan Brossard, then CTO of P1 Code Security (and now a security bigwig at Salesforce.com) and self-styled "alien with extraordinary ability in computer hacking."

Brossard said that as long as virtual machines from different customers are hosted on the same hardware, getting a shell on the same host machine as a given target is just a matter of paying a few dollars a month.

"This means you don't have to worry about finding a remote exploit. Sharing is very interesting if you are malicious, because then seemingly minor local bugs do matter: virtualization amplifies the consequences. Owning the host from the guest is practical, so security through virtualization is a failure," claimed Brossard.

Virtual machine security remains a challenge

Of course that was then and this is now. Virtualization has gotten a lot more sophisticated since then.

But as we know, security bugs never disappear. Some may be fixed, but others get introduced.

So it's no huge surprise that a major bug has just been publicized in Xen, a server virtualization hypervisor that's particularly popular with large cloud service providers.

And the bug is pretty bad, as it allows VM escape, which enables a malicious guest administrator to escalate their privileges to that of the host, and it affects all versions of the Xen hypervisor.

The good news — if it can be called that — is that the virtual machine security vulnerability is only exposed to paravirtualized guests running on x86 hardware, not to fully virtualized x86 guests (or ARM guests).

In Xen Security Advisory CVE-2016-6528 the Xenproject.org Security Team describes the problem like this: "The PV pagetable code has fast-paths for making updates to pre-existing pagetable entries, to skip expensive re-validation in safe cases (e.g. clearing only Access/Dirty bits). The bits considered safe were too broad, and not actually safe."

The problematic shortcut has been fixed with a patch for Xen versions 4.3.x and upwards, which was distributed before the issue was publicized.

Now no one should suggest the Xen developers don't know what they are doing: building a hypervisor is no trivial task, and bugs are inevitable — in hypervisors just as much as in operating systems and in applications. Maybe more so given the level of complexity involved.

So this little episode should stand as a timely reminder that while it may well be the case that running an application in a virtual machine in a public cloud is more secure than running the same application in a container, that's not the end of the security story.

If you're in a shared environment, you're also introducing new risks when you virtualize. That means Brossard's virtual machine security conclusion back in 2010 still holds true today.

"Adding layers of virtualization is actually a bad idea that can lead to exploitability," he pointed out. "The best way to get secure software is to properly test it for security bugs."

Paul Rubens is a technology journalist and contributor to ServerWatch, EnterpriseNetworkingPlanet and EnterpriseMobileToday. He has also covered technology for international newspapers and magazines including The Economist and The Financial Times since 1991.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.