Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vagrant compromises host security by default #1785

Closed
mc0e opened this issue Jun 2, 2013 · 12 comments

Comments

Projects
None yet
6 participants
@mc0e
Copy link

commented Jun 2, 2013

I'm hardly the first to notice, but out of the box, vagrant has some serious security issues.

Firstly, it comes with standard ssh key and passwords, giving root access. This is pretty obvious, and not really unexpected. Most users will figure that it's ok, because the Vagrant uses host only networking, and the VM's often not that important anyway.

Unfortunately, Virtualbox forwards 0.0.0.0:2222 on the host to the virtual environment. IF it forwarded 127.0.0.1:2222 that wouldn't be much of an issue, but as it is, this opens up access to anyone on the local network.

Virtualbox also shares it's configuration directory from the host, and it does it in read-write mode. This gives the vagrant user (or root) numerous ways to compromise the security of the host machine. The simplest such mechanism would be to put ruby code into the Vagrantfile. Whatever code is put there will run on the host environment before long.

To do:

  1. Fix the port forwarding so it forwards from localhost only.
  2. Provide a way to make the sharing of directories read-only, and make that the default behaviour, particularly for the default sharing of the whole vagrant directory.
@mitchellh

This comment has been minimized.

Copy link
Member

commented Jun 2, 2013

I will be addressing the port forwarding by changing it to bind to 127.0.0.1 only. As for the ruby code in the Vagrantfile, it runs as the user that the vagrant command is run as. I don't consider this a security issue so much since it is so obvious that any code put in there will be run. I may be missing something with the second point though.

@velocd

This comment has been minimized.

Copy link

commented Jun 2, 2013

Provide a way to make the sharing of directories read-only, and make that the default behaviour, particularly for the default sharing of the whole vagrant directory.

I think not sharing the Vagrant folder is better security in the long run, and only share the folder and files needed by the instance. For example, a web server wouldn't need the Vagrantfile and related things.

config.vm.synced_folder "nginx/", "/work"
config.vm.synced_folder "./", "/vagrant", disabled: true
@mitchellh

This comment has been minimized.

Copy link
Member

commented Jun 2, 2013

Ah, well the way people run Vagrant mostly is to share their project directory. In cases like Ruby on Rails it is very common for files to be edited in this directory. Read-only by default would get rid of the "works by default" nature of Vagrant in this case and I won't do that. I think the security risk involved in having read/write is minimal here, if not completely obvious.

@mc0e

This comment has been minimized.

Copy link
Author

commented Jun 4, 2013

If the vagrant environment is shielded from the outside world, then there may be little opportunity to exploit his, but if the vagrant user has access to the home account of the developer, then that's likely to be a major security issue. eg, the compromised user account on the host will commonly have things like easy ssh-agent based access to production servers. I think it's important that you put out a warning to your users that they need to upgrade or patch their versions of vagrant. At least get hold of the maintainers of the packages for various OS distributions.

If you want to make it possible to share these files read-write, then you need to put warnings about the security issues front and center, and I still think the user should have to do something to turn this read-write sharing on. Currently you don't even have clear instructions on how to disable writes to the host environment.

What you've created encourages people to just download and fire up an environment within a few commands of first taking a look at vagrant. At this point they're wide open, and not very much at all about vagrant is obvious yet. To many users it never will be unless you tell them, partly because they'll start from a reasonable assumption that you've taken some care over looking out for their security. Don't believe me? I'm sure you find yourself in a fair few cases where you can scan for ssh listening on port 2222 so you can investigate. No doubt others are already doing it.

I think there's a pretty good argument that what you've got here is currently badly broken by default.

@dserodio

This comment has been minimized.

Copy link

commented Jun 6, 2013

Forwarding only localhost:2222 would be a good compromise: keeps all the current functionality with much better security.

mitchellh added a commit that referenced this issue Jun 9, 2013

@mitchellh

This comment has been minimized.

Copy link
Member

commented Jun 9, 2013

Fixed! Will be part of 1.2.3. :)

@bascht

This comment has been minimized.

Copy link

commented Jun 19, 2013

I am sure there is still a large amount of Vagrant 1.0.x installations somewhere "out there", so we tried to get at least the sane defaults of 2979b0a into a single patch for 1.0.7 https://gist.github.com/bascht/5812538 - we're using this to quickly patch old installations until we can upgrade to 1.2.3. ;-)

@robbyt

This comment has been minimized.

Copy link

commented May 25, 2014

It seems that there is a regression, and this is a problem again in Vagrant 1.6.2.

@mitchellh

This comment has been minimized.

Copy link
Member

commented May 25, 2014

@robbyt Just spun up an empty VM with 1.6.2 and SSH is bound to 127.0.0.1

@robbyt

This comment has been minimized.

Copy link

commented May 26, 2014

@mitchellh thanks for confirming - I'm having this problem with the vmware-fusion provider on osx. What other information can I provide?

@mc0e

This comment has been minimized.

Copy link
Author

commented May 26, 2014

@mitchellh If ssh is bound to 127.0.0.1 on the VM, it shouldn't be reachable even from the host environment.

@mitchellh

This comment has been minimized.

Copy link
Member

commented May 27, 2014

@mc0e It binds the forwarded port to 127.0.0.1, not the SSH daemon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.