CVE-2020-15257

总结

containerd 是一种行业标准的容器运行时，可作为 Linux 和 Windows 的守护进程使用。在 containerd 1.3.9 和 1.4.3 之前的版本中，containerd-shim API 被不当地暴露给主机网络容器。shim 的 API 套接字的访问控制仅验证连接进程的有效 UID 是否为 0，但未进一步限制对抽象 Unix 域套接字的访问。这将允许在与 shim 相同的网络命名空间中运行、有效 UID 为 0 但权限有所降低的恶意容器，以提升的权限启动新进程。此漏洞已在 containerd 1.3.9 和 1.4.3 中修复。用户应在这些版本发布后尽快更新。需要注意的是，使用旧版本 containerd-shim 启动的容器应停止并重新启动，因为即使升级后，正在运行的容器仍将存在漏洞。如果您不提供让不受信任的用户在与 shim 相同的网络命名空间（通常是“主机”网络命名空间，例如使用 `docker run --net=host` 或 Kubernetes Pod 中的 `hostNetwork: true`）中启动容器并以有效 UID 0 运行的能力，则您不受此问题影响。如果您正在以易受攻击的配置运行容器，可以通过在策略中添加类似 `deny unix addr=@**` 的行，使用 AppArmor 拒绝对所有抽象套接字的访问。最佳实践是以降低的权限、非零 UID 和隔离的命名空间运行容器。containerd 维护者强烈建议不要与主机共享命名空间。减少容器使用的隔离机制必然会增加该容器的权限，无论使用哪种容器运行时来运行该容器。

• abstractshimmerPoC

  containerd 中 CVE-2020-15257 的概念验证。