runC是一套位于Docker、CRI-O、containerd以及Kubernetes等基础设施与引擎之下的底层容器运行时。
runC团队的Aleksa Sarai解释称，“此项安全漏洞允许恶意容器（在最低用户交互等级下）覆盖主机runC二进制文件，这意味着攻击者将借此获得在主机上以root层级执行代码的权限。”
“具体来讲，攻击者能够利用一套其可以控制的镜像创建新的容器，或者是向其能够访问的现有容器之内添加docker exec文件。在这类情况下的任意容器当中，该攻击者都将能够通过当前用户交互等级以root权限运行任意命令（无论命令本身是否由攻击者所控制）。”
他同时发现，类似的安全漏洞也存在于LXC以及Apache Mesos项目当中。他解释称，“除了少数事先已经采取相应缓解措施的运行时项目”，这个问题有可能会影响到当前市面上的大多数其它容器运行时方案。
目前面向runC以及LXC的修复补丁都已经正式发布。
红帽公司警告称，用户需要更新“docker”与“runc”软件包（您可以点击此处[1]了解更多与此项漏洞相关的安全影响）。另外，Debian与Ubuntu也在着手发布修复补丁。
Docker v18.09.2 版本已经顺利修复了这一漏洞。（您可点击此处[2]获取适用于同Docker打包发布的旧版runC的补丁。）
AWS方面已经针对旗下各款产品（包括Amazon Linux、Amazon ECS、Amazon EKS以及AWS Fargate等）的用户群体发布了关于如何修复及缓解此项漏洞的说明与建议。Google Cloud也发布了同样的指导性信息。
Twistlock公司CTO John Morello表示，此次安全漏洞可以说是多年以来容器领域曝出的最为严重的问题。
他在接受采访时指出，“如果组织运行那些从不受信任的来源处获取到的镜像，那么其主机很有可能被攻击者所全面接收，这意味着此项安全漏洞无疑是一种相对易被利用的真正威胁。考虑到相对简单的攻击实现方式以及相关利用代码在未来一周之内就有可能出现，我们也许马上就会看到与之相关的实际攻击活动。”
“在完成修复之前，容器环境下的大多数默认配置都易受此类攻击的影响。当然，一部分关键性缓解措施——例如坚决不运行不可靠的镜像——将能够显著降低此漏洞遭到利用的可能性。”
红帽公司容器子系统团队首席产品经理Scott McCarty则指出，这并不是容器运行时环境中曝出的第一个重大缺陷，也绝对不可能是最后一个。
他总结称，“正如去年掀起轩然大波的Spectre/Meltdown漏洞代表着安全研究工作开始从软件架构转向处理器架构一样，我们预计在此次事件之后，像runC这样的底层容器运行时以及Docker等容器引擎未来也将受到研究人员以及潜在恶意攻击者们的高度重视。”
红帽公司产品安全保障项目经理Chris Robinson评论称，“随着整个行业以及我们的客户逐步转向超密集型架构，逃逸与权限升级问题将带来远高于传统裸机系统中类似问题的广泛影响。具体来讲，容器化背景下的安全隐患将带来更为广泛的威胁范围，而不再像过去那样仅仅局限于单一系统。”
“值得庆幸的是，对于红帽客户而言，红帽企业Linux为我们的云平台及容器产品提供了更为安全的基础。默认启用的SELinux策略能够帮助我们的用户缓解此类问题，同时确保他们能够根据实际业务需求规划时间以部署软件更新工作。”
内容更新（2019年2月13日凌晨2：20）：
Sarai在开源安全邮件列表中宣布，“已经有禁令范围之外的人士发布了面向CVE-2019-5736漏洞的概念验证方案（尽管并没有使用相同的攻击载体，但仍具有高度相关性）。由于初始研究人员已经发布了相关博文[3]以详尽解释这项漏洞，我决定尽早发布漏洞利用代码，从而最大限度帮助各相关方了解问题的产生原因。”
相关链接：
https://www.redhat.com/en/blog/it-starts-linux-how-red-hat-helping-counter-linux-container-security-flaws
https://github.com/rancher/runc-cve
https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
原文链接：https://www.helpnetsecurity.com/2019/02/12/runc-container-escape-flaw/