From a discussion on the VMWare workstation support forums, I learned that VMWare workstation in combination with glibc 2.3.4 or 2.3.5 is a security risk (see discussion in the URL above). The problem is that from glibc 2.3.4 setuid works per process instead of per thread, so some multithreaded setuid applications suddently have all threads running as root. The symptom is a file written as the root user, presumably one can make accidents by letting it be a softlink somewhere else - and presumably many other things can go wrong. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Not sure what the solution would be here. We can't exactly force vmware users to downgrade to 2.3.3... Pulling in vmware team for comments.
Not sure there is a solution :-( VMware workstation 5.0 and above work around the problem. But since you have to pay for licenses, some may be stuck with 4.5 - I for one do not need the new features in 5.0. Also, I am not sure to what extend fixing this really helps security, since one can create new virtual machines with access to the raw disks, and probably cause a security breach that way (I think). Perhaps the *real* solution would be to revert the "broken" behaviour of glibc (broken as in "broken as designed", not as in buggy), but that might break countless other programs ? Jakob
About the only thing we *can* do is package.mask VMware versions < 5.0 and give a big fat warning to users. There's a possibility that a future vmware-any-any-update version might resolve this issue, but for now, there isn't much that we can do about it.
That's what I would push for if there was a clear exploitation path. But if the "suddenly all threads as root" phenomenon is not predictable, I can't see it exploited... or is it ?
I think it is quite consistent that all threads run as root, but if it is exploitable? Well, ~/.vmware/preferences is overwritten by root, but if I make it a softlink somewhere else, the link is not followed. I do not think that a vmware-any-any-update will come, it was Petr Vandrovec (the author of these updates) who told me about the problem - he seemed quite annoyed at the glibc change, which happened a while ago. /Jakob
Setting this to Auditing so that we find an exploitable hole before making any move.
Nothing audit team can do here. I would suggest vmware team modifies vmware ebuild to install a vmware group, then only make vmware-vmx executable by users in group vmware. This way, the system administrator can add trusted users to this group. A stern ewarn stating that vmware access can be used for evil would then solve this issue. Moving component to `Default configs`.
All versions of vmware-workstation (not just < 5) now use a vmware group. This can be resolved as it applies to those packages.
Looks good to me, please reopen if you feel this needs more care.
