共计 3149 个字符，预计需要花费 8 分钟才能阅读完成。
美国时间 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/engin…
https://docs.docker.com/engin…
Kubernetes 用户怎么办？
使用 K8s 的用户都很清楚，K8s 并不能兼容太高的 Docker 版本，所以更新官方 Docker 版本是很难的一件事，为此 K8s 官方特意发表了一篇 Blog：https://kubernetes.io/blog/20…。主要思想就是，不要在容器中使用 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/ru… 来获取方案，值得一提的是 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 之路左右，确保大家安全、稳妥、无虞地继续前进❤️
