【編者的話】Docker Hub是一個(gè)供Docker開發(fā)者用來上傳/下載容器鏡像的地方。為了認(rèn)識其應(yīng)對安全風(fēng)險(xiǎn)的能力如何，我們對其中的鏡像進(jìn)行了一次細(xì)致的研究。結(jié)果我們驚奇的發(fā)現(xiàn)，超過三成的官方倉庫包含的鏡像疑有高安全風(fēng)險(xiǎn)。

Docker Hub是一個(gè)供Docker開發(fā)者用來上傳/下載 容器鏡像的地方。為了認(rèn)識其應(yīng)對安全風(fēng)險(xiǎn)的能力如何，我們對其中的鏡像進(jìn)行了一次細(xì)致的研究。結(jié)果我們驚奇的發(fā)現(xiàn)，超過三成的官方倉庫包含的鏡像疑有高安全風(fēng)險(xiǎn)（如：Shellshock、Heartbleed、Poodle等）。對于普通的鏡像，即那些被Docker用戶上傳的，沒有經(jīng)過任何權(quán)威機(jī)構(gòu)驗(yàn) 證過的鏡像，這個(gè)比例高達(dá)40%（樣本的錯(cuò)誤大約在3%）。

[[135440]] 

[圖：多姿多彩的容器，圖片來源自VSMagazine]

為了開展這次研究，我們下載了Docker Hub中的的鏡像，然后分析其中的軟件包和版本。然后我們使用來自Mitre、NVD（美國國家漏洞數(shù)據(jù)庫）和Linux發(fā)行版自己的數(shù)據(jù)庫來分析哪些鏡 像易于受到攻擊。我們開發(fā)一個(gè)開源的工具 Banyan Collector，并且使用一個(gè)叫做Banyan Insights的服務(wù)來生成這個(gè)研究中的數(shù)據(jù)。

盡管我們的分析是基于公共的Docker Hub進(jìn)行的，我們預(yù)估這結(jié)果與那些使用私有容器注冊中心的企業(yè)會類似。企業(yè)通常會不斷基于那些口碑較好鏡像來部署容器，依賴這些鏡像的周期更新來獲取最 新的軟件包。盡管有這些措施，企業(yè)仍然有漏洞的威脅；更加嚴(yán)格的運(yùn)維管理加上實(shí)時(shí)的監(jiān)控對于保證安全必不可少。

在本文的剩余部分，我們簡單的從高層次介紹下安全漏洞是如何分類，描述基于分析Docker Hub上官方和普通鏡像中漏洞得到的結(jié)果，然后討論下這份研究對于運(yùn)維管理的意義。

安全漏洞的指定和分類

Mitre作為一個(gè)不以盈利為目的機(jī)構(gòu)，指定并維護(hù)一份CVE（常見安全漏洞和威脅）的列表，每一個(gè) CVE描述了在廣泛發(fā)布的軟件中的漏洞。由美國政府維護(hù)的NVD數(shù)據(jù)庫列出了每一個(gè)CVE的影響，包含其波及的軟件和相應(yīng)的修復(fù)措施（或者尚未采取修復(fù)措 施的）。每一個(gè)Linux發(fā)行版也都維護(hù)了一個(gè)發(fā)行版特定的影響和提供修復(fù)該漏洞的軟件包版本。

每一個(gè)漏洞都會被NVD和Linux的發(fā)行版指定一個(gè)分值。分值的范圍從0到10，7.0到10.0屬于高危漏洞，4.0-6.9之間的屬于中危 漏洞，0-3.9的屬于低危漏洞。這個(gè)分類考慮了一系列因素，包括利用該漏洞攻破系統(tǒng)所需要的復(fù)雜度（復(fù)雜度越低，分?jǐn)?shù)越高）和該漏洞可能會造成的影響 （影響越大，分值越高）。下面是一些例子：

1. 高危漏洞：如：ShellShock（bash）、Heartbleed（OpenSSL）
2. 中危漏洞：如：Poodle（OpenSSL）
3. 低危漏洞：如內(nèi)存中數(shù)組的內(nèi)存的分配可能會導(dǎo)致整形溢出

把漏洞劃分為高中低漏洞的做法帶有主觀性，一些公司也可能會根據(jù)自己的情況來重新分類。而且，NVD指定的分值可能跟Linux發(fā)行版中的分值不 一致，并且可能會隨著時(shí)間推移而更改。我們的研究中使用的漏洞的分值來源于Ubuntu和CentOS發(fā)行版指定的分值，對于Debian我們直接使用了 NVD數(shù)據(jù)庫中分值，因?yàn)槲覀冋也坏饺魏侮P(guān)于Debian發(fā)行版對漏洞分類比較好的數(shù)據(jù)源。我們對Docker Hub在2015的5月20日的鏡像做了一個(gè)快照，然后進(jìn)行分析。我們也試了一下其他日期，得出的結(jié)論十分相近。

對于Docker Hub中官方倉庫的評估

Docker維護(hù)著一個(gè)官方的倉庫的列表，為軟件廠商和機(jī)構(gòu)（如Canonical、Debian、Redhat等）提供了一個(gè)即時(shí)更新它們最新容器鏡像的渠道。官方倉庫可以從他們的路徑體現(xiàn)出來，他們的路徑在library的命名空間下。舉幾個(gè)例子：library/ubuntu，library/redis等。Docker Hub包含大約75個(gè)官方的倉庫（在我們寫這篇文章的時(shí)候），大概包含約1600的不同的標(biāo)簽，指向約960個(gè)不同的鏡像。

[[135441]] 

[圖一：官方有漏洞的鏡像]

圖一展示了根據(jù)分析Docker Hub上所有官方的鏡像的得出的主要結(jié)果。超過1/3的鏡像有高危漏洞，接近2/3的有高或中級危漏洞。這些統(tǒng)計(jì)數(shù)據(jù)讓人無法平靜，因?yàn)檫@些鏡像中一些也是下載量最多的鏡像（一些有幾十萬的下載量）。

如果我們只看今年創(chuàng)建的鏡像，有高危漏洞的鏡像的比例仍然超過1/3，但是含有高和中級危漏洞的鏡像接近了75%。換句話說，今年創(chuàng)建的鏡像，每四個(gè)中就有三個(gè)存在較容易被利用的漏洞，并且潛在影響非常大。

如果我們將范圍縮小到哪些標(biāo)注了lastest(最新)的鏡像，這比例分別下降到了23%和47%，這比例顯然還是很高。這更小的數(shù)據(jù)說明，Docker的用戶和維護(hù)者們，傾向于將鏡像保持到最新，但是老一些的鏡像卻被忽略；創(chuàng)建容器數(shù)量之大和速度之快，讓老的鏡像在更新的時(shí)候被忽略。

為了理解這些漏洞，特別是排名靠前的，我們做了一個(gè)詳細(xì)的影響Docker Hub的鏡像漏洞的分析：

[[135442]] 

[圖二： Docker Hub官方鏡像中有高危漏洞的鏡像]

圖二展示了該分析的主要結(jié)果，并且表一列舉了跟這些軟件包相關(guān)的主要的CVE。最近發(fā)布的存在于mercuarial的漏洞在很多鏡像中都有（大 約20%）。著名的OpenSSL漏洞如Heartbleed和Poodle，在近10%的官方鏡像中存在。一些鏡像還包含bash的 ShellShock(如Centos5.11鏡像中)漏洞，這個(gè)漏洞在7個(gè)月前就被發(fā)布了。即便一些機(jī)構(gòu)不使用這些包，但是如果不手動將這些包從容器中 移除掉也會成為惡意攻擊的羔羊。

[[135443]]

對于Docker Hub中普通倉庫的評估

除了一些官方的倉庫，Docker Hub包含了一大部普通倉庫（在寫本文的時(shí)候大約有95000個(gè)），并且有數(shù)十萬不一樣的鏡像。我們實(shí)驗(yàn)中隨機(jī)選擇了1700個(gè)鏡像，然后對他們的內(nèi)容的內(nèi)容進(jìn)行分析（誤差約百分之三）。

[[135444]] 

[圖三：有漏洞的普通鏡像]

圖三顯示了在分析了普通鏡像后得到的主要結(jié)果。大體上，漏洞的出現(xiàn)概率比官方鏡像的相比大很多。這個(gè)結(jié)果合乎預(yù)期，因?yàn)槟壳吧袥]有措施可以在將鏡像上傳到Docker Hub前可以過濾并檢查這些普通的鏡像。

大約40%的普通鏡像有高危的漏洞。即便我們只是看今年創(chuàng)建的鏡像，并且只看那些有latest標(biāo) 簽的，包含漏洞威脅的鏡像的比例仍然在30-40%之前徘徊。如果我們包含那些含有中危漏洞的鏡像，比例會迅速升到70%以上，不管哪個(gè)時(shí)間段都是如此。 盡管你可能會說，這些鏡像比起官方鏡像下載次數(shù)太少了，但是考慮到它們龐大的數(shù)量（幾十萬的規(guī)模）可以預(yù)想它們跟官方鏡像一樣使用甚廣。

我們又分析了影響普通鏡像中的高危漏洞，圖4展示了主要的結(jié)果：

[[135445]] 

[圖四：普通鏡像中含有高危漏洞的軟件包]

有趣的是，不同于官方鏡像中首要禍源在于mercurial，在這些普通的鏡像中，openSSL、bash、和apt成了禍源的榜首。我們懷疑 官方的和普通這種數(shù)字上的差異來源于發(fā)行版的差異，他們占據(jù)了這些鏡像的大部分。官方鏡像通?；贒ebian，并且其中一一大部分包含 mercurial包。而普通的鏡像，卻通?；赨buntu因而有bash、apt和/或openssl相關(guān)的漏洞。

延伸

容器技術(shù)帶來軟件開發(fā)中的變革，它提供了一個(gè)十分高效的方法，可以將開發(fā)者開發(fā)的軟件在數(shù)分鐘或者幾小時(shí)內(nèi)搬上生產(chǎn)環(huán)境運(yùn) 行，而傳統(tǒng)的方式可能需要幾天甚至數(shù)月。但是我們的數(shù)據(jù)顯示這種優(yōu)勢有其弊端，沒有謹(jǐn)慎的運(yùn)維和安全管理的措施，我們冒著讓我們的軟件生態(tài)環(huán)境更容易被攻 擊的危險(xiǎn)。

容器為運(yùn)行于不同容器之間的運(yùn)行程序提供了一層安全隔離，因而提高了安全性。然而容器還是需要和其他的容器和系統(tǒng)進(jìn)行通訊，因此，由于鏡像中存在 的安全漏洞，它們還是很容易被遠(yuǎn)程攻擊，包含那些我們沒有分析到的漏洞。再者，在多種多樣的環(huán)境中啟動大量的容器的輕便與快捷，如在你的共有云上，私有云 上，筆記本上，都讓追蹤和防護(hù)有安全漏洞的容器變得更加困難。部署容器的高效性，大大的加速了部署軟件的多樣性，結(jié)果讓環(huán)境中的新的漏洞越來越多。

使用容器的另外一個(gè)根本點(diǎn)在于，包管理已經(jīng)被轉(zhuǎn)移到了容器的內(nèi)部，而傳統(tǒng)的方式是僅僅是基于安裝在虛擬或者實(shí)體機(jī)的操作系統(tǒng)層面上。這種改變主要 根源于虛擬機(jī)和容器提供的抽象處于不同的層面。虛擬機(jī)提供的是以主機(jī)為中心的抽象，其特點(diǎn)是長期不停機(jī)一直運(yùn)行，包含的軟件包供不同應(yīng)用所需。與之相對 的，容器提供的是一個(gè)更加以進(jìn)程為主的抽象，其特點(diǎn)是短暫性，可以到處運(yùn)行，構(gòu)建后不會改變，僅僅包含運(yùn)行一個(gè)應(yīng)用所必須的軟件包。任何更新都需要重新構(gòu) 建容器，從而保持容器的不可修改性，這讓任何的漏洞同時(shí)被復(fù)制。

另外，向DevOps模式的轉(zhuǎn)變，開發(fā)者開始為他們開發(fā)的應(yīng)用的軟件包負(fù)責(zé)，這意味著現(xiàn)在開發(fā)者開始負(fù)起了維護(hù)軟件包的責(zé)任。除了操作系統(tǒng)的軟件 包，開發(fā)者在容器中可以包含應(yīng)用層面中的模塊，如pip（Python）、npm（Node.JS）和maven（Java）等，而這些都在我們的研究之 外，然而它們也可能帶來新的安全問題。因?yàn)殚_發(fā)者更加關(guān)注快速的開發(fā)出新的功，這讓保持老的鏡像更新變得更加困難，正如我們的研究呈現(xiàn)的一樣（如官方的與 201年4月發(fā)布的CentOS 5.11鏡像仍然包含Shellshock漏洞，該漏洞是八個(gè)月前，2014年9月被爆出的）。

一個(gè)很好的避免這些問題的方式是經(jīng)常用最新的更新重新構(gòu)建鏡像。重新構(gòu)建的過程必須使用發(fā)布商發(fā)布的最新的基礎(chǔ)鏡像，并且不能使用任何緩存的鏡像層（如：使用在apt-get upgrade的時(shí)候加上-no-cahce）。 但是在一旦發(fā)現(xiàn)漏洞從頭重新構(gòu)建，并且重新部署所有的容器的開銷太大，十分不切實(shí)際了—— 漏洞出的頻率太高，每天都會爆出好幾次，并且很難評估每一個(gè)安全漏洞的的影響范圍。加之，更新容器的軟件包很可能給容器中的應(yīng)用帶來負(fù)面影響和不穩(wěn)定性， 而這即使用復(fù)雜的測試也未必能捕捉到，這讓人更加不情愿經(jīng)常更新。

結(jié)論

我們的研究結(jié)果鼓勵使用嚴(yán)格的運(yùn)維管理流程，實(shí)時(shí)的分析鏡像中的內(nèi)容，清楚其中的內(nèi)容和包含的漏洞。鏡像應(yīng)該經(jīng)過安全漏洞 的掃描，并且根據(jù)漏洞的嚴(yán)重程度來標(biāo)記是否需要更新。任何重大的漏洞都應(yīng)該被及時(shí)的發(fā)現(xiàn)，并且應(yīng)該可以觸發(fā)對這些有隱患的鏡像進(jìn)行隔離機(jī)制。鏡像不僅僅應(yīng) 只從操作系統(tǒng)層面進(jìn)行掃描，也應(yīng)從應(yīng)用的層面的安全漏洞進(jìn)行掃描。這些流程應(yīng)該被集成到持續(xù)構(gòu)建的框架中，這樣在享受容器帶來的全面福利的同時(shí)，仍然保持 著好的安全實(shí)踐。