上周，SUSE Linux GmbH高级软件工程师Aleksa Sarai公布了影响Docker, containerd, Podman, CRI-O等默认运行时容器runc的严重漏洞CVE-2019-5736。

漏洞会对IT运行环境带来威胁，漏洞利用会触发容器逃逸、影响整个容器主机的安全，最终导致运行在该主机上的其他容器被入侵。漏洞影响AWS, Google Cloud等主流云平台。更多关于CVE-2019-5736信息参见runC容器逃逸漏洞分析（CVE-2019-5736）http://www.4hou.com/vulnerable/16165.html

日前，该容器逃逸漏洞的PoC利用代码已在GitHub上公布。

这是CVE-2019-5736漏洞利用的Go语言实现。漏洞利用是通过覆写和执行主机系统runc二进制文件完成的。

工作原理

本PoC共有漏洞利用的两个用例。

第一个是一个trap。攻击者需要获取容器中的命令执行，并监听一个恶意二进制文件。如果有攻击者或受害者使用docker exec进入容器，就会触发漏洞利用，恶意代码就可以以root权限运行。

第二个创建了一个恶意Docker镜像。如果该恶意镜像运行就会触发漏洞利用。

漏洞的利用需要在容器内获取root(uid 0)权限。

详细解释

本PoC是使用lxc项目的commit创建的。

如果目标二进制文件是/bin/bash，就会被指定路径为#!/proc/self/exe (/proc/self/exec是kernel为每个进程创建的符号链接，指向该进程执行的热禁止文件) 的进程取代。当容器中执行/bin/bash时，执行runc二进制文件的/proc/self/exe就会被执行。

研究人员用执行启动Docker exec进程的二进制文件的#!/proc/self/exe来覆写了容器中的 /bin/sh。

这样攻击者就可以进一步写入目标/proc/self/exe并尝试运行runc二进制文件。但一般来说这样并不能成功，因为当runC运行时kernel是不允许它被覆写的。因此攻击者打开了一个使用O_PATH flag的/proc/self/exe的文件描述器，然后通过/proc/self/fd/以O_WRONLY的形式重新打开二进制文件，并尝试从一个单独进程的写循环来写入。

注释：上面的部分内容并不是完全准确的。比如在获取runcinit的文件描述器时并不一定需要使用O_PATH flag。而且也不需要在另一个进程中创建写循环。获取/proc/PID/exe的file handle也可以获取runcinit的文件描述器。然后使用handle来获取/proc/self/fd/FILEDESCRIPTOR的file handle。下面是研究人员使用的file handle：

最后当runc运行时就可以PoC就可以成功转型。然后runc二进制文件就被入侵了，可以被用于攻击其他容器或主机本身。

如果可以写入该file handle，那么就可以覆写主机上的runc二进制文件。就可以以root权限运行任意命令了。

恶意Docker镜像示例

研究人员认为恶意Docker镜像是一个非常危险的场景。只要运行恶意容器镜像就可以以root权限运行代码。详细解释参见https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html。

Docker发布了v18.09.2 版本来解决这一问题，但有专家认为有成千上万台Docker daemons仍然存在被利用的风险，其中大多数主机位于美国和中国。