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 | <= 1.1.11 |
BuildKit | <= 0.12.4 |
Moby（Docker Engine） | <= 25.0.1 和 <= 24.0.8 |
Docker Desktop | <= 4.27.0 |
如果我使用的是受影响的版本，该怎么办？
如果您使用的是受影响版本的 runc、BuildKit、Moby 或 Docker Desktop，请确保更新到最新版本，以下表格中列出了相关链接
| 修补后的版本 | |
|---|---|
runc | >= 1.1.12 |
BuildKit | >= 0.12.5 |
Moby（Docker Engine） | >= 25.0.2 和 >= 24.0.9 |
Docker Desktop | >= 4.27.1 |
如果您无法及时更新到不受影响的版本，请遵循以下最佳实践来降低风险
- 只使用可信的 Docker 镜像（例如 Docker 官方镜像）。
- 不要从不可信的来源或不可信的 Dockerfile 构建 Docker 镜像。
- 如果您是使用 Docker Desktop 的 Docker 商业客户，并且无法更新到 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 标志来实现。如果您直接或通过客户端使用 HTTP API，可以通过将nocache设置为true或将version设置为2来实现，针对 /build API 端点。
技术细节和影响
CVE-2024-21626（高危）
在 runc v1.1.11 及更早版本中，由于某些泄露的文件描述符，攻击者可以通过以下方式获取对主机文件系统的访问权限：导致新生成的容器进程（来自 runc exec）在主机文件系统命名空间中具有工作目录，或诱骗用户运行恶意镜像并允许容器进程通过 runc run 访问主机文件系统。这些攻击也可以被调整为覆盖半任意主机二进制文件，从而实现完全的容器逃逸。请注意，当使用更高级别的运行时（例如 Docker 或 Kubernetes）时，可以通过运行恶意容器镜像（无需额外的配置）或在启动容器时传递特定的 workdir 选项来利用此漏洞。在 Docker 的情况下，此漏洞也可以从 Dockerfile 中被利用。
该问题已在 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 守护程序发生恐慌并崩溃。
该问题已在 BuildKit v0.12.5 中修复。
CVE-2024-24557（中危）
在 Moby <= v25.0.1 和 <= v24.0.8 中，如果镜像是从头开始构建的，则传统的构建器缓存系统容易受到缓存中毒的影响。此外，对某些指令（最重要的是 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 二进制文件的补丁。除了更新到此新版本之外，我们鼓励所有 Docker 用户认真使用 Docker 镜像和 Dockerfile，并确保仅在构建中使用受信任的内容。
与往常一样，您应该在更新之前检查 Docker Desktop 系统要求，以确保完全兼容，请查看您的操作系统的系统要求：Windows、Linux、Mac。
Docker Build Cloud
所有新的 Docker Build Cloud 构建器实例都将使用最新的 Docker Engine 和 BuildKit 版本进行配置，因此不会受到这些 CVE 的影响。更新也已推送到现有的 Docker Build Cloud 构建器。
其他 Docker 产品不受这些漏洞的影响。
咨询链接
- Runc
- BuildKit
- Moby
Text4Shell CVE-2022-42889
最后更新于 2022 年 10 月
CVE-2022-42889 已在流行的 Apache Commons Text 库中发现。该库的版本（包括但不限于 1.10.0）会受到此漏洞的影响。
我们强烈建议您更新到最新版本的 Apache Commons Text。
扫描 Docker Hub 上的镜像
2021 年 10 月 21 日 1200 UTC 后触发的 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 漏洞中，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 日 1700 UTC 后触发的 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 更新到最新版本。某些镜像可能由于其他原因而不易受攻击。我们建议您也查看上游网站上发布的指南。
| 存储库 | 已修复版本 | 其他文档 |
|---|---|---|
| couchbase | 7.0.3 | Couchbase 博客 |
| Elasticsearch | 6.8.22, 7.16.2 | Elasticsearch 公告 |
| Flink | 1.11.6, 1.12.7, 1.13.5, 1.14.2 | Flink 关于 Log4j CVE 的建议 |
| Geonetwork | 3.10.10 | Geonetwork GitHub 讨论 |
| lightstreamer | 等待信息 | 等待信息 |
| logstash | 6.8.22, 7.16.2 | Elasticsearch 公告 |
| neo4j | 4.4.2 | Neo4j 公告 |
| solr | 8.11.1 | Solr 安全新闻 |
| sonarqube | 8.9.5, 9.2.2 | SonarQube 公告 |
| storm | 等待信息 | 等待信息 |
注意
虽然一些扫描器可能会检测到 xwiki 镜像存在漏洞，但开发者认为这些镜像不受 Log4j 2 CVE 的影响，因为 API jar 文件不包含漏洞。 Nuxeo 镜像已过时，不会再更新。