Bugtraq mailing list archives

Re: VMware 1.1.2 Symlink Vulnerability (not)


From: peterw () USA NET (Peter W)
Date: Tue, 25 Jan 2000 00:19:41 -0500


Aleph, please nuke my previous post on this thread.

Oops. Vmware does try to create $TMPDIR/vmware-log or /tmp/vmware-log,
even if given a config file argument (though if given a .cfg argument, it
quickly unlinks the temporary log file).

New recommendations:
 - set $TMPDIR to something sane like $HOME/tmpfiles

The exploit is not as silly as it first looked to me, but neither is it as
serious as the advisory seems to suggest.

Apologies to Harikiri for not checking a wee bit more thoroughly before
posting a response. Doh.

To Vmware: it would be nice if the first choice was $HOME/vmware,
then $TMPDIR (maybe), then a fatal complaint.

-Peter

At 11:50pm Jan 24, 2000, Peter W wrote:

At 8:48am Jan 24, 2000, harikiri wrote:

w00w00 Security Advisory - http://www.w00w00.org/

Title:              VMware 1.1.2 Symlink Vulnerability
Platforms:  Linux Distributions with VMware 1.1.2 (build 364)

Due to the low-level requirements of VMware, it is necessary to run the
program at a high privilege level, typically root.

Vmware installs kernel modules, but the app itself may be run by
unprivileged users.

VMware creates the file "/tmp/vmware-log" on startup. The existance and
owner of the file is not checked prior to writing startup information to
the file.

NOTE: VMware uses other files in the /tmp directory. The one cited above
is only a single example.

Vmware normally writes a log file and other files to the same diretory as
your guest OS's vmware <configName>.cfg file, but I don't expect many
folks would save their configurations in /tmp, _especially_ since (1)
that's where the precious virtual disk file is located and (2) vmware
defaults to $HOME/vmware/<configName>. It looks like all of these files
persist after vmware shuts down, and if I rename a file, vmware honors my
umask when it re-creates it. If I link to a root:root mode 644 file,
vmware complains about not being able to write to it.

If vmware cannot create <configName>.log in the same dir as
<configName>.cfg, _then_ it will try to make a generic "vmware-log" file.
Note it will write this in $TMPDIR rather than /tmp if $TMPDIR is set.
Again, I can't imagine the vmware user not being able to write in the
virtual config directory. If I link $TMPDIR/vmware-log to a file I don't
have write perms to, vmware refuses to run.

Local users may create a symlink from an arbitrary file to /tmp/vmware-log.
When VMware is executed, the file pointed to by the symlink will be overwritten.

This may be used as a local denial of service attack. There may also be a
method to gain elevated privileges via the symlink attack, though none is
known at this time.

The limit of this exploit is the following: any attacker who can replace
any special vmware config files (or set up sym links before they're
created) can trick a local vmware user into clobbering a file they already
have write priviliges to.

http://www.bastille-linux.org/ : working towards more secure Linux systems


Current thread: