Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I would like to know if it is save for the host system of a virtual machine (VM - VirtualBox OSE in my case) to execute malware.

Can a virus break out and read or write data from the host system? Can it establish an internet connection if I disable it in my VM?

Is a VM a safe environment to try to find out what a virus does?

Can a fork bomb "kill" the host system if I reduce the memory to about 1/4 of my total real memory? How much CPU-time can it use?

share|improve this question
add comment

4 Answers

up vote 16 down vote accepted

Theoretically, the guest system is totally isolated by the VM and cannot even "see" the host, let alone attack it; so the guest cannot break out of the VM. Of course, in practice, it has occasionally happened. An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM implementation or, possibly, the hardware features on which the VM builds on. There are few exit routes for data out of the VM; e.g., for Internet access, the VM is emulating a virtual network card, which deals only with the lowest level packets, not full TCP/IP -- thus, most IP-stack issues remain confined within the VM itself. So bugs leading to breakout from VM tend to remain rare occurrences.

There are some kinds of attacks against which VM are very effective, e.g. fork bombs. From the point of view of the host system, the VM is a single process. A fork bomb in the guest will bring to its knees the scheduler in the guest OS, but for the host this will be totally harmless. Similarly for memory: the VM emulates a physical machine with a given amount of RAM, and will need about that amount of "real" RAM to back it up efficiently. Regardless of what the guest does, the VM will never monopolize more RAM than that. (You still want to limit VM RAM size to, say, at most 1/2 of your physical RAM size, because the extra "real" RAM is handy for disk caching; and the host OS will want to use some, too.)

share|improve this answer
add comment

I have done quite a bit of malware experimentation within a VM - mostly using backtrack4 to break in from one host to the next. I'm a VMware Workstation user, primarily.

The largest issue comes from the possibility of the network connection of your VM transferring back to your host OS. You want to totally disable networking and / or use a network which has no access back to your host.

Limiting memory is a good best practice. I generally keep it to about a quarter, same as you. The CPU time is limited to either the number of cores or (if you have finer grained controls in your software) the percentage of CPU time defined for your specific VM.

Targeted attacks capable of breaking out of the virtual environment do exist and are commercially available - such as the cloudburst @Hendrick mentions - but are relatively rare. Keeping up to date on your virtualization patches is a very good idea.

See here, here, and here for details.

share|improve this answer
    
The other piece to be aware of is the use of VMWare tools, which are a standard method of communicating back to the host, through the virtualized hardware. This is just another path, and one I don't know of any vulns for off the top of my head. –  MToecker Nov 17 '11 at 23:05
    
Good point. I generally don't install VMware tools unless I have a defined need. –  Tim Brigham Nov 18 '11 at 0:58
1  
@MToecker, one path with VMWare tools is shared drives. If you have write access to files on the host machine from within the guest, so does any piece of malware. –  mikeazo Nov 18 '11 at 1:58
5  
What do you mean by "There has been no precedence to date for breaking through the virtualization layer"? Google finds Exploit in the shared folder implementation and Exploit in the graphic card simulation as the first two hits. I am sure that spending more than 2 minutes on a search will result in a lot more vulnerabilities. –  Hendrik Brummermann Nov 18 '11 at 7:17
    
The only things that I've seen have been in regards to the VMware tools. Thanks for bringing up the cloudburst stuff. I'll update accordingly. –  Tim Brigham Nov 18 '11 at 14:34
add comment

In addition to all the good information here about whether the virus can escape out of the VM, let me point out another issue to consider:

It is possible for malicious code to detect whether it is being executed inside a virtual machine or not. This often goes by the name virtual machine detection or "red pills", and there are many techniques available.

Moreover, some viruses and other malware use these techniques to detect whether they are being run in a VM, and if so, shut off their payload (avoid taking any malicious action). They do this to try to make life harder for folks to reverse-engineer the malware or detect it.

Consequently, a VM is not a good way to find out what a piece of malware does. The malware may not be able to break out of the VM, but at the same time, it might not do anything when it is running inside the VM. If you run it in the VM and see it does nothing, decide it is harmless, and then decide to run it outside the VM -- you could get owned. Be careful out there.

share|improve this answer
add comment

Disclaimer: I'm going for a relatively high-level understanding. If you want a detailed guide, that's out of scope. Additionally, there are other ways (entirely in software) to implement virtual machines to which this does not apply. I am also focusing on "breaking out" through the virtualisation mechanisms only - i.e. not ones that can happen PC-to-PC on actual hard networked hosts.

I like detail, so here we go with some. Firstly, codeproject has some excellent assembler references on the different modes of an x86 CPU (real, protected and long) and use of virtualisation. There's an Intel VT blog (I'm not sure if Intel write this) and lastly the first part of the Rootkit Arsenal is dedicated to explaining x86 and is an excellent read, complete with walkthroughs and nice diagrams. Understanding it all takes patience, so what I'll do here is to give a very brief introduction to how it works.

The way we rocked when we ran DOS

DOS and early 16-bit real mode systems operate a segmented memory model. There is no control over the size of segments and there are no protection switches on any of those segments. Code gets loaded into a segment of memory and it runs; it can far jump into other segments, so any code, anywhere can alter anything, including producing a TSR (terminate and stay resident) piece of code that simply points one of the IVT entries (interrupt vector table) at an address in its space, before executing the original. Basically, there is no protection. None. Nada.

The rise of 32-bit protected mode

Protected mode gets complicated quickly. There are three parts to it - segmentation, paging and PAE. Each requires a table of data that tells the CPU about that segment, page or helps it extend the address space (PAE). These include the famous ring flags (they apply to segments and pages) which implement process isolation. Paging is your way to load data out of RAM and onto disk and create fancy things like virtual memory (see, the word virtual! We're getting there!)

Long mode

Long mode does away with segmentation and simply mandates the PAE/Paging structures. Again, to totally trivialise implementing an OS, Paging is controlled by structures in memory which are then set up via special instructions. Voila, one can achieve process isolation with the right settings. Again, I'm trivialising slightly...

Give me virtualisation!

Okay. Virtualisation is the same general concept. Virtual machines are set up using virtual machine control structures which dictate how their memory is mapped back to physical memory, kinda like paging. Crucially, under certain conditions the virtual machine will be required to ask the host operating system for something, kinda like process isolation, kinda like a software interrupt. These are referred to VM exits and provide information to the host such as the state of registers on exit. Kinda just like a system call.

Can a piece of malware break out of a virtual machine?

So, as far as the VM is concerned, the host OS has all its own memory space and can be infected/damaged/destroyed as it pleases.

In terms of affecting the host memory directly, the virtual machine cannot, because it cannot see it. The host must map the required memory into the virtual machine space. It must also, in that memory space, implement everything from the BIOS up. In order to communicate with certain host devices for certain tasks, the host machine must set up those VM exit conditions and the target VM must trigger them. When that happens, control is transferred to the host.

There are, therefore, two possible at-risk areas:

  1. The actions the host takes in response to a VM exit. If there are any bugs in this handling it may be possible to persuade the host to execute something it shouldn't.
  2. Any host access to the guest machine's memory space. Remember the host machine code running in ring 0 can waltz in and crash the party wherever it so pleases. It just so happens that you can set the guest's memory from the guest (surprisingly).

This leads you to your exploit mechanism. You need a handling bug in the VM exit routine, then you need to be able to persuade that code to execute some memory, ideally code you just put into a page from the guest vm. Once done, say bye to Kansas.

As Tom Leek says, VMs are incredibly effective in defending against fork bombs. In a similar vein to the way the OS can limit how much memory a process can allocate, so it can limit how much memory is mapped to the VM. Run out and the guest OS believes it is out of physical memory; the host will not allocate it more unless you implement a VM exit to do this, which would be a bit dangerous and I do not believe this is done.

How likely is this?

Not very. It depends on those VM exit implementations entirely, or reading memory from the guest on the host with a nice bug in your reading code. It also requires that said bug would allow you to control the crash in such a way that you can force execution to the memory address your host holds. The VM exit must be able to access that memory.

What I have not covered?

  1. Attacks on existing software stacks such as TCPIP. The vulnerabilities here are the same as if you had two actual phsyical PCs anyway.
  2. Entirely software implemented virtualisation.
  3. Virtualisation on any other type of chip. This applies to Intel VT compatible setups.

Finally, I have previously argued that process isolation is a form of sandboxing. Reading that answer and this one, you should now be able to understand why I define them that way. There are remarkable similarities between process isolation and virtual machines in x86.

Update

So, I've dug around even more on this, especially into the blue pill research. What I've described is a very simplistic high level view. I've found more detail. Here's a whole paper dedicated to it from Invisible Things Lab. It turns out that their defences talk included the concept of denying execute access to user mode pages from ring 0, thereby preventing direct execution of data the virtual machine has placed into memory. It turns out this is being implemented in Intel CPUs and patches currently exist in the Linux Kernel. So, depending on how that goes, it may well be the case that attacks of this nature become much harder, even if exploits exist.

share|improve this answer
    
Great answer! Very helpful! –  D.W. Nov 19 '11 at 18:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.