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>] [day] [month] [year] [list]
Message-ID: <46D618B6.9040804@vmware.com>
Date: Wed, 29 Aug 2007 18:09:10 -0700
From: VMware Security team <security@...are.com>
To: bugtraq@...urityfocus.com
Subject: VMware poor guest isolation design

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

*Summary*

VMware VIX API 1.1 supports an option that allows users with privileges
on the host machine to execute programs on a guest operating system
under the identity of a user currently logged into the guest. For
example, if user A powers on a virtual machine (VM) and logs into the
guest operating system, then a user B who has privilege on the host
machine to connect to that VM can also write scripts that will
anonymously run programs in the VM guest operating system as user A.
Note that the only users who can access the VM this way are either the
same users who have powered on the VM or an administrator on the host.

*Affected products:*

This behavior is only present in Workstation 6.0 and VMware Player 2.0.

This issue does not affect any released version of VMware Server, VMware
ESX Server, or VMware GSX Server.

*How to disable this behavior*

You can disable this behavior by adding an entry to the host
configuration file. This will override any VM-specific configuration and
globally disable the behavior for all virtual machines running on the host.

The host configuration is owned by the System/root account, so it is
protected against non-root users who have virtual machines on the system.

This behavior can be disabled at the host level by adding the following
line to the host configuration file:

guest.commands.anonGuestCommandsRunAsConsoleUser = "FALSE"

On Linux, the default pathname for this file is:

/usr/lib/vmware/settings

(Note that "settings" is the file name, not another directory name.)

On Windows (except Windows Vista), the default pathname for this file is:

C:\Documents and Settings\All Users\Application

Data\VMware\VMware Workstation\settings.ini

On Windows Vista, the default pathname for this file is:

C:\ProgramData\VMware\VMware Workstation\settings.ini

(Note that on Windows Vista, the "ProgramData" directory may be hidden
by default.)

If you installed the product in a custom location, then the path name
for the configuration file may be different.

Normally, the file will not exist. If the file does not exist, then
first create a new blank text file named "settings" on Linux and
"settings.ini" on Windows and then add the new settings line.

Alternatively, you can also add the following line to the VMX
configuration file to disable the behavior on a per-VM basis:

guest.commands.anonGuestCommandsRunAsConsoleUser=FALSE

The only feature of VMware Workstation that relies on this behavior is
the Integrated Virtual Debugger, i.e. the optional plugins for Eclipse
IDE and Microsoft Visual Studio. Disabling this login mode as documented
above will disable this feature.

In addition, VIX API client programs and scripts which depend on this
login mode while calling VixVM_LoginInGuest will need to be modified to
use a username and password to login to the guest.


*The rationale for this design decision*

We added this functionality to VMware Workstation in order to provide a
seamless user experience using Integrated Virtual Debugger – a user will
not be prompted to log-in each time a program is launched to run/debug
inside a VM.

We determined that, although this automates interaction with the guest
operating system, this is not a /bona fide/ escalation of privileges in
the guest operation system because any user who can access the VM this
way can already open the user interface and manually interact with the
guest under the identity of the currently logged-in user.

In other words, if you are able to connect to a running VM, you need to
be either the user who powered on the VM, or you are an administrator of
the host. So, this behavior only applies to users who already have
access to the VM.

However, we take this feedback very seriously, and we are reevaluating
this design decision for the next dot-release of Workstation.

For further questions regarding this issue or other security related
issues for VMware, please contact us at security@...are.com.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG1hizS2KysvBH1xkRCFftAJ0Smpt2Pg9S1TNNQbMbHVAkwmzW4ACeIh4T
LvOvvSkDakRXQIXNEcvtxGc=
=NCoo
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ