毫不夸张的说，所有的 Docker 版本都存在同一个漏洞，这个漏洞可以让攻击者获得主机服务器上所有路径的读写访问权限。据了解，之所以会出现该漏洞，主要是因为 Docker 软件处理某些符号链接的方式，而这些符号链接中往往会包含有到其他目录或文件的路径的文件。
1.事件回溯
研究员 Aleksa Sarai 发现，在某些情况下，攻击者可以在路径解析时间和操作时间之间的短时间窗口将自己的符号链接插入到路径中。这是 TOCTOU 问题的一个变体，特别是“docker cp”命令，它可以将文件从主机复制到容器，或从容器复制到主机。
Sarai 表示，“这次攻击的基本前提是 FollowSymlinkInScope 遭受了相当根本的 TOCTOU 攻击。FollowSymlinkInScope 的目的是获取给定路径并安全解析，就好像进程位于容器内部一样。完整路径被解析之后，路径会被传递，同时会进行一些操作（例如，在’docker cp’的情况下，它会在创建流式传输到客户端的存档时打开）。”
“如果攻击者在解析之后、操作之前，向路径添加符号链接组件，那么主机上的符号链接路径组件就会被解析为 root。如果正好是在‘docker cp’的情况下，攻击者就可以对主机上的所有路径进行读写访问。”
研究人员认为针对 Docker 的这种攻击可能会持续几年时间。Sarai 针对这一漏洞开发了利用代码，并表示：潜在的攻击场景可能来自云平台，“最可能受到影响的是托管云，因为它允许配置文件复制到正在运行的容器中，也允许从容器中读取文件。”
虽然这个漏洞只有针对“docker cp”的攻击代码，但它是最容易被攻击的端点。另外还有一个值得注意的点，如果选择了一条路径，扩展了其中的所有符号链接，并假设该路径是安全的，那么这是一种非常危险的行为。
2.如何修复
“这个 Docker 漏洞虽然看起来很严重，但对大多数企业来说未必是紧急情况。” Capsule8 产品开发副总裁 Kelly Shortridge 表示：“Docker 的这个 TOCTOU 漏洞允许攻击者不仅在容器内，而且在主机上违反数据完整性和机密性。除了禁止在任何正在运行的容器上使用 docker cp 实用程序或使用攻击保护产品之外，利用 docker cp 的 Docker 用户很容易受到攻击，但仅限于动机足够强的攻击者，他们有意愿与 docker cp 竞争。”
据了解，Sarai 已经提交了针对该漏洞的修复建议，其中包括在使用文件系统时暂停容器。
这个问题最完整的解决方案是修改 chrootarchive，这样所有的存档操作都将以根目录作为容器 rootfs 进行 (而不是父目录，因为父目录是由攻击者控制的，所以导致了这个漏洞)。不过，要对 Docker 核心部分做更改几乎是不可能完成的事情。
退而求其次，我们选择了在使用文件系统时暂停容器。这种方法能够阻止最基本的攻击，但是在某些攻击场景下无法发挥作用，例如 shared volume mounts。
不过，截止到目前还没有关于 Docker 官方何时修复漏洞的消息。
3.网友支招
Docker 的这个漏洞公布之后，引发了网友的广泛讨论，大家各抒己见，纷纷为解决该漏洞献计献策。
有网友建议：“至少在某些情况下，符号链接攻击是可以通过验证路径的布尔函数来避免的。如果路径不受符号链接攻击，返回 true，否则返回 false。不受符号链接攻击意味着遍历路径，检查每个目录的权限，确保其不允许任何人创建符号链接。如果路径是相对的，则将当前工作目录作为前缀，以便进行检查。如果路径包含符号链接，那么我们必须验证符号链接目标的实际父目录，且不允许替换该目标。其实，我们只要把路径规范化就可以了，但是这种做法是不可取的，因为软件必须保证已给出的路径不变，而符号链接抽象是属于用户的，应该被尊重。”
也有网友建议：“在 syscall 系列中使用 open + O_PATH + *，它可以用来获得一个已解析目录的句柄，用户可以操作该目录而不会对该句柄上的不同操作进行重新遍历。或者也可以临时加入容器的 mount 命名空间以获取源句柄，不过这种方法很难真正实现，因为 goroutines 无法很好地处理每个线程的操作。”
对于 Docker 的这个漏洞，您有何解决方法？欢迎在下方留言讨论！
参考链接：