In the rush to virtualise servers, IT managers must be aware of the potential system risks.
The argument for virtualisation as a security tool makes perfect sense: however it is delivered, malware generally attacks the underlying operating system. It installs software to carry out a malware writer's goals, which are largely criminal, consisting of spam distribution, password stealing, and account harvesting. But in a virtualised environment, the operating system becomes nothing more than a file - a movable, replaceable entity.
Operating systems in virtualised environments are delivered as virtual machines (VMs). If something goes wrong with the VM - if it gets compromised by malware, for example - then the idea is that it won't affect any other operating systems that you run atop that virtualised environment. If you're really worried about its security, you can remove it altogether and replace it with a fresh one, it's as simple as moving a file. This is the basis that many antivirus researchers work on, using a sacrificial VM that is replaced after it is infected.
Nevertheless, there are security worries. Isn't it possible that a piece of malware could punch through the underlying virtualisation platform, infecting the code underneath?
Worse still, could malicious code effectively virtualise the virtualisation platform, effectively controlling everything in a similar way that a rootkit can be used to 'own' an operating system?
Security researcher Joanna Rutkowska presented a proof of concept attack known as 'blue pill' in 2006, that she said virtualised an operating system and was undetectable. Others in the security community (including AMD, whose technology she used to engineer the attack) refuted this.
Still, Rutkowska and others have continued with such research, and this year she posited a new attack, focusing on hypervisors. Unlike operating system-hosted virtualisation - in which a virtualisation platform runs on top of a base operating system, and then concurrently runs a series of VMs - hypervisors do away with the operating system altogether, instead running on the 'bare metal'. There is then nothing between the hypervisor and the VM. Hypervisors are designed to be very small, consisting of minimal code, providing little more than a platform to control the operation of the VMs.
To demonstrate her theories Rutkowska chose Xen, the Open Source hypervisor commercialised by XenSource and then taken over last year by Citrix. The double-edged attack focused on planting rootkits directly in the hypervisor, and also on 'bluepilling' the hypervisor, in which a blue pill-style attack was run on top of the hypervisor to compromise VMs.
However, Martin Niemer, group manager for product marketing at VMware, the darling vendor of the virtualisation industry, calls this a largely philosophical debate: "We haven't seen anyone manipulating the hypervisor," he says. "People are thinking that it's possible, but there is technology in place to protect it." Such techniques include system timing measurements, and the use of instructions in the X86 architecture that work outside virtualisation.
Not according to Clive Longbottom, service director at industry watcher Quocirca. He thinks we should be using the trusted platform module (TPM) - an anti-tampering technology that uses secret keys, encoded at chip level, to prove that the state of software has not been changed.
"We have to start taking TPM more seriously, and software that sits well above it, like Openview, and other management tools have to be able to manage both the physical and the virtual environment, rather than having separate tools to manage each one," Longbottom maintains.
VMware does not take advantage of TPMs at present. Niemer calls it a good idea, but this cannot be something he has only just thought of; TPMs have been around for five years at least. Tom Rowan, security technical consultant at distributor Magirus, thinks that it's more to do with commercial than technical reasons. "It would restrict what machines you can run then hypervisor on and they already have a fairly strict hardware compatibilty list as it is," he reckons.
Instead, virtualisation companies are focusing on putting tools around the hypervisor to make it more secure, and relying on best practice. VMware offers an API called VMSafe that allows the traffic passing through the hypervisor to be controlled. It lets virtual machines run in privileged mode, taking input from other VMs, and monitoring their communications with the hypervisor. Anti-malware vendors are using VMSafe to enhance protection for VMs.
Back to basics
Niemer also says that certain basic measures can help to secure the system. "The issue is how a network is designed to run a hypervisor," he says, explaining that the firm's ESXi hypervisor should be on a separate network interface card connected to the management network, and should go nowhere near the production network.
That way, when an attack comes in over the production network, the attacker couldn't reach the management console. "What the attacker would see is the VM. They don't see the IP address of the hypervisor as this is on the management port and that isn't connected to the Internet," Neimer adds.
A nice idea in theory; in practice, things are rarely that simple, warns Rowan, who worries that the people responsible for implementing virtualisation may not always be sufficiently well versed in security. People set weak passwords. They design networks badly, or perhaps inadvertently subvert those designs (what happens if an errant admin sets up network access between his desktop and the administration console for convenience's sake?)
"And no-one is thinking about the advantage that these are just files. As soon as you start moving files around and manipulating them, then you have a problem," Rowan says. "What if someone got access to where you're storing the files, getting access to the data and stealing the copy? Virtualisation has its advantages, but from a security perspective there's a lot to be worried about."