> attacker in the future. Some of you keep trying to point out that owning the
> host always means owning the guests, but that isn't always the case,
> especially if you are not a full administrator on the host machine.
...

> should be able to protect a virtual guest from its host. There's no way a
> non-admin user is going to be able to modify the RAM of a vm. And in Windows
> Vista, if not already blocked, even as an administrator I would have to
> explicitly allow a worm to access the RAM or disk of a virtual machine. No
> worm is going to access a vm's resources without a UAC prompt coming up.

UAC is not a security boundary.

You don't need administrator privileges. If the VM is running with the
same privileges of the attacker, he can alter the program state of the VM.
The most obvious way with VMWare is to pause the machine. This writes out
physical memory as a .vmem file. Alter the file and resume VMWare. Less
obviously you can use the OS debugging APIs, or inject a DLL into the
address space of the VM process, or map its memory using memory management
APIs, or exploit a vulnerability in the VM process, or.....

Similar attacks can be performed by altering the disks or attaching
malicious hardware. You could point out that the guest OS need not
trust the disk or the hardware and you would be right. However, all
of the important OSs *DO* trust disks and most are very trusting of
hardware.

Your statements that administrator access protects the VM is simply false.
Your assumption that UAC will protect you from low-privileged worms is
similarly wrong.

> Mark

Tim Newsham
http://www.thenewsh.com/~newsham/

[ reply ]