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
