Virtualization – the promised land?

By Paladion

June 15, 2007

Someone somewhere is still getting compromised after investing a lot in security. Now there's something called 'virtualization' which seems to be some kind of a promised land – a 'solution' to all these security problems. It’s being adopted rapidly across multiple organizations just because its 'secure'. So what is virtualization? Why is it such a craze? Is it really that secure? Is there no way to compromise it? Are we finally 100% safe? A lot of pertinent questions there – let's try and answer them, shall we?

A magic bullet?

Someone somewhere is still getting compromised after investing a lot in security. Now there's something called 'virtualization' which seems to be some kind of a promised land – a 'solution' to all these security problems. It’s being adopted rapidly across multiple organizations just because its 'secure'. So what is virtualization? Why is it such a craze? Is it really that secure? Is there no way to compromise it? Are we finally 100% safe? A lot of pertinent questions there – let's try and answer them, shall we?

So what is virtualization?

The term virtual itself means something which simulates what is real ; something which you wouldn't know was not real if you used it. That's what virtualization is as well. You can install an entire OS inside a virtual machine and set it to open in “full screen mode” each time you want to use it (The same way you watch those movies on your computer – always in full screen mode). Once its booted up and your friend pops in to use your machine there's no way he'll ever know that he was accessing his email through a virtual machine (VM) -- lets call this the Guest OS -- and not the actual OS (Host OS). So all we need is, for example: A Windows box as your desktop, the virtualization software installed on it and Linux, Solaris and any other OS's you use installed inside the software (Images).

Now that we're clear what a VM is and what its uses are, lets look at how its used by the IT community and why its being so talked about in the security community. Different people use a VM for different reasons: training , testing code, isolating key DMZ Servers, R&D and much more. However we'll look at a VM just from a security standpoint. Let's try and figure out how a VM keeps malware at bay, how it keeps viruses and worms from spreading.

Malware – On a normal system

So how does normal malware behave? One of the most common scenarios is as follows:

  • User clicks on link in Email
  • User taken to/redirected to a “Free software download” page
  • User downloads beta version of the latest game
  • User also unknowingly downloads, unpacks and installs malware packaged with the game

The malware now depending on how it was written usually does one of the following:

  • Duplicates itself on the user's system and starts spreading itself to other systems
  • Installs itself on to the user's computer and uses it to host pornography, illegal software or maybe even use it as a platform for a DDOS attack
  • Installs itself on to user's computer, loads at startup and captures user's personal information and sends it to an attacker

So how do you normally counter malware? You keep your operating system and all installed software updated with the latest vendor patches, turn off needless services, kept your anti virus definitions updated, do not visit suspicious websites or links and have a host based packet based/program controlling firewall to regulate access. Yeah, right, we all know how easy that is!  Enter the VM to help you out.

Malware – In a virtual machine

A VM is an OS inside an OS. The only difference is – its isolated from the host OS completely. Lets look at how a VM works a bit more closely. Here's how a standard VM architecture is:

The VM simulates the exact working of the underlying hardware its running on. This means that whatever the user does inside the Guest OS, he's actually using the RAM,Processor and N/w card of the host. The VMM (actually the VM Driver) gives as much control as possible to the Guest OS user. If however the Guest OS performs an operation that'll affect the Host OS the VMM driver will step in and ensure that the Host OS remains completely unaffected. So for example: If there's some virus you caught while inside the VMM and it was programmed to reboot the machine, just the Guest OS would get rebooted. The Host OS is completely unaffected by the virus. The best part is – to get back to a clean Guest OS you just need to point the software to a clean uncorrupted image.

There are 3 types of virtualization which are widely used in commercial as well as open source products. They are: Full virtualization, Paravirtualization, Hardware based virtualization. We'll only take a detailed look at Full virtualization here and just touch on the other two.

Full virtualization

The Guest OS isn't modified at all in full virtualization. All communication between the Guest OS and Hardware passes through the VMM. Now there's a component called the Hypervisor which is what is actually responsible for the Guest OS remaining isolated but still able to talk to the Host OS. The Guest OS uses the VM Driver to speak to the Hypervisor which decides which GuestOS operation must be permitted to execute directly on the Hardware. What do we mean by “permitted”? The VMAPP or the GuestOS runs in user mode while the VMM or the VM Driver runs in privileged mode. Think of it this way:

GuestOS = Normal User
VMM = Administrator

which now means that a VMM can access memory addresses that a VMAPP cannot. Now the responsibility of actually implementing user mode and privileged mode lies with the processor. So a processor must:

  1. Have something in place which limits the VM to its allocated address space and not let it write anywhere else.
  2. Should be able to tell the VMM(VM Driver) that the VM(VMApp) has tried to execute a sensitive instruction (Attempted change to privileged mode, Trying to access sensitive locations outside the addresses allocated to it, All I/O instructions).
  3. In the event that a VM does execute sensitive instructions the processor should immediately shift control from the VMApp to the VMM. The VMM should then be allowed to simulate the sensitive instructions.

Now the Pentium architecture addresses these concerns as follows:

  1. Limit VM to allocated address space:
    It uses a concept of “address segmentation” to divide the available address space into “protected address spaces”. So this means that the Windows, Solaris and Mandrake VM's running simultaneously on my machine all get separate address spaces. What's even better is that each segment now gets assigned a DPL(Descriptor privilege level 0(most powerful) – 3(least powerful)) which decide what they can access or not. All VM's get a DPL of 3. So this means that if I'm disassembling this new complex multi-platform worm on my Windows VM there is no way its going to spread to my underlying Fedora Core 5 machine or my Solaris and Mandrake VM's I'm running. The DPL will not allow it to do so.
  1. VMApp executed sensitive instruction and the control shift to the VMM:
    17 instructions of the Pentium were in the year 2000 classified as sensitive and unprivileged. This meant that the processor directly executed these instructions and there was no way these instructions could be simulated on the VMM. So any code which used these instructions could not run in a VM. This might well have changed in newer architectures , we're not really sure though.

So this effectively means that if malware affects my Guest OS, its effects are going to remain restricted to that VM only. That's because it cannot access the address spaces of other VM's or the Host  OS.


It is a technique that presents a software interface to VM's that is similar but not identical to that of the underlying hardware. So if I have a Fedora Core 5 box and want to run a Suse Linux VM I'd need to configure Suse so it used the functions of the “paravirtualized software interface” instead of the actual OS system calls. This is actually a bit hard to do for all OS's but there are numerous OS's which have already been modifed so that they can run in such an environment. It's even possible to run a proprietary guest Windows OS on specific architectures. From a security perspective an operating system that runs the paravirtualized system as host is also known as domain number 0 (dom0), while a system that runs as a guest is known as the unprivileged domain (dom1). Dom0 has direct access while dom1 accesses sensitive instructions through dom0.

Hardware Based Virtualization

This is used on specific platforms only. In such systems the guest OS can be ported without it being modified at all. I know I haven't spoken too much about the other 2 types of virtualization but that's because its way beyond the scope of this article. This article was just to tell you about why virtualization is such a key concept now, how a generic virtualization system works and why its a secure alternative if implemented properly.

The crackers fight back

The cracker community obviously understand that virtualization prevents them from spreading their viruses and worms. So now they've started coming up with techniques which first detect whether they're running inside a VM or not. There are 2 primary approaches that they use:

Direct hardware fingerprinting

If there's a program inside your VM that can query your OS for the motherboard make, and you get an answer saying “Microsoft Corporation” you're quite obviously inside a Virtual environment. That's because Microsoft doesn't manufacture motherboards. Virtual Machines have predictable hardware profiles, so you can just query for "virtual hardware" that's only available in VM's and can't easily be changed.

Indirect hardware fingerprinting

Remember we spoke about those 17 instructions which couldn't be emulated by a VM. Guess what?? If you can write code which emulates some of those and the code runs you're probably on a real system. If it doesn't run then you're inside a virtual machine. This is very complex to do but if it's possible then you can rest assure that someone out there is trying to do this. In fact there have been plenty of theories (as of now) on how to achieve this. I'll give you some links to look at in the Reference section.


Virtualization is an excellent technology if you're testing things. Its probably most widely used for Malware analysis though corporates are nowadays buying just 1 high end server fitted with truckloads of RAM and running their applications and even domain controllers in virtualized environments. VMWare is the most popular virtualization software that's used right now – it uses the full virtualization approach. The Open Source community is associated with Xen – and it used a Paravirtualization approach. However rest assured, please do not treat it as a magic bullet. It is only as secure as your host OS itself.

So those good old best practices of defense in depth still stand. Well written security policies, secure rulebases, monitoring, LAN segregation – all those are still very much the key to a relatively secure environment. But virtualization does give you that extra layer of security – for now. There have been exploits on these products as well but they are relatively few. So as long as you implement VM's well and don't leave Guest OS images around loosely, virtualization is great and very useful.

I think I've touched on too many things in one article and not gone too deep into anything thus leaving you unsatisfied. My apologies for that – but its hard to cover every single detail in a five-pager, specially on a subject as vast as this. Maybe someday later I'll go a bit deeper into the technology and we could take a look at how exactly we could handle the problems of virtualization. Hope you enjoyed this introductory article though.


  1. Virtualization - Wikipedia
  2. VMM-usenix00-0611
  3. Virtualizing I/O Devices on VMware Workstation's Hosted Virtual Machine Monitor
  4. Red Pill... or how to detect VMM using (almost) one CPU instruction
  5. A Choices Hypervisor on the ARM architecture
  6. VMware Multiple Denial Of Service Vulnerabilities
  7. Can Operating Systems tell if they're running in a Virtual Machine?

Tags: Features