2013-02-05 81 views
67

編輯2:TL; DR:的答案是肯定的,2013年,但這一缺陷已得到修復默認流浪者不安全?

通過以下對vagrantup.com入門指導,我似乎與虛擬機落得即接受端口2222上的SSH連接,以便任何人都可以獲得對我的虛擬機的root訪問權限,並使用默認憑據(username = password = vagrant或vagrant_insecure_private_key)讀取我的主機工作目錄。

這是真的嗎?如果是,爲什麼它不被認爲是一個嚴重的安全漏洞?如果我將敏感數據複製到虛擬機中,該怎麼辦?

編輯:對於那些誰認爲任何人在互聯網上能夠讀取你的源代碼,並在VM上執行任意代碼並不壞,我建議在這篇博客文章讀了「突圍」一節http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

簡而言之:按預期運行Vagrant可以讓任何人進入你的主機/開發機器(例如,通過使用惡意的git post-commit hook)。

+1

打破進出vagrant_的鏈接。以下當前工作:http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/ – pnd

+1

http://web.archive.org/web/20160714220643/ http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant –

回答

91

簡短的回答是是的

爲什麼?

當構建流浪基座箱(手動或使用工具,如Veewee自動),助洗劑遵循其定義了以下的vagrant base boxes specifications

  1. 用戶rootvagrant使用流浪漢作爲密碼
  2. 公共密鑰認證(無密碼)爲用戶vagrant

流浪項目爲SSH公鑰認證提供了一個不安全的key pair,因此vagrant ssh工作。

因爲每個人都有訪問私有密鑰,任何人都可以使用私鑰登錄到您的虛擬機(假設他們知道你的主機的IP,端口默認爲2222,以代替轉發規則。)

這是不安全的OOTB。但是,您可以從~vagrant/.ssh/authorized_keys中刪除信任密鑰並添加自己的更改密碼vagrantroot,然後認爲它相對安全。

更新

由於流浪1.2.3,通過默認的SSH轉發端口結合127.0.0.1所以只有本地連接被允許[GH-1785]。

重要更新

由於流浪1.7.0(PR #4707)與第一vagrant up隨機生成的密鑰對流浪將替換默認不安全的ssh密鑰對。

請參閱CHANGELOG:使用默認的不安全密鑰對,Vagrant會自動用第一個vagrant up上隨機生成的密鑰對替換它。 GH-2608

+0

的開箱即用的配置沒有完全破壞,但開箱即用的它包括給予有效訪問用戶運行虛擬主機環境中的虛擬機與虛擬機中具有根訪問權限的任何人共享。這是一個相當嚴重的缺陷,但並不足以讓主人妥協。 – mc0e

+1

無密碼sudo!看來你不能忽視這一點? – CMCDragonkai

10

我已經提出這作爲流浪漢github存儲庫的問題。開發人員表示,他們將通過轉發的端口可以解決問題。然而,開發人員並不接受有關從VM中破壞主機環境的問題。我認爲他們是錯誤的。

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

打破了虛擬機相比,更便於鏈接的博客文章建議。你不必依靠git鉤子來破壞主機,你只需將任意ruby代碼放入Vagrant文​​件即可。

我會在一個虛擬機沙箱,如果我能運行無業遊民。由於我不能,所以我使用了防火牆。

配置規則添加安全密鑰並刪除不安全密鑰和默認密碼是個好主意。

7

由於流浪1.2.3默認的是綁定到本地主機,而不是公共接口,避免了外部連接的問題。

9

我編寫了這個簡單的內聯shell配置程序,用我的id_rsa.pub換出authorized_keys。一旦配置,insecure_private_key不能用於認證。

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 
+2

這看起來非常適合私鑰。但是這對於賬號「流浪者」和「根」有密碼「流浪者」這一事實不會做任何事情,對嗎? –

1

只是想補充說有一個流浪者插件可以解決這個問題:vagrant-rekey-ssh。它會更改VM的默認密碼,並刪除不安全的SSH密鑰。

+0

好東西。謝謝。儘管宿主環境暴露在流浪者的箱子裏,但如果有其他的漏洞存在的話。 – mc0e

+2

供參考:此功能現在包含在Vagrant 1.7+中。該插件已過時。 – James

0

我想解釋一下爲什麼流浪未必如你想象的那麼不安全。

我想先說一句,因爲我相信你們大多數人都已經意識到,由於這些盒子被共享的方式,有必要保持對Vagrant盒子的開放訪問。出於這個原因,我相信主要的安全問題不會在下載該框後更改默認憑據。以橋接模式運行此類計算機將允許網絡中的某個人使用默認憑據進行登錄。

在我看來,這些框背後的想法是,任何人都可以下載它,並保護它,一旦它被佔有。我的vagrant安裝用一個新的隨機生成的ssh密鑰替換默認密鑰。我不確定這是否是用插件完成的,但我很想知道無密碼的sudo和默認密碼是否也存在安全風險。