bugtraq - RE: More on VMWare poor guest isolation design

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <Pine.BSI.4.64.0708271327590.7227@malasada.lava.net>
Date: Mon, 27 Aug 2007 13:36:54 -1000 (HST)
From: Tim Newsham <newsham@...a.net>
To: "M. Burnett" <mb@...o.net>
Cc: bugtraq@...urityfocus.com
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
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/