本文仅用于学习研究为目的，禁止用于任何非法目的，否则后果自负

近日Containerd公布了一个安全漏洞，攻击者通过构造一个恶意镜像，能够在普通用户进行pull和提取镜像时，修改用户宿主机上现存文件的文件权限。该漏洞不能直接读取，写入或者执行用户的文件。

CVE-2021-32760漏洞被评估为5.0 MEDIUM中危，关于该漏洞的详细信息，请参见https://github.com/containerd/containerd/security/advisories/GHSA-c72p-9xmj-rx3w。

从官方的patch可以看出，之前只考虑了硬链接和非软连接的情况，当在打包的时候采用软链接+硬链接时则会绕过该检查。

修复之前的代码：

修复之后的代码：

通过构造软连接+硬链接的方式将容器镜像内部的文件链接到宿主机上的文件构造恶意镜像，能够在Containerd拉取和提取镜像的时候修改宿主机文件权限，官方给的测试用例如下：

在镜像中创建admin目录，此目录需要宿主机也存在，并构造恶意链接：

在宿主机创建poc和ep两个文件，poc赋予400权限：

打包镜像后，用containerd进行拉取：

查看poc文件权限：

可以看到文件权限变为777，利用成功。

在这个漏洞分析完之后，不免产生一个疑问，docker和containerd都存在拉取并提取镜像的行为，为什么这个漏洞只影响containerd，不影响docker呢？

让我们分别看下docker和containerd对镜像进行提取时的逻辑：

containerd：

首先containerd在处理tar包时，会对tar包中的文件进行遍历，刚开始发现此处其实存在目录穿越的问题，后来仔细研究发现在使用相对路径时候，fs.RootPath在所有的路径前面都加上了root目录，限制了目录的范围，无法进行穿越，之后createTarFile函数对压缩包的不同文件类型都进行了处理，当文件类型是软链接时：

直接对软连接和path进行了链接，并未对链接后的路径进行限制，因此此处其实是存在目录穿越漏洞的，在有漏洞的handleLChmod代码中，对tar文件的文件类型进行了判断，并未对链接的文件类型进行限制，因此当采用软连接+硬链接时，会直接链接到宿主机的文件中，从而将宿主机的文件权限进行修改。

值得注意的是，此处containerd对使用软链接的目录穿越的问题仍未修复，修复后的代码只是对文件的类型进行了判断，因此还是可以通过软连接+硬链接的方式链接到宿主机的文件，只不过干不了什么？

再来看看docker这部分逻辑的实现代码：

可以看到此处docker对于路径的限制其实是比containerd更严格的，除了对在tar包的文件路径前面加上了dest的限制，并且禁止使用..的相对路径，因此在docker中这部分逻辑不存在目录穿越的问题。再看下对于链接文件的处理情况：

可以看到其实docker是有相似的处理逻辑，只不过docker的处理逻辑更加严格，对链接文件进行了限制，无法链接到宿主机的任意文件中了，因此这个漏洞不影响docker。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课