Re: VMWare poor guest isolation design

看板Bugtraq作者時間18年前 (2007/08/25 20:48), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串6/8 (看更多)
On Thu, 23 Aug 2007, Jonathan Yu wrote: > Hi there, > > First of all - please forgive me, I'm not a developer and I don't use > the automation API. However, I use VMware a lot for development. I > have a Windows XP host machine and I use VMware to develop Linux code > (Debian Etch, Linux 2.6). I'm a p570 user on the server side, but I do use vmware workstation for development purposes as well. > It is worse than this because according to the original e-mail, you > can queue up commands to be executed upon the next login. That is > where it gets dangerous, whereas it wouldn't have been an issue with > "no physical security" alone. Only if you *choose* to run the userland utilities. If you don't, all the queuing in the world won't get those commands executed. > However, I propose an alternate attack scenario: if the host system is > compromised, then the program is able to write to the VMware Disk > files or the physical partition that the virtual machines are > installed in. This means that you can write arbitrary things to it or > change files around, so you can have the same effect if you, say, add > a command to the root user's crontab... Which is my point. If you don't have security on the host, you're already massively vulnerable regardless of whether or not this functionality exists. >> Furthermore, this attack only works if you are running the vmware guest >> utilities *and* you are currently logged into a GUI desktop running the >> vmware userland process. > Many people are in this situation. So we're surrounded by lemmings. You're not pinning that on me, man. ;-) > I have all the guest tools installed. Why? It is useful - besides the > hgfs ("Shared Folders") support, there is also the vmmemctl module, > which returns unused memory pages back to the host OS, which allows > overcommitting if necessary (on my system it just ensures that I can > use as much of the RAM as possible). I'm glad you're getting some utility from them, you're part of the demographic they wrote them for. But, odds are, you're also part of the demographic that still doesn't have practical impact by this. You probably admin your own box as well as the vms you develop in. If your host has gotten exploited, whether or not they can execute something in a vm is the least of your problems. Once again, host security rules all. Let's sum this up, folks: this functionality poses no threat to the host platform. So, if someone cracks the *host* isn't that fact alone far more frightening than the ability to (maybe) launch a few processes in a vm? I'd wager that the damage that can be done by launching a few processes on the host is far more gruesome than what can be done in the guests. --Arthur Corliss Live Free or Die
文章代碼(AID): #16q2KT00 (Bugtraq)
討論串 (同標題文章)
文章代碼(AID): #16q2KT00 (Bugtraq)