Summary: | app-emulation/vmware-workstation: glibc 2.3.4 means security hole | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Jakob Schiotz <schiotz> |
Component: | Default Configs | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | vmware+disabled |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://www.vmware.com/community/thread.jspa?threadID=21037 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jakob Schiotz
2005-09-01 06:37:54 UTC
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. |