内容简介：美国时间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 Kuberne
美国时间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：
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之路左右，确保大家安全、稳妥、无虞地继续前进:heart:
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
数据密集型应用系统设计
Martin Kleppmann / 赵军平、李三平、吕云松、耿煜 / 中国电力出版社 / 2018-9-1 / 128
全书分为三大部分： 第一部分，主要讨论有关增强数据密集型应用系统所需的若干基本原则。首先开篇第1章即瞄准目标：可靠性、可扩展性与可维护性，如何认识这些问题以及如何达成目标。第2章我们比较了多种不同的数据模型和查询语言，讨论各自的适用场景。接下来第3章主要针对存储引擎，即数据库是如何安排磁盘结构从而提高检索效率。第4章转向数据编码（序列化）方面，包括常见模式的演化历程。 第二部分，我们将......一起来看看 《数据密集型应用系统设计》 这本书的介绍吧!
