runc容器逃逸漏洞最強後續：應對之策彙總與熱點疑問解答

美國時間2019年2月11日晚，runc經過oss-security郵件列表披露了runc容器逃逸漏洞CVE-2019-5736的詳情。runc是Docker、CRI-O、Containerd、Kubernetes等底層的容器運行時，這次安全漏洞無可避免地會影響大多數Docker與Kubernetes用戶，也所以爲整個業界高度關注。

漏洞披露後，Docker在第一時間發佈了兩個版本18.06.2和18.09.2，這兩個版本均可以修復runc漏洞。Rancher Labs極速響應，Rancher Kubernetes管理平臺和RancherOS操做系統均在不到一天時間內緊急更新，是業界第一個緊急發佈新版本支持Docker補丁版本的平臺，並持嚴謹態度在oss-security郵件列表披露漏洞後的五小時內連夜郵件通知全部Rancher用戶這次漏洞的詳情及應對之策。

更值得一提的是，儘管Docker發佈了修復版本，但由於不是全部用戶都能輕易將生產環境中的Docker版本升至最新，Rancher幫忙將修復程序反向移植到全部版本的Docker並提供給用戶。且目前Docker官方提供的修復版本並不支持3.x內核（只兼容4.x內核），而runc的開發者特地向Rancher提交了支持3.x內核的PR，目前PR已合併，Rancher提供的方案現已能夠支持3.x內核。

runc安全漏洞事件背景

runc是一個根據OCI(Open Container Initiative)標準建立並運行容器的CLI tool，目前Docker引擎內部也是基於runc構建的。2019年2月11日，研究人員經過oss-security郵件列表披露了runc容器逃逸漏洞的詳情，根據OpenWall的規定EXP會在7天后也就是2019年2月18日公開。

此漏洞容許以root身份運行的容器以特權用戶身份在主機上執行任意代碼。這意味着容器可能會破壞Docker主機（覆蓋Runc CLI），而所須要的只是可以使用root來運行容器。攻擊者可使用受感染的Docker鏡像或對未受感染的正在運行的容器運行exec命令。

Rancher在12號當天已經過公衆號文章詳細分析了漏洞詳情和用戶的應對之策。相信目前大部分用戶已經對漏洞已經有了初步的瞭解，甚至在Github上已經有人提交了EXP代碼。Rancher在第一時間完成了補丁修復，並向企業用戶推送的修復方案。同時在咱們也收到了大量來自社區用戶在後臺的提問，爲了疏解種種謎團，這篇後續文章，咱們將選取你們重點關注的一些熱點疑問進行進一步的解答。

熱點問題

非特權容器也能發起攻擊嗎？

答案是確定的，Rancher安全團隊在第一時間作了一些測試，即便運行容器時不使用privileged參數，同樣能夠發起攻擊。由於這個漏洞核心要素在於，容器內的用戶是否對runc有訪問權限， 容器內默認是root用戶，只是這個root是受限制的root，可是它是具備對runc的訪問權限，因此必定能夠發起攻擊。

主機上不用root用戶啓動容器能夠避免攻擊嗎？

答案是沒法避免，如上一個問題分析，它和容器內的用戶有關，至於在主機上以什麼用戶啓動無關。Rancher安全團隊在Ubuntu系統上作了測試，即便使用ubuntu用戶啓動容器， 依然能夠完成對runc的替換。

更新官方Docker的注意事項

Docker也在第一時間發佈了兩個版本18.06.2和18.09.2，這兩個版本均可以修復runc漏洞，可是你須要注意的是他們都只兼容4.x內核，若是你的系統依然使用的3.x內核， 請謹慎使用，由於它基本不會起做用，甚至可能致使額外的問題。

Ubuntu 14.04 customers using a 3.13 kernel will need to upgrade to a supported Ubuntu 4.x kernel

參考兩個版本的RN：

• https://docs.docker.com/engine/release-notes/#18062

• https://docs.docker.com/engine/release-notes/#18092

Kubernetes用戶怎麼辦？

使用K8s的用戶都很清楚，K8s並不能兼容過高的Docker版本，因此更新官方Docker版本是很難的一件事，爲此K8s官方特地發表了一篇Blog：https://kubernetes.io/blog/2019/02/11/runc-and-cve-2019-5736/ 。 主要思想就是，不要在容器中使用root，它推薦的方案是使用PodSecurityPolicy。固然不少用戶修改PodSecurityPolicy後可能會引起各類問題，因此它也推薦用戶更新Docker。 同時它也提到，不能更新Docker的用戶，可使用Rancher提供的方案，Rancher爲每一個版本都移植了補丁：

If you are unable to upgrade Docker, the Rancher team has provided backports of the fix for many older versions at github.com/rancher/runc-cve.

如何使用Rancher提供的補丁？

如上一個問題提到的，用戶能夠直接訪問https://github.com/rancher/runc-cve 來獲取方案，值得一提的是Rancher爲3.x和4.x內核用戶都提供了補丁版本。

To install, find the runc for you docker version, for example Docker 17.06.2 for amd64 will be runc-v17.06.2-amd64.

For Linux 3.x kernels use the binaries that end with no-memfd_create. Then replace the docker-runc on your host with the patched one.

如何正確使用EXP？

首先不建議你們普遍傳播EXP，由於它每暴露一次，就爲總體環境增長了一絲風險，咱們能夠研究學習可是不要惡意傳播。 咱們在後臺看到有些人問到，他們使用了某些EXP代碼，攻擊沒有成功，想知道是否是本身的系統是安全的，不用考慮升級。 Rancher安全團隊也查看了一些外部公開的EXP，有些EXP是不完整的，它可能只能在某些環境上起做用。 好比利用libseccomp的EXP，就沒法在靜態編譯的runc上起做用，咱們使用了一些公開的EXP就沒法在RancherOS上完成攻擊。 雖然不一樣版本的Docker都使用runc，可是不一樣的操做系統使用runc的方式不一樣，有的使用static runc，有的使用dynamic runc。 因此不能以某些公開的EXP的執行結果爲標準，來判斷本身系統是否存在漏洞。

守護用戶的K8S之路

Rancher Kubernetes平臺擁有着超過一億次下載量，咱們深知安全問題對於用戶而言的重要性，更遑論那些經過Rancher平臺在生產環境中運行Docker及Kubernetes的數千萬用戶。

2018年年末Kubernetes被爆出的首個嚴重安全漏洞CVE-2018-1002105，就是由Rancher Labs聯合創始人及首席架構師Darren Shepherd發現的。

2019年1月Kubernetes被爆出儀表盤和外部IP代理安全漏洞時，Rancher Labs也是第一時間向用戶響應，確保了全部Rancher 2.x和1.6.x的用戶都徹底不被漏洞影響。

負責、可靠、快速響應、以用戶爲中心，是Rancher始終不變的初心；在每一次業界出現問題時，嚴謹踏實爲用戶提供相應的應對之策，也是Rancher一如既往的行事之道。將來，Rancher也將一如既往支持與守護在用戶的K8S之路左右，確保你們安全、穩妥、無虞地繼續前進❤️