Docker的一個安全性漏洞

標籤：lxc   linux   docker   駭客   漏洞   

最近又翻譯了一篇關於Docker的文章，內容是Docker發布的一個安全性漏洞以及應對方法，地址在docker中文社區的《突破 DOCKER 容器的漏洞驗證代碼》

其實我十來年前做過一段時間的系統安全，還結識了安全圈裡一幫兄弟，後來我轉行做了儲存，也一直在關注安全領域。這一兩年安全行業迅猛發展，看得我有時候真是羨慕嫉妒恨啊......

回到技術話題，這個漏洞其實很容易理解。Linux上，每個進程除了根據運行者的uid進行許可權識別，還有一組kernel capability，這一組在kernel代碼裡面以CAP_開頭的宏更細緻的定義了進程所擁有的許可權。

而在容器也就是container內部，許可權的設計就很複雜了。Container內啟動並執行進程，本質上都直接運行在主機的核心空間中，和其他主機上的進程在核心中沒什麼區別，都有task_struct。所以為了限制container內進程的存取權限，讓他們感覺自己運行在自己獨立的空間中，就要在進程資料結構中設定特定的參數，在很多核心調用中，虛構返回。比如最基本的chroot()，讓container進程只能將指定的目錄當作根目錄進行訪問。

而攻擊者（駭客）想要突破這個限制，要從container內部進程想辦法訪問到宿主系統的各種資源。最早最粗糙的攻擊方式就是用各種特殊符號，比如“../../../../”。這種現在看起來搞笑的攻擊方法在30年前UNIX上可是很奏效的，後來慢慢的很多簡單的漏洞就被補上了。

具體到這個從docker的容器中訪問到宿主系統的攻擊方法，是利用了kernel的CAP_DAC_READ_SEARCH這個capability配合open_by_handle_at()這個系統調用。Docker 0.12之前的版本，在建立新的container之前，放棄了很多kernel的capability，卻忘記了這一個，乃至於容器內的子進程都繼承了這個cap。而擁有這個cap以後，通過指定inode的值，可以通過open_by_handle_at()這個系統調用直接開啟inode值對應的檔案，而不再是通過路徑開啟。而通常來說，/根檔案系統的inode號是2.所以通過構造合理的參數，使用open_by_handle_at()，可以開啟宿主系統的根目錄。開啟了根目錄之後嘛，嘿嘿，就可以隨意便利和開啟下面的檔案咯。

這裡再貼個英文的關於該漏洞更詳細的說明 Docker breakout exploit analysis

值得欣慰的是，從0.12版本以後，docker在建立新容器進程的時候，會放棄所有的kernel capability。這個問題就不存在啦。

本文出自 “計算-儲存-互連網” 部落格，請務必保留此出處http://besmart.blog.51cto.com/8957700/1429979