【編者的話】Docker Hub是一個供Docker開發者用來上傳/下載容器鏡像的地方。為了認識其應對安全風險的能力如何，我們對其中的鏡像進行了一次細致的研究。結果我們驚奇的發現，超過三成的官方倉庫包含的鏡像疑有高安全風險。

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

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

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

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

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

安全漏洞的指定和分類

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

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

高危漏洞：如：ShellShock（bash）、Heartbleed（OpenSSL）

中危漏洞：如：Poodle（OpenSSL）

低危漏洞：如內存中數組的內存的分配可能會導致整形溢出

把漏洞劃分為高中低漏洞的做法帶有主觀性，一些公司也可能會根據自己的情況來重新分類。而且，NVD指定的分值可能跟Linux發行版中的分值不 一致，并且可能會隨著時間推移而更改。我們的研究中使用的漏洞的分值來源于Ubuntu和CentOS發行版指定的分值，對于Debian我們直接使用了 NVD數據庫中分值，因為我們找不到任何關于Debian發行版對漏洞分類比較好的數據源。我們對Docker Hub在2015的5月20日的鏡像做了一個快照，然后進行分析。我們也試了一下其他日期，得出的結論十分相近。

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

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

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

圖一展示了根據分析Docker Hub上所有官方的鏡像的得出的主要結果。超過1/3的鏡像有高危漏洞，接近2/3的有高或中級危漏洞。這些統計數據讓人無法平靜，因為這些鏡像中一些也是下載量最多的鏡像（一些有幾十萬的下載量）。

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

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

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

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

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

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

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

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

圖三顯示了在分析了普通鏡像后得到的主要結果。大體上，漏洞的出現概率比官方鏡像的相比大很多。這個結果合乎預期，因為目前尚沒有措施可以在將鏡像上傳到Docker Hub前可以過濾并檢查這些普通的鏡像。

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

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

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

有趣的是，不同于官方鏡像中首要禍源在于mercurial，在這些普通的鏡像中，openSSL、bash、和apt成了禍源的榜首。我們懷疑 官方的和普通這種數字上的差異來源于發行版的差異，他們占據了這些鏡像的大部分。官方鏡像通常基于Debian，并且其中一一大部分包含 mercurial包。而普通的鏡像，卻通常基于Ubuntu因而有bash、apt和/或openssl相關的漏洞。

延伸

容器技術帶來軟件開發中的變革，它提供了一個十分高效的方法，可以將開發者開發的軟件在數分鐘或者幾小時內搬上生產環境運 行，而傳統的方式可能需要幾天甚至數月。但是我們的數據顯示這種優勢有其弊端，沒有謹慎的運維和安全管理的措施，我們冒著讓我們的軟件生態環境更容易被攻 擊的危險。

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

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

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

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

結論

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