Docker 安全公告

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

最后更新于2024年9月13日

Docker Desktop 中与 Docker 扩展相关的两个远程代码执行 (RCE) 漏洞由 Cure53 报告,并于 9 月 12 日在 4.34.2 版本中修复。

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

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

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

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

最后更新于2024年7月

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

2024年9月16日,宽限期将结束,当强制执行SSO时,密码将无法通过Docker CLI验证到Docker Hub。受影响的用户需要切换到使用PATs以继续登录。

在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-23650CVE-2024-24557 的修复,这些漏洞分别由独立研究人员和Docker的内部研究计划发现。

Versions Impacted
runc<= 1.1.11
BuildKit<= 0.12.4
Moby (Docker Engine)<= 25.0.1 and <= 24.0.8
Docker Desktop<= 4.27.0

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

如果您正在使用受影响的 runc、BuildKit、Moby 或 Docker Desktop 版本,请确保更新到最新版本,链接如下表所示:

Patched Versions
runc>= 1.1.12
BuildKit>= 0.12.5
Moby (Docker Engine)>= 25.0.2 and >= 24.0.9
Docker Desktop>= 4.27.1

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

  • 仅使用受信任的Docker镜像(例如 Docker官方镜像)。
  • 不要从未经信任的来源或未经信任的Dockerfiles构建Docker镜像。
  • 如果您是使用 Docker Desktop 的 Docker Business 客户,并且无法更新到 v4.27.1,请确保启用 加固的 Docker Desktop 功能,例如:
  • 对于CVE-2024-23650、CVE-2024-23651、CVE-2024-23652和CVE-2024-23653,避免使用来自不受信任来源的BuildKit前端。前端镜像通常在Dockerfile中指定为#syntax行,或者在使用buildctl build命令时使用--frontend标志。
  • 为了缓解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 访问主机文件系统,从而获得对主机文件系统的访问权限。这些攻击还可以被调整为覆盖半任意的主机二进制文件,从而实现完全的容器逃逸。请注意,在使用更高级别的运行时(如 Docker 或 Kubernetes)时,此漏洞可以通过运行恶意容器镜像而无需额外配置,或者在启动容器时传递特定的工作目录选项来利用。在 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 中,如果镜像从 scratch 构建,经典构建器缓存系统容易受到缓存污染。此外,对某些指令的更改(最重要的是 HEALTHCHECKONBUILD)不会导致缓存失效。了解某人正在使用的 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 二进制文件的补丁。除了更新到这个新版本外,我们鼓励所有 Docker 用户认真使用 Docker 镜像和 Dockerfiles,并确保在构建过程中仅使用可信内容。

一如既往,在更新之前,您应该检查Docker Desktop的系统要求,以确保完全兼容性( Windows, Linux, Mac)。

Docker Build Cloud

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

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

Text4Shell CVE-2022-42889

最后更新于2022年10月

CVE-2022-42889 已在流行的Apache Commons Text库中被发现。该库的版本直到但不包括1.10.0都受到此漏洞的影响。

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

在Docker Hub上扫描镜像

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

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

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

我们已将这些镜像中的Apache Commons Text更新至最新版本。由于其他原因,某些镜像可能不易受到攻击。我们建议您也查看上游网站发布的指南。

Log4j 2 CVE-2021-44228

最后更新于2021年12月

Log4j 2 中的 CVE-2021-44228 漏洞,这是一个非常常见的 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-45046CVE-2021-45105进行跟踪。 为了更完整地修复此漏洞,我们建议您尽可能更新到2.17.0版本。

在Docker Hub上扫描镜像

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

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

最后更新于2021年12月

许多 Docker 官方镜像 包含了受 Log4j 2 CVE-2021-44228 漏洞影响的版本。下表列出了可能包含受漏洞影响的 Log4j 2 版本的 Docker 官方镜像。我们已将这些镜像中的 Log4j 2 更新到最新版本。由于其他原因,其中一些镜像可能不受影响。我们建议您也查看上游网站发布的指南。

RepositoryPatched versionAdditional documentation
couchbase7.0.3Couchbase 博客
Elasticsearch6.8.22, 7.16.2Elasticsearch 公告
Flink1.11.6, 1.12.7, 1.13.5, 1.14.2Flink 关于 Log4j CVE 的建议
Geonetwork3.10.10Geonetwork GitHub 讨论
lightstreamerAwaiting infoAwaiting info
logstash6.8.22, 7.16.2Elasticsearch 公告
neo4j4.4.2Neo4j 公告
solr8.11.1Solr 安全新闻
sonarqube8.9.5, 9.2.2SonarQube 公告
stormAwaiting infoAwaiting info

注意

尽管 xwiki 镜像可能被某些扫描器检测为易受攻击, 但作者认为这些镜像不会受到 Log4j 2 CVE 的影响,因为 API jar 文件不包含该漏洞。 Nuxeo 镜像已被弃用,将不再更新。