lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Aug 2007 13:36:54 -1000 (HST)
From: Tim Newsham <>
To: "M. Burnett" <>
Subject: RE: More on VMWare poor guest isolation design

> 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

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

Powered by blists - more mailing lists