毫不夸張的說，所有的 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/docker-bug-allows-root-access-to-host-file-system
https://news.ycombinator.com/item?id=20031403