To build the kernel modules, the admin has to run /opt/vmware/workstation/bin/vmware-config.pl, which creates /tmp/vmware-config{0,1,2}/. A user can symlink these directories before and place e.g. modified non-writable perl scripts, which would be executed by root.
As mentioned in bug 91058, we are working on a solution which will move at least some of the work done in /tmp/vmware-config*/ to the nice sandboxed location of a portage ebuild. However, it doesn't look like it's gonna be hitting the tree anytime soon, please chat to Chris G about the release schedule for this enhancement...
Any news?
Well, by "soon" we meant weeks, really. We could try to patch the vmware-config.pl file for now, but my perl isn't all that good, so it'll be a while. What course of action would security recommend?
My insignificant two cents: Giving a user access to vmware-workstations involves a lot of trust already. Having said this, I think it might be the best way to include a check to see whether the files to be created are there yet, which shouldn't be impossible to do (I know, the vmware scripts are like 7000 lines of bloat you never ever need and it's hell out there). The final solution would be to just dump the **** vmware comes with [as for the ESX "guest" stuff you just need one executable to deliver the heartbeat and life signs, for example] and everybody would congratulate you on that achievement I guess. If you absolutely can't find anybody else to touch the perl stuff, page me (perl's not my special love, either, but what can you say :[ )
(In reply to comment #4) > My insignificant two cents: Giving a user access to vmware-workstations > involves a lot of trust already. A user doesn't need to have access to vmware to carry the attack. A symlink placed in /tmp to a directory including a malicious file suffices. Chris, I don't know how the security team thinks about it, but accoriding to the vulnerability policy
(In reply to comment #4) > My insignificant two cents: Giving a user access to vmware-workstations > involves a lot of trust already. A user doesn't need to have access to vmware to carry the attack. A symlink placed in /tmp to a directory including a malicious file suffices. Chris, I don't know how the security team thinks about it, but accoriding to the vulnerability policy¹, I'd say the severity level is A1 or at least B1. Also VMwware needs to be informed. I didn't do so, yet, assuming the VMware team has upstream contacts. [1] http://www.gentoo.org/security/en/vulnerability-policy.xml
(In reply to comment #0) > To build the kernel modules, the admin has to run > /opt/vmware/workstation/bin/vmware-config.pl, which creates > /tmp/vmware-config{0,1,2}/. A user can symlink these directories before and > place e.g. modified non-writable perl scripts, which would be executed by root. > IIRC, vmware-config.pl will increment /tmp/vmware-configX to the next number if /tmp/vmware-configX is exist. Not sure how you can perform a symlink attack.
We have no contacts within VMware, but http://www.vmware.com/company/contact.html has a link for reporting security bugs.
Look at #6; in my vmware-workstation-5.5.1.19175-r3's vmware-config.pl the handling of this starts in line 1545; I fail to see the window of attack, though. Does anybody have a clearer view?
Any news on this one?
I haven't been able to look into it, but from what everyone is saying, it looks to be a non-issue.
Taviso do you agree?
I've to admit that I didn't look at the perl script. Tuan is absolutely right of course.
