Docker Hub中超過30%的官方鏡像包含高安全風險

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)，和maven(java)，而這些都在我們的研究之外，然而它們也可能帶來新的安全漏洞。因為開發者更加關注快速的將新的功能給盡早的弄出來，這讓保持老的鏡像更新變得更加困難，正如我們的研究呈現的一樣（如官方的與201年4月發布的Centos 5.11鏡像仍然包含shellshock漏洞，該漏洞是八個月前，2014年9月被爆出的）。

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

結論

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