Docker 安全公告

Docker Desktop 4.34.2 安全更新：CVE-2024-8695 和 CVE-2024-8696

最后更新于 2024年9月13日

Cure53 的 研究人员 报告了 Docker Desktop 中与 Docker 扩展相关的两个远程代码执行 (RCE) 漏洞，这些漏洞已于 9 月 12 日在 4.34.2 版本中修复。

• CVE-2024-8695: 在 4.34.2 之前的 Docker Desktop 中，恶意扩展可能利用通过构造的扩展描述/变更日志实现的远程代码执行 (RCE) 漏洞。[严重]
• CVE-2024-8696: Docker Desktop 4.34.2 之前版本中存在一个远程代码执行 (RCE) 漏洞，该漏洞可通过精心设计的扩展发布者 URL/附加 URL 被恶意扩展利用。[高危]

在扩展市场中未发现利用这些漏洞的现有扩展。Docker 团队将密切监控并认真审查任何发布新扩展的请求。

我们强烈建议您更新到 Docker Desktop 4.34.2。如果您无法及时更新，可以 禁用 Docker 扩展作为临时解决方案。

强制执行 SSO 时弃用 CLI 密码登录

最后更新于 2024 年 7 月

当首次引入 SSO 强制执行时，Docker 提供了一个宽限期，允许在向 Docker Hub 进行身份验证时继续在 Docker CLI 中使用密码。这样做是为了让组织能够更轻松地使用 SSO 强制执行。建议配置 SSO 的管理员鼓励使用 CLI 的用户 切换到个人访问令牌，以应对该宽限期的结束。

2024 年 9 月 16 日，宽限期将结束；当强制执行 SSO 时，密码将不再能够通过 Docker CLI 向 Docker Hub 进行身份验证。受影响的用户必须切换为使用 PAT 才能继续登录。

在 Docker，我们希望为我们的开发者和组织提供最安全的体验，此次弃用是朝此方向迈出的关键一步。

Docker 安全公告：runc、BuildKit 和 Moby 中的多个漏洞

最后更新于 2024年2月2日

我们 Docker 优先考虑软件的安全性和完整性以及用户的信任。Snyk Labs 的安全研究人员发现并报告了容器生态系统中的四个安全漏洞。其中一个漏洞， CVE-2024-21626，涉及 runc 容器运行时，另外三个影响 BuildKit ( CVE-2024-23651， CVE-2024-23652 和 CVE-2024-23653)。我们要向社区保证，我们的团队一直在与报告者和开源维护者合作，努力协调并实施必要的补救措施。

我们致力于维持最高的安全标准。我们已于 1 月 31 日发布了 runc、BuildKit 和 Moby 的修补版本，并于 2 月 1 日发布了 Docker Desktop 的更新以解决这些漏洞。此外，我们最新的 BuildKit 和 Moby 版本包含了对 CVE-2024-23650 和 CVE-2024-24557 的修复，这些漏洞分别由独立研究人员和 Docker 的内部研究计划发现。

如果我使用的是受影响的版本，该怎么办？

如果您正在使用受影响的 runc、BuildKit、Moby 或 Docker Desktop 版本，请务必更新至下表所列的最新版本：

如果您无法及时更新到未受影响的版本，请遵循这些最佳实践以降低风险：

• 仅使用受信任的 Docker 镜像（例如 Docker 官方镜像）。
• 不要从不受信任的来源或不受信任的 Dockerfile 构建 Docker 镜像。
• 如果您是使用 Docker Desktop 的 Docker Business 客户，并且无法更新到 v4.27.1，请确保启用 加固版 Docker Desktop 功能，例如：
  • 增强容器隔离，可在运行来自恶意镜像的容器时减轻 CVE-2024-21626 的影响。
  • 镜像访问管理，以及 注册表访问管理，使组织能够控制其用户可以访问哪些镜像和仓库。
• 对于 CVE-2024-23650、CVE-2024-23651、CVE-2024-23652 和 CVE-2024-23653，请避免使用来自不可信来源的 BuildKit 前端。前端镜像通常在 Dockerfile 中通过 #syntax 行指定，或者在使用 --frontend 命令时通过 buildctl build 标志指定。
• 为了缓解 CVE-2024-24557，请确保在构建镜像时使用 BuildKit 或禁用缓存。在 CLI 中，这可以通过 DOCKER_BUILDKIT=1 环境变量（如果安装了 buildx 插件，Moby >= v23.0 的默认设置）或 --no-cache flag 来完成。如果您直接使用 HTTP API 或通过客户端使用，可以通过将 nocache 设置为 true 或将 version 设置为 2 来实现，针对 /build API 端点。

技术细节与影响

CVE-2024-21626 (高)

在 runc v1.1.11 及更早版本中，由于某些文件描述符泄漏，攻击者可以通过使新生成的容器进程（从 runc exec）在主机文件系统命名空间中拥有工作目录，或者通过诱骗用户运行恶意镜像并允许容器进程通过 runc run 访问主机文件系统，从而获得对主机文件系统的访问权限。这些攻击也可以被改编为覆盖半任意主机Binaries，从而实现完全的容器逃逸。请注意，当使用更高级别的运行时（如 Docker 或 Kubernetes）时，可以通过运行恶意容器镜像而无需额外配置，或者在启动容器时传递特定的 workdir 选项来利用此漏洞。在 Docker 的情况下，也可以从 Dockerfiles 中利用此漏洞。

该问题已在 runc v1.1.12 中修复。

CVE-2024-23651 (高)

在 BuildKit v0.12.4 及更早版本中，两个并行运行的恶意构建步骤如果共享具有子路径的相同缓存挂载，可能会导致竞争条件，从而导致主机系统中的文件可被构建容器访问。这种情况仅在用户尝试构建恶意项目的 Dockerfile 时才会发生。

该问题已在 BuildKit v0.12.5 中修复。

CVE-2024-23652 (高危)

在 BuildKit <= v0.12.4 中，恶意的 BuildKit 前端或使用 RUN --mount 的 Dockerfile 可能会欺骗用于删除为挂载点创建的空文件的功能，从而导致删除主机系统上容器外的文件。只有当用户使用恶意 Dockerfile 时，才会发生这种情况。

该问题已在 BuildKit v0.12.5 中修复。

CVE-2024-23653 (高)

除了将容器作为构建步骤运行外，BuildKit 还提供了用于运行基于已构建镜像的交互式容器的 API。在 BuildKit <= v0.12.4 版本中，可能利用这些 API 请求 BuildKit 以提升的权限运行容器。通常情况下，只有在 buildkitd 配置中启用了特殊的 security.insecure 权限，并且发起构建请求的用户允许时，才允许运行此类容器。

该问题已在 BuildKit v0.12.5 中修复。

CVE-2024-23650 (中危)

在 BuildKit v0.12.4 及更早版本中，恶意的 BuildKit 客户端或前端可以构造一个请求，导致 BuildKit 守护进程因 panic 而崩溃。

该问题已在 BuildKit v0.12.5 中修复。

CVE-2024-24557 (中危)

在 Moby <= v25.0.1 和 <= v24.0.8 版本中，如果镜像是 FROM scratch 构建的，传统的构建器缓存系统容易受到缓存投毒攻击。此外，对某些指令（最重要的是 HEALTHCHECK 和 ONBUILD）的更改不会导致缓存未命中。了解某人正在使用的 Dockerfile 的攻击者可以通过让他们拉取一个特制的镜像来毒害他们的缓存，该镜像会被视为某些构建步骤的有效缓存候选者。

该问题已在 Moby >= v25.0.2 和 >= v24.0.9 版本中修复。

Docker 产品受到怎样的影响？

Docker Desktop版

Docker Desktop v4.27.0 及更早版本受到影响。Docker Desktop v4.27.1 已于 2 月 1 日发布，包含 runc、BuildKit 和 dockerd Binaries的补丁。除了更新到这个新版本之外，我们鼓励所有 Docker 用户谨慎使用 Docker 镜像和 Dockerfile，并确保在构建中仅使用受信任的内容。

与往常一样，在更新之前，您应该检查您的操作系统（ Windows、 Linux、 Mac）的 Docker Desktop 系统要求，以确保完全兼容。

Docker Build Cloud

任何新的 Docker Build Cloud 构建器实例都将配置最新的 Docker Engine 和 BuildKit 版本，因此不会受这些 CVE 的影响。更新也已推广到现有的 Docker Build Cloud 构建器。

没有其他 Docker 产品受这些漏洞影响。

公告链接

• Runc
  • CVE-2024-21626
• BuildKit
  • CVE-2024-23650
  • CVE-2024-23651
  • CVE-2024-23652
  • CVE-2024-23653
• Moby
  • CVE-2024-24557

Text4Shell CVE-2022-42889

最后更新于 2022 年 10 月

CVE-2022-42889 已在流行的 Apache Commons Text 库中被发现。该库版本号低于（但不包括）1.10.0 的版本均受此漏洞影响。

我们强烈建议您更新到最新版本的 Apache Commons Text。

扫描 Docker Hub 上的镜像

在协调世界时 2021 年 10 月 21 日 12:00 之后触发的 Docker Hub 安全扫描现在能够正确识别 Text4Shell CVE。在此日期之前的扫描目前未反映此漏洞的状态。因此，我们建议您通过向 Docker Hub 推送新镜像来触发扫描，以在漏洞报告中查看 Text4Shell CVE 的状态。有关详细说明，请参阅 在 Docker Hub 上扫描镜像。

Docker 官方镜像受 CVE-2022-42889 影响

许多 Docker 官方镜像 包含 Apache Commons Text 的漏洞版本。以下列出了可能包含 Apache Commons Text 漏洞版本的 Docker 官方镜像：

• bonita
• Couchbase
• 地理网络
• neo4j
• sliverpeas
• solr
• xwiki

我们已将这些镜像中的 Apache Commons Text 更新至最新版本。出于其他原因，其中部分镜像可能不存在漏洞。我们建议您也查阅上游网站上发布的指南。

Log4j 2 CVE-2021-44228

最后更新于 2021 年 12 月

Log4j 2 CVE-2021-44228漏洞存在于 Log4j 2（一个非常常见的 Java 日志库）中，该漏洞允许远程代码执行，攻击者通常可以从易于获取的上下文中发起攻击。例如，该漏洞在 Minecraft 服务器中被发现，允许将命令输入到聊天日志中，因为这些内容随后会被发送给日志记录器。这使得它成为一个非常严重的漏洞，因为该日志库的使用非常广泛，且可能很容易被利用。许多开源维护者正在努力修复并更新软件生态系统。

Log4j 2 的受影响版本包括从 2.0 到 2.14.1（含）的版本。首个修复版本是 2.15.0。我们强烈建议您尽可能更新到 最新版本。如果您使用的是 2.0 之前的版本，则不受此漏洞影响。

如果您正在使用这些版本，您可能不会受到漏洞影响，因为您的配置可能已经缓解了此问题，或者您记录的内容可能不包含任何用户输入。然而，如果不详细了解所有可能记录日志的代码路径及其输入来源，这可能很难验证。因此，您可能需要升级所有使用易受攻击版本的代码。

CVE-2021-45046

作为对 CVE-2021-44228的更新，2.15.0版本中的修复 并不完整。已发现其他问题，并通过 CVE-2021-45046和 CVE-2021-45105进行追踪。 为了更彻底地修复此漏洞，我们建议您在可能的情况下更新至2.17.0版本。

扫描 Docker Hub 上的镜像

在协调世界时 2021 年 12 月 13 日 17:00 之后触发的 Docker Hub 安全扫描现在可以正确识别 Log4j 2 CVE。此日期之前的扫描目前未反映此漏洞的状态。因此，我们建议您通过将新镜像推送到 Docker Hub 来触发扫描，以在漏洞报告中查看 Log4j 2 CVE 的状态。有关详细说明，请参阅 在 Docker Hub 上扫描镜像。

受 Log4j 2 CVE 影响的 Docker 官方镜像

最后更新于 2021 年 12 月

许多 Docker 官方镜像包含存在漏洞的 Log4j 2 CVE-2021-44228 版本。下表列出了可能包含存在漏洞的 Log4j 2 版本的 Docker 官方镜像。 我们已将这些镜像中的 Log4j 2 更新至最新版本。其中部分镜像可能因其他原因而不存在漏洞。 我们建议您也查阅上游网站上发布的指南。

注意

尽管 xwiki 镜像可能被某些扫描器检测为易受攻击，但作者认为这些镜像不存在 Log4j 2 CVE 漏洞，因为 API jar 包不包含该漏洞。 The Nuxeo 镜像已弃用，将不再更新。