資訊專欄INFORMATION COLUMN
摘要：產(chǎn)品開發(fā)副總裁表示的這個(gè)漏洞允許攻擊者不僅在容器內(nèi)，而且在主機(jī)上違反數(shù)據(jù)完整性和機(jī)密性。據(jù)了解，已經(jīng)提交了針對(duì)該漏洞的修復(fù)建議，其中包括在使用文件系統(tǒng)時(shí)暫停容器。
毫不夸張的說，所有的 Docker 版本都存在同一個(gè)漏洞，這個(gè)漏洞可以讓攻擊者獲得主機(jī)服務(wù)器上所有路徑的讀寫訪問權(quán)限。據(jù)了解，之所以會(huì)出現(xiàn)該漏洞，主要是因?yàn)?Docker 軟件處理某些符號(hào)鏈接的方式，而這些符號(hào)鏈接中往往會(huì)包含有到其他目錄或文件的路徑的文件。1.事件回溯
研究員 Aleksa Sarai 發(fā)現(xiàn)，在某些情況下，攻擊者可以在路徑解析時(shí)間和操作時(shí)間之間的短時(shí)間窗口將自己的符號(hào)鏈接插入到路徑中。這是 TOCTOU 問題的一個(gè)變體，特別是“docker cp”命令，它可以將文件從主機(jī)復(fù)制到容器，或從容器復(fù)制到主機(jī)。
Sarai 表示，“這次攻擊的基本前提是 FollowSymlinkInScope 遭受了相當(dāng)根本的 TOCTOU 攻擊。FollowSymlinkInScope 的目的是獲取給定路徑并安全解析，就好像進(jìn)程位于容器內(nèi)部一樣。完整路徑被解析之后，路徑會(huì)被傳遞，同時(shí)會(huì)進(jìn)行一些操作（例如，在’docker cp’的情況下，它會(huì)在創(chuàng)建流式傳輸?shù)娇蛻舳说拇鏅n時(shí)打開）。”
“如果攻擊者在解析之后、操作之前，向路徑添加符號(hào)鏈接組件，那么主機(jī)上的符號(hào)鏈接路徑組件就會(huì)被解析為 root。如果正好是在‘docker cp’的情況下，攻擊者就可以對(duì)主機(jī)上的所有路徑進(jìn)行讀寫訪問。”
研究人員認(rèn)為針對(duì) Docker 的這種攻擊可能會(huì)持續(xù)幾年時(shí)間。Sarai 針對(duì)這一漏洞開發(fā)了利用代碼，并表示：潛在的攻擊場(chǎng)景可能來自云平臺(tái)，“最可能受到影響的是托管云，因?yàn)樗试S配置文件復(fù)制到正在運(yùn)行的容器中，也允許從容器中讀取文件。”
雖然這個(gè)漏洞只有針對(duì)“docker cp”的攻擊代碼，但它是最容易被攻擊的端點(diǎn)。另外還有一個(gè)值得注意的點(diǎn)，如果選擇了一條路徑，擴(kuò)展了其中的所有符號(hào)鏈接，并假設(shè)該路徑是安全的，那么這是一種非常危險(xiǎn)的行為。
2.如何修復(fù)“這個(gè) Docker 漏洞雖然看起來很嚴(yán)重，但對(duì)大多數(shù)企業(yè)來說未必是緊急情況。” Capsule8 產(chǎn)品開發(fā)副總裁 Kelly Shortridge 表示：“Docker 的這個(gè) TOCTOU 漏洞允許攻擊者不僅在容器內(nèi)，而且在主機(jī)上違反數(shù)據(jù)完整性和機(jī)密性。除了禁止在任何正在運(yùn)行的容器上使用 docker cp 實(shí)用程序或使用攻擊保護(hù)產(chǎn)品之外，利用 docker cp 的 Docker 用戶很容易受到攻擊，但僅限于動(dòng)機(jī)足夠強(qiáng)的攻擊者，他們有意愿與 docker cp 競(jìng)爭(zhēng)。”
據(jù)了解，Sarai 已經(jīng)提交了針對(duì)該漏洞的修復(fù)建議，其中包括在使用文件系統(tǒng)時(shí)暫停容器。
這個(gè)問題最完整的解決方案是修改 chrootarchive，這樣所有的存檔操作都將以根目錄作為容器 rootfs 進(jìn)行 (而不是父目錄，因?yàn)楦改夸浭怯晒粽呖刂频模詫?dǎo)致了這個(gè)漏洞)。不過，要對(duì) Docker 核心部分做更改幾乎是不可能完成的事情。
退而求其次，我們選擇了在使用文件系統(tǒng)時(shí)暫停容器。這種方法能夠阻止最基本的攻擊，但是在某些攻擊場(chǎng)景下無法發(fā)揮作用，例如 shared volume mounts。
不過，截止到目前還沒有關(guān)于 Docker 官方何時(shí)修復(fù)漏洞的消息。
3.網(wǎng)友支招Docker 的這個(gè)漏洞公布之后，引發(fā)了網(wǎng)友的廣泛討論，大家各抒己見，紛紛為解決該漏洞獻(xiàn)計(jì)獻(xiàn)策。
有網(wǎng)友建議：“至少在某些情況下，符號(hào)鏈接攻擊是可以通過驗(yàn)證路徑的布爾函數(shù)來避免的。如果路徑不受符號(hào)鏈接攻擊，返回 true，否則返回 false。不受符號(hào)鏈接攻擊意味著遍歷路徑，檢查每個(gè)目錄的權(quán)限，確保其不允許任何人創(chuàng)建符號(hào)鏈接。如果路徑是相對(duì)的，則將當(dāng)前工作目錄作為前綴，以便進(jìn)行檢查。如果路徑包含符號(hào)鏈接，那么我們必須驗(yàn)證符號(hào)鏈接目標(biāo)的實(shí)際父目錄，且不允許替換該目標(biāo)。其實(shí)，我們只要把路徑規(guī)范化就可以了，但是這種做法是不可取的，因?yàn)檐浖仨毐ＷC已給出的路徑不變，而符號(hào)鏈接抽象是屬于用戶的，應(yīng)該被尊重。”
也有網(wǎng)友建議：“在 syscall 系列中使用 open + O_PATH + *，它可以用來獲得一個(gè)已解析目錄的句柄，用戶可以操作該目錄而不會(huì)對(duì)該句柄上的不同操作進(jìn)行重新遍歷。或者也可以臨時(shí)加入容器的 mount 命名空間以獲取源句柄，不過這種方法很難真正實(shí)現(xiàn)，因?yàn)?goroutines 無法很好地處理每個(gè)線程的操作。”
對(duì)于 Docker 的這個(gè)漏洞，您有何解決方法？歡迎在下方留言討論！
參考鏈接：https://duo.com/decipher/dock...
https://news.ycombinator.com/...
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/74718.html
摘要：產(chǎn)品開發(fā)副總裁表示的這個(gè)漏洞允許攻擊者不僅在容器內(nèi)，而且在主機(jī)上違反數(shù)據(jù)完整性和機(jī)密性。據(jù)了解，已經(jīng)提交了針對(duì)該漏洞的修復(fù)建議，其中包括在使用文件系統(tǒng)時(shí)暫停容器。 毫不夸張的說，所有的 Docker 版本都存在同一個(gè)漏洞，這個(gè)漏洞可以讓攻擊者獲得主機(jī)服務(wù)器上所有路徑的讀寫訪問權(quán)限。據(jù)了解，之所以會(huì)出現(xiàn)該漏洞，主要是因?yàn)?Docker 軟件處理某些符號(hào)鏈接的方式，而這些符號(hào)鏈接中往往會(huì)包...
摘要：年月日，研究人員通過郵件列表披露了容器逃逸漏洞的詳情，根據(jù)的規(guī)定會(huì)在天后也就是年月日公開。在號(hào)當(dāng)天已通過公眾號(hào)文章詳細(xì)分析了漏洞詳情和用戶的應(yīng)對(duì)之策。 美國(guó)時(shí)間2019年2月11日晚，runc通過oss-security郵件列表披露了runc容器逃逸漏洞CVE-2019-5736的詳情。runc是Docker、CRI-O、Containerd、Kubernetes等底層的容器運(yùn)行時(shí)，此...
摘要：漏洞披露后，在第一時(shí)間發(fā)布了，用戶可升級(jí)到此版本以修復(fù)該漏洞。年年底被爆出的首個(gè)嚴(yán)重安全漏洞，就是由聯(lián)合創(chuàng)始人及首席架構(gòu)師發(fā)現(xiàn)的。年月被爆出儀表盤和外部代理安全漏洞時(shí)，也是第一時(shí)間向用戶響應(yīng)，確保所有和的用戶都完全不被漏洞影響。 runC是一個(gè)根據(jù)OCI（Open Container Initiative）標(biāo)準(zhǔn)創(chuàng)建并運(yùn)行容器的CLI工具，目前Docker引擎內(nèi)部也是基于runc構(gòu)建的。...
閱讀 3876·2021-07-28 18:10
閱讀 2583·2019-08-30 15:44
閱讀 1094·2019-08-30 14:07
閱讀 3466·2019-08-29 17:20
閱讀 1583·2019-08-26 18:35
閱讀 3542·2019-08-26 13:42
閱讀 1821·2019-08-26 11:58
閱讀 1594·2019-08-23 18:33
