Will installing guest additions post a security risk to a host OS?
-
could you narrow the focus of your question a bit? are you concerned about creating a risk to the guest from the host? a risk to the guest from other hosts? a risk to the host from the guest? something else?– jeffCommented Aug 27, 2009 at 3:47
-
i'm worried about risk to host– PhilCommented Aug 27, 2009 at 12:16
Add a comment
|
5 Answers
Probably. Definitely in vmware-tools. The copy/paste buffer and keyboard/mouse shared memory areas allow access to the host. If the virtual is rooted it's trivial to determine the type of virtualization used and hack/install your own client tools. AFAIK, only vmware has had example code to hack over these API channels and that's been patched for quite some time.
That being said the changes of you getting hacked this way are probably close to zero. I wouldn't concern myself until we start to see published hacks using these methods. Or rather, there's plenty of other things to spend time on securing first. Shared file access, not using a DMZ, improper firewalling, weak passwords, bad file permissions are all more important.
Always remember, social networking hacks, mis-configured systems and disgruntled employees and plain stupidity (selling data loaded harddrives on ebay, password taped to the monitor, etc.) are the top four entry points for most reported large system hacks.
Here's one, there have been others - VMWARE - A VMCI privilege escalation on Windows-based hosts or Windows- based guests.
OpenBSD has the right attitude. Don't install it unless it's absolutely needed. You can install the network driver from the client tools on it's own. "Secure" virtuals should not have shared file access, consoles, etc..
-
what about linux hosts? i pretty much don't use windows as host– PhilCommented Aug 31, 2009 at 13:27
I can't think of any reason why it would be. "Guest" refers to the guest operating system, by the way, not guest users.
Guest Additions is a set of drivers for the display and mouse, etc., that improves the functionality of those items.
answered Aug 27, 2009 at 1:15
The guest is sandboxed. Guest additions are installed on the guest OS. I don't see how it's any more of a security risk than having that machine on your network as a physical system...I suppose you could come up with some scenarios of a more direct threat if you have host-to-guest drive sharing enabled.
Otherwise...why would you think it's a security threat?
answered Aug 27, 2009 at 1:23
-
-
1Ah. Well, for the most part the security issue is the same as having another computer on your network (compromise the guest, it can be a launch point to attack others visible on the network, for example, or copy files to/from shares including the host-to-guest mapping, but again...same as any other system in your network.) You'll also have to double-update (remember to keep security updated on your VM machine periodically). Other than that, there's no inherent risk from it that I've ever seen or heard of. Commented Aug 27, 2009 at 12:49
There are some vulnerabilities in any software, and virtualization software is no different. However, the vulnerabilities are currently hard to do and little known or understood - thus not much of a threat. There is the threat that a user may try to "break" the virtualized sandbox; however, as I mentioned, this is currently not likely to occur.
You biggest risk is from the host OS or the guest OS being compromised, not the virtualization software itself.
...what about linux hosts?
The exploits are over data channels and shared memory. Host OS doesn't matter per se. It's the individual code involved and the access controls/permissions on the host. (selinux/apparmor/tomoyo for linux)