Docker 全部版本都中招，重大漏洞容許攻擊者訪問主機文件系統

絕不誇張的說，全部的 Docker 版本都存在同一個漏洞，這個漏洞可讓攻擊者得到主機服務器上全部路徑的讀寫訪問權限。據瞭解，之因此會出現該漏洞，主要是由於 Docker 軟件處理某些符號連接的方式，而這些符號連接中每每會包含有到其餘目錄或文件的路徑的文件。

1.事件回溯

研究員 Aleksa Sarai 發現，在某些狀況下，攻擊者能夠在路徑解析時間和操做時間之間的短期窗口將本身的符號連接插入到路徑中。這是 TOCTOU 問題的一個變體，特別是「docker cp」命令，它能夠將文件從主機複製到容器，或從容器複製到主機。

Sarai 表示，「此次攻擊的基本前提是 FollowSymlinkInScope 遭受了至關根本的 TOCTOU 攻擊。FollowSymlinkInScope 的目的是獲取給定路徑並安全解析，就好像進程位於容器內部同樣。完整路徑被解析以後，路徑會被傳遞，同時會進行一些操做（例如，在’docker cp’的狀況下，它會在建立流式傳輸到客戶端的存檔時打開）。」

「若是攻擊者在解析以後、操做以前，向路徑添加符號連接組件，那麼主機上的符號連接路徑組件就會被解析爲 root。若是正好是在‘docker cp’的狀況下，攻擊者就能夠對主機上的全部路徑進行讀寫訪問。」

研究人員認爲針對 Docker 的這種攻擊可能會持續幾年時間。Sarai 針對這一漏洞開發了利用代碼，並表示：潛在的攻擊場景可能來自雲平臺，「最可能受到影響的是託管雲，由於它容許配置文件複製到正在運行的容器中，也容許從容器中讀取文件。」

雖然這個漏洞只有針對「docker cp」的攻擊代碼，但它是最容易被攻擊的端點。另外還有一個值得注意的點，若是選擇了一條路徑，擴展了其中的全部符號連接，並假設該路徑是安全的，那麼這是一種很是危險的行爲。

2.如何修復

「這個 Docker 漏洞雖然看起來很嚴重，但對大多數企業來講未必是緊急狀況。」 Capsule8 產品開發副總裁 Kelly Shortridge 表示：「Docker 的這個 TOCTOU 漏洞容許攻擊者不只在容器內，並且在主機上違反數據完整性和機密性。除了禁止在任何正在運行的容器上使用 docker cp 實用程序或使用攻擊保護產品以外，利用 docker cp 的 Docker 用戶很容易受到攻擊，但僅限於動機足夠強的攻擊者，他們有意願與 docker cp 競爭。」

據瞭解，Sarai 已經提交了針對該漏洞的修復建議，其中包括在使用文件系統時暫停容器。

這個問題最完整的解決方案是修改 chrootarchive，這樣全部的存檔操做都將以根目錄做爲容器 rootfs 進行 (而不是父目錄，由於父目錄是由攻擊者控制的，因此致使了這個漏洞)。不過，要對 Docker 核心部分作更改幾乎是不可能完成的事情。

退而求其次，咱們選擇了在使用文件系統時暫停容器。這種方法可以阻止最基本的攻擊，可是在某些攻擊場景下沒法發揮做用，例如 shared volume mounts。

不過，截止到目前尚未關於 Docker 官方什麼時候修復漏洞的消息。

3.網友支招

Docker 的這個漏洞公佈以後，引起了網友的普遍討論，你們各抒己見，紛紛爲解決該漏洞獻計獻策。

有網友建議：「至少在某些狀況下，符號連接攻擊是能夠經過驗證路徑的布爾函數來避免的。若是路徑不受符號連接攻擊，返回 true，不然返回 false。不受符號連接攻擊意味着遍歷路徑，檢查每一個目錄的權限，確保其不容許任何人建立符號連接。若是路徑是相對的，則將當前工做目錄做爲前綴，以便進行檢查。若是路徑包含符號連接，那麼咱們必須驗證符號連接目標的實際父目錄，且不容許替換該目標。其實，咱們只要把路徑規範化就能夠了，可是這種作法是不可取的，由於軟件必須保證已給出的路徑不變，而符號連接抽象是屬於用戶的，應該被尊重。」

也有網友建議：「在 syscall 系列中使用 open + O_PATH + *，它能夠用來得到一個已解析目錄的句柄，用戶能夠操做該目錄而不會對該句柄上的不一樣操做進行從新遍歷。或者也能夠臨時加入容器的 mount 命名空間以獲取源句柄，不過這種方法很難真正實現，由於 goroutines 沒法很好地處理每一個線程的操做。」

對於 Docker 的這個漏洞，您有何解決方法？歡迎在下方留言討論！

參考連接：

https://duo.com/decipher/dock...
https://news.ycombinator.com/...