Docker Hub 中超過 30% 的官方映象包含高危漏洞

【編者的話】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的屬於低危漏洞。這個分類考慮了一系列因素，包括利用該漏洞攻破系統所需要的複雜度（複雜度越低，分數越高）和該漏洞可能會造成的影響 （影響越大，分值越高）。下面是一些例子：

1. 高危漏洞：如：ShellShock（bash）、Heartbleed（OpenSSL）
2. 中危漏洞：如：Poodle（OpenSSL）
3. 低危漏洞：如記憶體中陣列的記憶體的分配可能會導致整形溢位

把漏洞劃分為高中低漏洞的做法帶有主觀性，一些公司也可能會根據自己的情況來重新分類。而且，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）。 但是在一旦發現漏洞從頭重新構建，並且重新部署所有的容器的開銷太大，十分不切實際了—— 漏洞出的頻率太高，每天都會爆出好幾次，並且很難評估每一個安全漏洞的的影響範圍。加之，更新容器的軟體包很可能給容器中的應用帶來負面影響和不穩定性， 而這即使用複雜的測試也未必能捕捉到，這讓人更加不情願經常更新。

結論

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