73

EDIT 2: TL;DR: the answer was yes in 2013, but this flaw has been fixed

By following the Getting Started instructions on vagrantup.com, I seem to end up with a virtual machine that is accepting SSH connections on port 2222 so that anyone can get root access to my VM and read my host working directory using the default credentials (username=password=vagrant or vagrant_insecure_private_key).

Is this true? If yes, why is it not considered a gaping security vulnerability? What if I had copied sensitive data to the VM?

EDIT: and for those who think anyone on the internet being able to read your sources and executing arbitrary code on your VM is not that bad, I recommend reading the "Breaking out" section in this blog post http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

In a nutshell: running Vagrant "as intended" can also enable anyone to break into your host/development machine (e.g., by using a malicious git post-commit hook).

oseiskar
  • 3,282
  • 2
  • 22
  • 22
  • 1
    The link to _breaking in and out of vagrant_ is broken. The following currently works: http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/ – pnd Feb 18 '16 at 12:12
  • 1
    http://web.archive.org/web/20160714220643/http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant – Mark Fox Feb 23 '17 at 00:34
  • How do you secure against the "breaking out" vulnerability? or is that now obsolete because it's secure against breaking in? – user163831 Feb 29 '20 at 01:59

6 Answers6

100

The short answer is YES.

Why?

When building Vagrant base boxes (manually or using tools like Veewee to automate), builders follow the vagrant base boxes specifications which defines the following:

  1. User root and vagrant use vagrant as password
  2. Public key authentication (password-less) for the user vagrant.

Vagrant project provides an insecure key pair for SSH Public Key Authentication so that vagrant ssh works.

Because everyone has access to the private key, anyone can use the private key to login to your VMs (suppose they know your IP of the host machine, port is by default 2222 as forwarding rules in place.)

It is NOT secure OOTB. However, you can remove the trusted key from ~vagrant/.ssh/authorized_keys and add your own, change password for vagrant and root, then it's considered relatively safe.

Update

Since Vagrant 1.2.3, by default SSH forwarded port binds to 127.0.0.1 so only local connections are allowed [GH-1785].

IMPORTANT Update

Since Vagrant 1.7.0 (PR #4707) Vagrant will replace the default insecure ssh keypair with randomly generated keypair on first vagrant up.

See in the CHANGELOG: the default insecure keypair is used, Vagrant will automatically replace it with a randomly generated keypair on first vagrant up. GH-2608

notpeter
  • 1,046
  • 11
  • 16
Terry Wang
  • 13,840
  • 3
  • 50
  • 43
  • The OOTB configuration is not fully compromised, but OOTB it does include giving effective access to the user running virtualbox in the host environment to anyone with root access in the VM. That's a fairly serious flaw, but not sufficient on its own to compromise the host. – mc0e May 28 '14 at 07:58
  • 2
    And passwordless sudo! It seems you cannot ignore that? – CMCDragonkai Jul 06 '14 at 07:28
10

I've raised this as an issue on the github repository for vagrant. The developer has said they'll fix the issue with the forwarded ports being externally available. The developer does not however accept the issue regarding compromise of the host environment from the VM. I think they're dangerously wrong.

https://github.com/mitchellh/vagrant/issues/1785

Breaking out of the vm is easier than the linked blog post suggests. You don't have to depend on git hooks to compromise the host, you just put arbitrary ruby code into the Vagrant file.

I'd run vagrant in a VM sandbox if I could. Since I can't, I make do with a firewall.

It's a good idea to have provisioning rules to add a secure ssh key, and to remove the insecure key and the default password.

mc0e
  • 2,699
  • 28
  • 25
9

I wrote this simple inline shell provisioner to swap out the authorized_keys with my id_rsa.pub. Once provisioned the insecure_private_key cannot be used to authenticate.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

# ...

  config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'" # avoids 'stdin: is not a tty' error.

  config.ssh.private_key_path = ["#{ENV['HOME']}/.ssh/id_rsa","#{ENV['HOME']}/.vagrant.d/insecure_private_key"]

  config.vm.provision "shell", inline: <<-SCRIPT
    printf "%s\n" "#{File.read("#{ENV['HOME']}/.ssh/id_rsa.pub")}" > /home/vagrant/.ssh/authorized_keys
    chown -R vagrant:vagrant /home/vagrant/.ssh
  SCRIPT

end
donnoman
  • 91
  • 1
  • 3
  • 3
    This looks great for the private key. But this won't do anything with the fact that account "vagrant" and "root" have the password "vagrant", right? – Noah Gibbs Sep 12 '14 at 03:53
7

As of Vagrant 1.2.3 the default is to bind to localhost instead of the public interface, avoiding the external connection issue.

jerm
  • 170
  • 1
  • 3
1

Just wanted to add that there is a Vagrant plugin that solves this problem:vagrant-rekey-ssh. It changes the default password of the VM, and removes the insecure SSH key.

Luca Invernizzi
  • 6,489
  • 3
  • 28
  • 26
  • Good stuff. Thanks. The exposure of the host environment to the vagrant box remains though, in case there's any other vulnerabilities there. – mc0e Jan 27 '15 at 16:39
  • 2
    FYI: This functionality is now included in Vagrant 1.7+. The plugin's obsolete. – James May 19 '16 at 20:54
0

I would like to explain why Vagrant is not necessarily as insecure as you might think.

I would like to start off by saying that as I am sure most of you are already aware, it is necessary to maintain open access to the Vagrant box because of the way these boxes are being shared. For that reason, I believe the main security concern is not changing the default credentials after the box is downloaded. Running such a machine in bridged mode would allow someone on the network to ssh in with default credentials.

It appears to me that the idea behind these boxes is that anyone can download it, and secure it once it is in their possession. My vagrant installation replaces default keys with a new, randomly generated ssh key. I am not sure if this is being done with a plugin, however I am curious to know if the password-less sudo and default password also present a security risk.

Coffee123
  • 156
  • 2
  • 9