深度調查：24％的Docker鏡像都存在嚴重漏洞

01-29

了解容器生態系統中的漏洞情況對於網路安全的研究至關重要，今天我們就把話題轉向Docker鏡像，看看Docker官方軟體庫中當前的漏洞狀態是什麼？

Docker官方倉庫主要包含開源和商業軟體的鏡像，通常由作者或供應商管理，並包含Docker社區中使用最廣泛的鏡像。其中有 20個最流行的鏡像的的pull下載超過千萬次。目前已有越來越多地第三代配置管理軟體用這些鏡像來替代其分散式系統管理的一些功能。

很少有技術能夠像 docker 這樣一出來就受到關注，並在很短的時間裡發展壯大，而且幾乎所有的技術公司都開始使用或者希望使用。隨著 docker 的出現，配置管理、微服務、數據中心自動化、devops 多個領域都重新煥發新機，好像 IT 行業的整個架構都要重新定義一樣。

雖然Docker官方非常認真對待安全問題，但由於這個項目側重於開源性的社區化服務，所以，出現安全漏洞的鏡像也是難免的。我們在2月6日對Docker官方存儲庫做了一個掃描分析，截至目前Docker官方總共有133個倉庫，我們對其中的91個倉庫進行了掃描分析。

對標註了最新的Docker鏡像進行掃描分析，24％的最新的Docker鏡像具有高危和中危漏洞，其中 10.53％具有高危漏洞。

Ubuntu鏡像明顯比Debian鏡像有著更多的漏洞。 Debian是最不易受到攻擊鏡像，它的高危和中危漏洞最少，只有8％，相比之下比Ubuntu的高危和中危漏洞是27％。基於RHEL的漏洞分布樣本量非常小（只有4％）。

Linux操作系統的發行版本可以大體分為兩類，一類是商業公司維護的發行版本，一類是社區組織維護的發行版本，前者以著名的Redhat（RHEL）為代表，後者以Debian為代表。但目前Debian被廣泛使用，而RHEL的使用卻是最少的。 Debian是Docker官方倉庫中的主力軍，在最新標記的鏡像中佔了79％以上，而Ubuntu約佔16％，而基於RHEL的鏡像佔了剩餘的4％。

Docker的用戶和維護者們，傾向於將鏡像保持到最新，但是老一些的鏡像卻被忽略；創建容器數量之大和速度之快，讓老的鏡像在更新的時候被忽略。從安全漏洞評分系統(CVSS)來看，舊版的Debian和Ubuntu有著更多的漏洞。

Debian 8.6和Ubuntu 14.04中高危和中危漏洞的數量比它們所對應的新版本（Debian 8.7和Ubuntu 16.04）要高得多。

從圖中可以看出，新版本的安裝和更新的軟體包較少。雖然這不是漏洞多少的直接指示，但這意味大量的漏洞仍在被使用。

最常見的漏洞是「SSL Death Alert」 (即「OpenSSL紅色警戒」漏洞)，通用漏洞編號CVE-2016-8610，這是一個DoS能力的漏洞，影響針對GnuTLS，OpenSSL和NSS編譯的軟體，包括nginx提供的HTTPS服務。攻擊者可以很容易的利用該漏洞在一個消息中打包大量未定義類型警告包，使服務或進程陷入無意義的循環，從而導致佔用掉服務或進程100%的CPU使用率。

各個鏡像中最常見的普通漏洞

Debian：OpenSSL本地信息泄露漏洞(CVE-2016-7056)存在於Debian 86％的鏡像中。OpenSSL某些版本在crypto/ecdsa/ecdsa_ossl.c的signing函數存在定時攻擊漏洞，具有本地訪問權的攻擊者利用此漏洞可恢復ECDSA P-256密鑰，因此雖然存在嚴重漏洞，但不大可能影響大多數人。

Ubuntu：如上所述CVE-2016-8610存在於Ubuntu 93％的鏡像中。

RHEL：Vim 任意代碼執行漏洞(CVE-2016-1248)存在於RHEL 50％的鏡像中。

各個鏡像中最常見的高危漏洞

Webkit的Memory Corruption：Safari Webkit引擎漏洞（CVE-2016-4658），用戶點擊惡意鏈接後，就能對設備產生危害，存在於linux5％的鏡像中。該高危漏洞不僅僅對CVE中提到的蘋果產品有影響，還對XML解析程序和標記工具集libxml2有很大的危害，使得libxml功能可以被遠程訪問，包括nokogiri和解析XML / HTML的大多數開源軟體。

鑒於大量服務通過非加密信道更新，而且不檢查下載的安裝包是否真實，攻擊者利用MITM獲得多台計算機控制權的途徑也是很多的。

比如CVE-2016-1252，一個APT(高級軟體包工具)簽名繞過漏洞利用。黑客組織手握大量類似漏洞和匹配的零日漏洞利用絲毫不令人意外。攻擊者或許也用不著繞過TLS，因為大部分Linux發行版的默認APT源都不使用TLS。

CVE-2016-1252存在於linux5％的鏡像中，影響Debian 8.7和Ubuntu 16.10，Ubuntu16.04和Ubuntu14.04。

那麼，防禦者該怎樣防止這些鏡像漏洞呢？

雖然減少Docker鏡像中的漏洞有點困難，但我們這裡還是有一些預防建議，用戶可以在鏡像構建過程中對安裝軟體包進行快速更新。如果可以，可以讓你的鏡像上的程序包運行時自動更新軟體包。另外向鏡像構建過程添加漏洞分析。通過使用最小化的Linux發行版例如Alpine ，現在所有的Docker官方鏡像都使用Alpine，Alpine包含了靜態編譯的僅依賴於其所編譯的內核的二進位程序。

延伸閱讀:容器生態系統的介紹

容器引擎：

容器引擎（Engine）或者容器運行時（Runtime）是容器系統的核心，也是很多人使用「容器」這個詞語的指代對象。容器引擎能夠創建和運行容器，而容器的定義一般是以文本方式保存的，比如 Dockerfile。

雲提供商（國外篇）：

容器飛速發展的時候，很多公司反應迅速，都相繼推出了自己的公有雲或者私有雲的容器解決方案。國外比較有名的容器雲提供商，比如，Amazon EC2 Container Serveice （ECS）：雲計算巨頭 AWS 推出的容器服務，比較吸引人的是構建在 EC2 上面的 ECS 是免費的，用戶只需要為底層的 EC2 資源付費。

雲提供商（國內篇）：

每次新技術的出現都會催生一堆公司，有大公司也有創業公司。不管是大數據、Iaas、人工智慧還是現在的容器。國內公司目前對技術已經非常敏感，追逐和使用新技術的腳步從來沒有落後過。雖然現在還沒有在核心技術上制定標準和掀起浪潮，但是我相信不久之後中國會出現能夠影響世界的技術。

目前國內做容器比較知名的公司，比如，阿里云：作為國內雲服務的一哥，阿里雲反應迅速，和 docker 建立官方合作，也開始為自己的容器產品佈道。

容器編排系統:

容器與虛擬機相比有個很大的優勢就是輕量，這個特性的量變很快就引發了質變，讓容器在各個技術角落施展拳腳。不過輕量級的容很容易造成混亂，面對成百上千乃至更多的容器，必須要有統一的管理平台。所以目前容器技術最熱烈的激戰也在這個領域，所有要使用容器的企業必須要在容器管理系統做出自己的抉擇。

容器基礎鏡像:

容器雖然輕量，但是傳統的基礎鏡像並非如此。因此有很多企業嘗試著打造專門為容器而生的操作系統，希望能成為容器時代的新選擇。比如，CoreOS：以容器為中心的操作系統，配置管理、自動擴容、安全等方面有一套完整的工具。

鏡像registry:

鏡像registry是存儲鏡像的地方，可以方便地在團隊、公司或者世界各地分享容器鏡像，也是運行容器最基本的基礎設施，比如，Docker Registry：Docker 公司提供的開源鏡像伺服器，也是目前最流行的自建registry的方案。

容器監控:

cAdvisor：Google 開源的容器使用率和性能監控工具

Datadog Docker：能夠收集 docker 的運行信息，並發送到 Datadog 進行分析。

NewRelic Docker：收集 docker 的運行信息，並發送到 NewRelic 進行分析。

Sysdig：同時提供開源版本和企業版本，能夠監控容器使用率和性能，並對性能就行分析。

網路:

容器的大規模使用，也對網路提供了更高的要求。網路的不靈活也是很多企業的短板，目前也有很多公司和項目在嘗試解決這些問題，希望提出容器時代的網路方案。比如：

Weave Net：weaveworks給出的網路的方案，使用vxlan技術，支持網路的隔離和安全。

服務發現:

容器和微服務的結合創造了另外的熱潮，也讓服務發現成功了熱門名詞。可以輕鬆擴展微服務的同時，也要有工具來實現服務之間相互發現的需求。目前主要有三種工具，當然它們可能已經集成到其他的容器管理系統中。比如：

etcd：CoreOS 開源的分散式 key-value 存儲，通過 HTTP 協議提供服務，因此使用起來簡單。但是 etcd只是一個key-value存儲，默認不支持服務發現，需要三方工具來集成。kubernetes 默認就使用 etcd 作為存儲。

本文參考來源於federacy，如若轉載，請註明來源於嘶吼：深度調查：24％的Docker鏡像都存在嚴重漏洞更多內容請關注「嘶吼專業版」——Pro4hou