0x00 漏洞背景
runc是一个根据OCI(Open Container Initiative)标准创建并运行容器的CLI tool。目前docker引擎内部也是基于runc构建的。2019年2月11日，研究人员通过oss-security邮件列表披露了runc容器逃逸漏洞的详情，根据OpenWall的规定EXP会在7天后也就是2019年2月18日公开。经360CERT研判，该漏洞可能影响广大云服务厂商，危害严重。
0x01 漏洞影响
该漏洞允许恶意容器(以最少的用户交互)覆盖host上的runc文件，从而在host上以root权限执行代码。在下面两种情况下，通过用户交互可以在容器中以root权限执行任意代码：
1.使用攻击者控制的镜像创建新容器。
2.进入到攻击者之前具有写入权限的现有容器中(docker exec)。
默认AppArmor策略不会阻止此漏洞。对于Fedora上的moby-engine软件包，默认SELinux策略也不会阻止此漏洞(因为容器进程似乎作为container_runtime_t运行)；对于Fedora上的docker软件包和podman软件包不受此漏洞影响(它们将容器进程作为container_t运行)。但是可以通过正确使用用户命名空间(其中host的root未映射到容器的用户命名空间)来阻止此漏洞。
目前除了runc之外，Apache Mesos和LXC也确认受到影响。攻击只可能发生在特权容器中，因为它需要host上的root权限来覆盖runc文件。LXC认为特权容器是不安全的，所以没有分配CVE来处理此问题，但是也已经发布了补丁。
0x02 漏洞细节
攻击者可以将容器中的目标文件替换成指向runc的自己的文件来欺骗runc执行自己。比如目标文件是/bin/bash，将它替换成指定解释器路径为#!/proc/self/exe的可执行脚本，在容器中执行/bin/bash时将执行/proc/self/exe，它指向host上的runc文件。然后攻击者可以继续写入/proc/self/exe试图覆盖host上的runc文件。但是一般来说不会成功，因为内核不允许在执行runc时覆盖它。为了解决这个问题，攻击者可以使用O_PATH标志打开/proc/self/exe的文件描述符，然后通过/proc/self/fd/<nr>使用O_WRONLY标志重新打开文件，并尝试在一个循环中从一个单独的进程写入该文件。当runc退出时覆盖会成功，在此之后，runc可以用来攻击其它容器或host。
0x03 漏洞补丁
lxc使用memfd_create系统调用创建匿名的内存文件，然后将该文件密封以防止修改。执行的是这个密封的内存中的文件而不是磁盘上的文件。同样，从特权容器到host文件的任何写操作都将写入内存中的文件而不是磁盘上的文件从而保证其完整性。由于内存中的文件是密封的，写入操作也将失败。
runc中的修补方案类似。
0x04 修复建议
目前漏洞细节已经披露，EXP也即将公开，不排除攻击者在EXP公开之前就根据漏洞细节自己编写EXP发动攻击的可能。360CERT建议使用基于lxc和runc容器技术的相关厂商和开发者及时进行升级，同时关注后续EXP，以对升级结果进行验证。其它厂商和开发者也需要关注该漏洞进展，未来不排除有更多的容器系统受到该漏洞影响。
0x05 时间线
2019-02-11 研究人员通过oss-security邮件列表披露漏洞的详情
2019-02-11 360CERT发布预警通告