It's possible to break out of a VM and execute onto the host machine which is usually version and software specific so the scope of this actual attack but as I'm sure you'll of guessed it's very low possibility but not to be overlooked.
If you're very paranoid and want the most secure then no software can offer you full isolation. Use a physical computer which doesn't have access to any device which is capable of outputting any signals to any remote devices.
If using a physical machine isn't possible then yeah, VM is the best solution. Just ensure you restrict the user you execute the actual VM under doesn't have more permissions (DACLs etc) that it actually requires to minimise the security risk of malware executing outside of the VM.
Edit:
Sorry, I misread what the OP was asking for. Nether the less I'll leave above answer if any is doing the reverse.
With that been said, of course it's possible to break into a VM. I use Visual Studio which is a programming IDE and there is a VMWare plugin which you can debug your software into running VMs which is created by VMWare. So, if VMWare Plugin can see all running VMs then they must be some export that uses an IPC to the VMWare itself.
Even if the VM vendor didn't have inbuilt functionality if the malicious software can execute OpenProcess (or lower APIs such as NtOpenProcess), ReadProcessMemory (NtReadVirtualMemory), WriteProcessMemory (NtWriteVirtualMemory):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684320%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681674(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680553%28v=vs.85%29.aspx
Well, this list could go on about other forms of code injection. Breaking from host into a guest would be must easier as you'll have direct access to the memory.
To secure your software you'll want to execute it under another user and deny all other users using DACL to the following:
- PROCESS_VM_OPERATION
- PROCESS_VM_READ
- PROCESS_VM_WRITE
- WRITE_DAC
- WRITE_OWNER
- PROCESS_DUP_HANDLE
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880%28v=vs.85%29.aspx
Finally ensure to use an AV which monitors IPCs and virtual and physical memory.
@Comment
Yeah, the risk is quite minimal really unless your targeted as an individual.
If the attacker can compromise the host machine then your VMs are easily at risk unless you've preformed the above tasks to reduce the scale of the attack.
Though, if the malware manages to get into kernel then it's game over regardless of the security you put in place. Malware on the host machine gaining access to the guest machine is a whole different field.
To explain this little better I'll make the scenario:
- Your VM software is Oracle VirtualBox
- Your host machine is Windows operating system which is infected with x malware.
- Your guest machine is isolated from any remote connections etc which is currently virus-free (This is why it's differs from scale of attack on host)
Exploiting the inbuilt components of the software (Easy method):
- Simplest way to explain this without knowing Windows internals would be there is an executable called VBoxManage.exe which is capable of managing hardware of your VM and the whole VM itself.
So, the malware just invokes passes the malicious commands to VBoxManage.exe to copy and executes the malware onto guest machine. Though, do note that administrator permissions is required by the malware.
If you let me know the VM are your using then I can give you more accurate scope of attack. VMWare has pretty much same functionality as Oracle VirtualBox without getting all hardcore into details.
I've not used VirtualBox in a while so things maybe slightly different but you could used to use a command called VBoxManage.exe guestcontrol.
Memory hacking
- Let's for argument sake say there is no command-line executables to manage the VM and/or SDK on how to communicate with VM.
If the malware process can use OpenProcess API with PROCESS_VM_OPERATION, PROCESS_VM_READ and PROCESS_VM_WRITE the malware can perform many varies ways to inject code or read data from your VM process.
This can be a very challenging or easy task but it's hard to say without trying it myself though I'm sure administrator permissions would be required to begin with.
I don't know if you want me to go into the details of process security and reverse engineering the software? Or you just stick to the above on how to reduce the attack scope regarding process permissions and user permissions.
