Docker 安全漏洞被规避的情况

本页列出了 Docker 已规避的安全漏洞，因此即使在漏洞修复之前，在 Docker 容器中运行的进程也从未受到这些漏洞的影响。前提是容器运行时未添加额外的 capabilities 或未以 --privileged 模式运行。

以下列表并不完整。它只是我们实际注意到的一些引起安全审查并已公开披露的漏洞的示例。极有可能的是，尚未报告的漏洞数量远超已报告的漏洞。幸运的是，由于 Docker 通过 apparmor、seccomp 和去除 capabilities 等方式实现默认安全，它很可能能够很好地规避未知漏洞，就像规避已知漏洞一样。

已规避的漏洞

  • CVE-2013-1956, 1957, 1958, 1959, 1979, CVE-2014-4014, 5206, 5207, 7970, 7975, CVE-2015-2925, 8543, CVE-2016-3134, 3135, 等等：引入非特权用户命名空间导致非特权用户可用的攻击面大幅增加，通过给予这些用户合法访问以前只有 root 用户才能访问的系统调用，如 mount()。所有这些 CVE 都是由于引入用户命名空间而导致的安全漏洞示例。Docker 可以使用用户命名空间来设置容器，但随后通过默认的 seccomp 配置限制容器内的进程创建其自己的嵌套命名空间，使得这些漏洞无法被利用。
  • CVE-2014-0181, CVE-2015-3339：这些漏洞需要存在 setuid 二进制文件。Docker 通过 NO_NEW_PRIVS 进程标志及其他机制禁用容器内的 setuid 二进制文件。
  • CVE-2014-4699：ptrace() 中的一个 bug 可能允许权限提升。Docker 使用 apparmor、seccomp 并删除 CAP_PTRACE 来禁用容器内的 ptrace()。这里有三重保护层！
  • CVE-2014-9529：一系列精心构造的 keyctl() 调用可能导致内核拒绝服务 (DoS) / 内存损坏。Docker 使用 seccomp 在容器内禁用了 keyctl()。
  • CVE-2015-3214、4036：这些是常见虚拟化驱动程序中的 bug，可能允许客户操作系统用户在主机操作系统上执行代码。利用这些 bug 需要在客户机中访问虚拟化设备。在不以 --privileged 模式运行时，Docker 隐藏了对这些设备的直接访问。有趣的是，这些案例似乎表明容器比虚拟机“更安全”，这与虚拟机比容器“更安全”的普遍认知相反。
  • CVE-2016-0728：由精心构造的 keyctl() 调用引起的 Use-after-free（释放后使用）可能导致权限提升。Docker 使用默认的 seccomp 配置在容器内禁用了 keyctl()。
  • CVE-2016-2383：eBPF 中的一个 bug（eBPF 是用于表达 seccomp 过滤器等内容的内核中的特殊 DSL）允许任意读取内核内存。（讽刺的是）使用 seccomp 在 Docker 容器内部阻止了 bpf() 系统调用。
  • CVE-2016-3134、4997、4998：setsockopt 在使用 IPT_SO_SET_REPLACE、ARPT_SO_SET_REPLACE 和 ARPT_SO_SET_REPLACE 时存在一个 bug，导致内存损坏 / 本地权限提升。这些参数被 CAP_NET_ADMIN 权限阻止，而 Docker 默认不允许此权限。

未缓解的漏洞

  • CVE-2015-3290、5157：内核的不可屏蔽中断处理中存在 bug，可能导致权限提升。可以在 Docker 容器中被利用，因为 modify_ldt() 系统调用目前未被 seccomp 阻止。
  • CVE-2016-5195：在 Linux 内核内存子系统处理私有只读内存映射的写时复制 (COW) 中断的方式中发现了一个竞态条件，这允许非特权本地用户获取对只读内存的写入权限。也称为 "dirty COW"。部分缓解措施：在某些操作系统上，通过结合对 ptrace 的 seccomp 过滤以及 /proc/self/mem 是只读的事实，可以缓解此漏洞。
页面选项