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之路左右，确保你们安全、稳妥、无虞地继续前进❤️