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: Thu, 23 Aug 2007 15:46:27 -0500
From: "William Holmberg" <>
To: "Arthur Corliss" <>,
	"M. Burnett" <>
Cc: <>
Subject: RE: VMWare poor guest isolation design

Perhaps there are implementations in certain businesses that require
those things. It is possible you may not be the only person with that
level of access, particularly in a large environment with 50 or so DA's,
and 10's of 1000's of users, with dozens or hundreds of VM's...

Looked at in the perspective that you don't *own* the hardware and the
VM's on them, would that alter your answer at all?


-----Original Message-----
From: Arthur Corliss [] 
Sent: Thursday, August 23, 2007 11:49 AM
To: M. Burnett
Subject: Re: VMWare poor guest isolation design

On Wed, 22 Aug 2007, M. Burnett wrote:

> I have run across a design issue in VMware's scripting automation API
> diminishes VM guest/host isolation in such a manner to facilitate
> escalation, spreading of malware, and compromise of guest operating
> VMware's scripting API allows a malicious script on the host machine
> execute programs, open URLs, and perform other privileged operations
on any
> guest operating system open at the console, without requiring any
> credentials on the guest operating system. Furthermore, the script can
> execute programs even if you lock the desktop of the guest OS.
> For example, if a non-admin user is logged in at the vm host, but
logged in
> to guest operating systems as an administrator, the script running as
> non-admin on the host can still execute admin-level scripts on the
> I obviously did not discover this issue--the API developers provided
it as a
> feature-I am simply pointing out the potential danger, that it was a
> design decision, and that there is a need to establish best practices
> virtual machine guest and host isolation.

I don't see this as a serious problem.  This is the virtual equivalent
of no
physical security.  If the host OS (or an account within it) is
of course all bets are off when it comes to a virtual machine running

Furthermore, this attack only works if you are running the vmware guest
utilities *and* you are currently logged into a GUI desktop running the
vmware userland process.

I personally look at this as an issue for Windows.  I personally don't
install the vmware guest software for my Linux VMs, nor would I log into
GUI as root.  For that matter, if you are merely hosting the guest VMs
would you need to ever use the vmware console after installation?  Use a
network-based access method, making the need for the vmware guest
unnecessary.  That should be sufficient for all OS'es.

In (not so) short, this attack vector is virtually worthless if
security practices are employed.

 	--Arthur Corliss
 	  Live Free or Die

Powered by blists - more mailing lists