1624 lines
139 KiB
Plaintext
1624 lines
139 KiB
Plaintext
cve: ./data/2024/0xxx/CVE-2024-0137.json
|
||
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code running in the host’s network namespace. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to denial of service and escalation of privileges.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE信息明确提到“improper isolation vulnerability”（隔离漏洞），并且涉及“network namespace”（网络命名空间）。这表明问题与容器的隔离机制相关，特别是网络命名空间的隔离。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机**：
|
||
是的，根据描述， specially crafted container image（特殊构造的容器镜像）可能导致“untrusted code running in the host’s network namespace”（不可信代码在宿主机的网络命名空间中运行）。这表明攻击者可以通过此漏洞突破容器隔离，影响宿主机或其他共享同一网络命名空间的容器。
|
||
|
||
3. **结论**：
|
||
由于条件1和条件2均满足，因此不需要返回“N/A”。
|
||
|
||
cve: ./data/2024/0xxx/CVE-2024-0443.json
|
||
A flaw was found in the blkgs destruction path in block/blk-cgroup.c in the Linux kernel, leading to a cgroup blkio memory leakage problem. When a cgroup is being destroyed, cgroup_rstat_flush() is only called at css_release_work_fn(), which is called when the blkcg reference count reaches 0. This circular dependency will prevent blkcg and some blkgs from being freed after they are made offline. This issue may allow an attacker with a local access to cause system instability, such as an out of memory error.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 信息明确提到 `blk-cgroup.c` 和 `cgroup blkio` 的内存泄漏问题。这表明它与 cgroup（控制组）直接相关，而 cgroup 是 Linux 容器（如 Docker）实现资源限制和隔离的重要组成部分。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致系统内存耗尽（out of memory error），从而影响整个宿主机的稳定性。由于 cgroup 是用于管理容器资源的核心机制，如果存在内存泄漏问题，可能会导致以下情况：
|
||
- 宿主机上的所有容器可能因为宿主机资源耗尽而受到影响。
|
||
- 攻击者可以通过触发此漏洞，利用本地访问权限使系统变得不稳定，进一步影响其他容器的正常运行。
|
||
|
||
因此，这个 CVE 满足条件 1 和条件 2。
|
||
|
||
cve: ./data/2024/10xxx/CVE-2024-10975.json
|
||
Nomad Community and Nomad Enterprise ("Nomad") volume specification is vulnerable to arbitrary cross-namespace volume creation through unauthorized Container Storage Interface (CSI) volume writes. This vulnerability, identified as CVE-2024-10975, is fixed in Nomad Community Edition 1.9.2 and Nomad Enterprise 1.9.2, 1.8.7, and 1.7.15.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE与namespace和容器相关。描述中提到“arbitrary cross-namespace volume creation”，表明攻击者可以通过未经授权的CSI（Container Storage Interface）操作，在不同namespace之间创建存储卷。这直接影响了容器之间的隔离性。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||
是的，这种漏洞可能会导致容器在运行时影响其他容器或宿主机。通过跨namespace的任意卷创建，攻击者可能绕过隔离机制，访问或修改其他容器或宿主机上的数据，从而破坏容器环境的安全性和完整性。
|
||
|
||
**结论**：满足条件1和条件2。
|
||
|
||
cve: ./data/2024/11xxx/CVE-2024-11075.json
|
||
A vulnerability in the Incoming Goods Suite allows a user with unprivileged access to the underlying system (e.g. local or via SSH) a privilege escalation to the administrative level due to the usage of component vendor Docker images running with root permissions. Exploiting this misconfiguration leads to the fact that an attacker can gain administrative control. over the whole system.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 提及了 Docker 镜像以 root 权限运行的问题。这直接涉及容器技术（Docker）以及容器的权限配置问题，因此与容器和隔离机制相关。
|
||
|
||
2. **分析是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，由于 Docker 容器以 root 权限运行，攻击者可以通过此漏洞获得对整个系统的控制权（包括宿主机和其他容器）。这种权限提升可能会导致攻击者破坏隔离机制，从而影响其他容器或宿主机的安全性。
|
||
|
||
3. **结论**：
|
||
该 CVE 满足条件 1 和条件 2，因此需要返回上述分析内容。
|
||
|
||
cve: ./data/2024/12xxx/CVE-2024-12678.json
|
||
Nomad Community and Nomad Enterprise ("Nomad") allocations are vulnerable to privilege escalation within a namespace through unredacted workload identity tokens. This vulnerability, identified as CVE-2024-12678, is fixed in Nomad Community Edition 1.9.4 and Nomad Enterprise 1.9.4, 1.8.8, and 1.7.16.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 和容器相关。Nomad 是一个用于调度和管理容器化应用程序的工具，漏洞描述中提到“privilege escalation within a namespace”，表明问题涉及 namespace 的权限提升。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
虽然该漏洞允许在 namespace 内进行权限提升，但其影响范围被限制在 namespace 内部。根据描述，没有明确提到该漏洞会直接影响其他容器或宿主机的安全性。因此，此漏洞的影响主要限于同一 namespace 内的工作负载，而不是跨容器或宿主机的全局影响。
|
||
|
||
**结论：**
|
||
满足条件 1，部分满足条件 2（仅限于 namespace 内的影响）。
|
||
|
||
cve: ./data/2024/13xxx/CVE-2024-13484.json
|
||
A flaw was found in openshift-gitops-operator-container. The openshift.io/cluster-monitoring label is applied to all namespaces that deploy an ArgoCD CR instance, allowing the namespace to create a rogue PrometheusRule. This issue can have adverse effects on the platform monitoring stack, as the rule is rolled out cluster-wide when the label is applied.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
该 CVE 提到 `openshift.io/cluster-monitoring` 标签被应用到所有部署了 ArgoCD CR 实例的命名空间（namespace），这表明问题确实与 namespace 相关。然而，描述中没有提到 cgroup、container 或具体的容器隔离机制。
|
||
|
||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
该漏洞允许一个命名空间创建一个恶意的 PrometheusRule，并且该规则会被集群范围应用。这种行为可能会对平台监控栈产生负面影响，但并没有直接提到容器逃逸、宿主机受影响或其他容器的资源被滥用的情况。因此，这个漏洞主要影响的是集群级别的监控配置，而不是容器之间的隔离性或宿主机的安全性。
|
||
|
||
3. **结论**：
|
||
条件 1 部分满足（与 namespace 相关），条件 2 不满足（不影响其他容器或宿主机）。因此，返回分析结果而非 "N/A"。
|
||
|
||
**最终分析结果**：
|
||
- 与 namespace 相关，允许创建恶意的 PrometheusRule，影响集群范围的监控配置。
|
||
- 不会影响容器隔离性或宿主机安全。
|
||
|
||
cve: ./data/2024/1xxx/CVE-2024-1355.json
|
||
A command injection vulnerability was identified in GitHub Enterprise Server that allowed an attacker with an editor role in the Management Console to gain admin SSH access to the appliance via the actions-console docker container while setting a service URL. Exploitation of this vulnerability required access to the GitHub Enterprise Server instance and access to the Management Console with the editor role. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.12 and was fixed in versions 3.11.5, 3.10.7, 3.9.10, and 3.8.15. This vulnerability was reported via the GitHub Bug Bounty program.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
该 CVE 描述中提到漏洞存在于 GitHub Enterprise Server 的 Management Console 中，攻击者可以通过设置服务 URL 在 `actions-console` Docker 容器中执行命令注入。这表明漏洞直接涉及到了一个名为 `actions-console` 的容器，因此与容器技术相关。
|
||
|
||
2. **分析是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
根据描述，攻击者可以通过命令注入获得对 `actions-console` 容器的管理员 SSH 访问权限。这种访问可能会进一步被利用来突破容器隔离，影响宿主机或其他容器的安全性。虽然具体描述没有明确提到跨容器或宿主机的影响，但获得 SSH 访问通常可能被用作进一步攻击的跳板。
|
||
|
||
3. **结论：**
|
||
条件 1 和条件 2 均满足，因此返回分析结果。
|
||
|
||
cve: ./data/2024/20xxx/CVE-2024-20483.json
|
||
Multiple vulnerabilities in Cisco Routed PON Controller Software, which runs as a docker container on hardware that is supported by Cisco IOS XR Software, could allow an authenticated, remote attacker with Administrator-level privileges on the PON Manager or direct access to the PON Manager MongoDB instance to perform command injection attacks on the PON Controller container and execute arbitrary commands as root.
|
||
|
||
These vulnerabilities are due to insufficient validation of arguments that are passed to specific configuration commands. An attacker could exploit these vulnerabilities by including crafted input as the argument of an affected configuration command. A successful exploit could allow the attacker to execute arbitrary commands as root on the PON controller.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，这个 CVE 信息明确提到漏洞存在于 Cisco Routed PON Controller Software 中，该软件作为一个 Docker 容器运行。因此，它与容器技术直接相关。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
根据描述，攻击者可以通过命令注入在 PON Controller 容器中以 root 权限执行任意命令。这种情况下，如果容器没有正确配置隔离机制（如 namespace 或 cgroup 限制不足），可能会导致以下风险：
|
||
- 攻击者可能利用容器内的 root 权限逃逸到宿主机。
|
||
- 如果宿主机上的共享资源（如网络、文件系统）未被妥善隔离，可能会影响其他容器的正常运行。
|
||
- 具体影响取决于容器运行时的安全配置（如是否启用了 Seccomp、AppArmor、只读根文件系统等）。
|
||
|
||
**结论：**
|
||
此 CVE 涉及容器技术，并且可能通过命令注入导致容器内权限滥用，进一步可能威胁到宿主机或其他容器的安全性。因此，条件 1 和 2 均满足。
|
||
|
||
cve: ./data/2024/21xxx/CVE-2024-21626.json
|
||
runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). runc 1.1.12 includes patches for this issue.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
该CVE描述了runc工具中的一个漏洞，runc是用于根据OCI规范在Linux上启动和运行容器的CLI工具。漏洞涉及文件描述符泄漏问题，导致新生成的容器进程的工作目录位于主机文件系统命名空间中。这直接影响了容器的隔离性，使容器能够访问主机文件系统，从而破坏了namespace提供的隔离机制。因此，该CVE与namespace、container以及隔离密切相关。
|
||
|
||
2. **分析是否会导致容器（如Docker等）在运行时影响其他容器或宿主机**：
|
||
根据描述，攻击者可以通过此漏洞实现以下几种攻击：
|
||
- **Attack 1**：恶意镜像可以利用漏洞通过`runc run`访问主机文件系统。
|
||
- **Attack 2**：通过`runc exec`生成的新容器进程可以直接访问主机文件系统。
|
||
- **Attack 3a/3b**：攻击者可以覆盖主机上的某些二进制文件，进一步实现完全的容器逃逸。
|
||
这些攻击均表明，漏洞不仅会影响当前容器，还可能通过破坏主机文件系统的方式影响其他容器或直接危害宿主机。
|
||
|
||
**结论**：
|
||
- 满足条件1和条件2，该CVE信息与namespace、container以及隔离相关，并且可能导致容器运行时影响其他容器或宿主机。
|
||
|
||
cve: ./data/2024/22xxx/CVE-2024-22036.json
|
||
A vulnerability has been identified within Rancher where a cluster or node driver can be used to escape the chroot
|
||
jail and gain root access to the Rancher container itself. In
|
||
production environments, further privilege escalation is possible based
|
||
on living off the land within the Rancher container itself. For the test
|
||
and development environments, based on a –privileged Docker container,
|
||
it is possible to escape the Docker container and gain execution access
|
||
on the host system.
|
||
|
||
|
||
This issue affects rancher: from 2.7.0 before 2.7.16, from 2.8.0 before 2.8.9, from 2.9.0 before 2.9.3.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息明确提到了 Rancher 容器和 Docker 容器。漏洞描述中提到通过集群或节点驱动程序可以逃脱 chroot 环境并获得 Rancher 容器的 root 访问权限。此外，还提到在使用 `--privileged` 的 Docker 容器中，攻击者可能进一步逃脱容器并获得宿主机的执行权限。这表明该漏洞直接与容器隔离机制相关。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞可能导致容器逃逸。具体来说，在 `--privileged` 模式下运行的 Docker 容器中，攻击者可以利用此漏洞逃脱容器并访问宿主机系统。一旦攻击者获得宿主机的访问权限，他们可能会进一步影响其他运行在该宿主机上的容器，从而破坏隔离性。
|
||
|
||
3. **结论：**
|
||
条件 1 和条件 2 均满足，因此返回上述分析结果。
|
||
|
||
cve: ./data/2024/23xxx/CVE-2024-23055.json
|
||
An issue in Plone Docker Official Image 5.2.13 (5221) open-source software allows for remote code execution via improper validation of input by the HOST headers.
|
||
analysis: 1. 该 CVE 信息与 namespace、cgroup、container 或容器隔离机制无直接关系。问题的核心是 Plone Docker 官方镜像中的 HOST 头部输入验证不当，导致远程代码执行漏洞，而不是容器或隔离机制本身的缺陷。
|
||
|
||
2. 由于该漏洞是由于 HOST 头部输入验证不当引起的远程代码执行，攻击者可能利用此漏洞在运行该镜像的容器中执行任意代码。如果容器以特权模式运行、共享宿主机的命名空间或配置不当，则可能进一步影响其他容器或宿主机的安全性。因此，此 CVE 在特定条件下可能会对其他容器或宿主机造成影响。
|
||
|
||
**结论：满足条件 1 和 2，需注意容器运行环境的配置安全性。**
|
||
|
||
cve: ./data/2024/23xxx/CVE-2024-23651.json
|
||
BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. The issue has been fixed in v0.12.5. Workarounds include, avoiding using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 信息明确提到了 BuildKit 的构建步骤中涉及容器（build container）以及缓存挂载（cache mounts），并且描述了由于共享缓存挂载的子路径导致的竞争条件问题。这与容器的隔离机制密切相关。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，根据描述，恶意构建步骤可以通过竞争条件访问宿主机系统上的文件。这意味着容器的隔离被破坏，可能允许攻击者访问或泄露宿主机上的敏感信息，从而影响宿主机或其他容器的安全性。
|
||
|
||
因此，该 CVE 满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/23xxx/CVE-2024-23652.json
|
||
BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. The issue has been fixed in v0.12.5. Workarounds include avoiding using BuildKit frontends from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE信息明确提到BuildKit工具以及其在容器环境中的使用。具体来说，问题涉及`RUN --mount`功能，该功能用于在构建过程中挂载文件或目录。此功能直接与容器的隔离机制相关，因为挂载点和文件操作是在容器上下文中进行的。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞可能导致容器内的操作影响到宿主机。攻击者可以通过恶意构造的Dockerfile或BuildKit前端，利用`RUN --mount`功能删除宿主机上的文件（而非仅限于容器内部）。这种行为破坏了容器与宿主机之间的隔离性，可能对宿主机造成严重损害。
|
||
|
||
**结论：** 该CVE满足条件1和条件2。
|
||
|
||
cve: ./data/2024/24xxx/CVE-2024-24557.json
|
||
Moby is an open-source project created by Docker to enable software containerization. The classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. 23.0+ users are only affected if they explicitly opted out of Buildkit (DOCKER_BUILDKIT=0 environment variable) or are using the /build API endpoint. All users on versions older than 23.0 could be impacted. Image build API endpoint (/build) and ImageBuild function from github.com/docker/docker/client is also affected as it the uses classic builder by default. Patches are included in 24.0.9 and 25.0.2 releases.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
该 CVE 描述了 Moby（Docker 的开源项目）中经典构建器缓存系统的一个问题，具体涉及 `FROM scratch` 构建时的缓存中毒风险，以及某些指令（如 `HEALTHCHECK` 和 `ONBUILD`）的变化不会导致缓存失效。虽然该问题发生在容器镜像构建过程中，但它主要与构建缓存逻辑有关，而不是直接与 namespace、cgroup 或容器隔离机制相关。
|
||
|
||
2. **分析是否会导致容器运行时影响其他容器或宿主机**：
|
||
该漏洞的核心是缓存中毒问题，可能导致攻击者通过精心构造的镜像污染构建缓存，从而影响后续的构建步骤。然而，这种影响仅限于镜像构建阶段，并不会直接影响容器运行时的行为，也不会破坏容器之间的隔离性或影响宿主机的安全性。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均不满足，因此返回：
|
||
**N/A**
|
||
|
||
cve: ./data/2024/24xxx/CVE-2024-24760.json
|
||
mailcow is a dockerized email package, with multiple containers linked in one bridged network. A security vulnerability has been identified in mailcow affecting versions < 2024-01c. This vulnerability potentially allows attackers on the same subnet to connect to exposed ports of a Docker container, even when the port is bound to 127.0.0.1. The vulnerability has been addressed by implementing additional iptables/nftables rules. These rules drop packets for Docker containers on ports 3306, 6379, 8983, and 12345, where the input interface is not `br-mailcow` and the output interface is `br-mailcow`.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 信息与容器和隔离相关。它描述了在 mailcow（一个基于 Docker 的电子邮件解决方案）中，多个容器共享一个桥接网络时出现的安全问题。具体来说，当某个端口绑定到 `127.0.0.1` 时，攻击者仍然可以通过同一子网访问这些端口，这表明容器之间的网络隔离存在缺陷。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致攻击者利用同一子网上的其他容器或宿主机对目标容器进行未经授权的访问。虽然漏洞本身并未直接提到突破容器隔离或访问宿主机资源，但通过网络层面的暴露，攻击者可能进一步利用其他漏洞来影响其他容器或宿主机。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/26xxx/CVE-2024-26634.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: fix removing a namespace with conflicting altnames
|
||
|
||
Mark reports a BUG() when a net namespace is removed.
|
||
|
||
kernel BUG at net/core/dev.c:11520!
|
||
|
||
Physical interfaces moved outside of init_net get "refunded"
|
||
to init_net when that namespace disappears. The main interface
|
||
name may get overwritten in the process if it would have
|
||
conflicted. We need to also discard all conflicting altnames.
|
||
Recent fixes addressed ensuring that altnames get moved
|
||
with the main interface, which surfaced this problem.
|
||
analysis: 1. 该 CVE 信息与 namespace 相关，因为它提到在删除 net namespace 时出现的问题。具体来说，当一个网络命名空间（net namespace）被移除时，可能会触发内核错误（BUG()），并且涉及物理接口的处理和名称冲突。
|
||
|
||
2. 由于该漏洞涉及到网络命名空间（net namespace）的删除操作，而网络命名空间是容器隔离机制中的重要组成部分之一，因此它可能会影响容器的运行。如果在容器中删除网络命名空间时出现问题，可能会导致以下情况：
|
||
- 容器的网络配置异常。
|
||
- 在极端情况下，可能会影响宿主机的网络命名空间（init_net），从而影响其他容器或宿主机本身。
|
||
|
||
因此，这个 CVE 满足条件 1 和条件 2。
|
||
|
||
cve: ./data/2024/26xxx/CVE-2024-26865.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
|
||
|
||
syzkaller reported a warning of netns tracker [0] followed by KASAN
|
||
splat [1] and another ref tracker warning [1].
|
||
|
||
syzkaller could not find a repro, but in the log, the only suspicious
|
||
sequence was as follows:
|
||
|
||
18:26:22 executing program 1:
|
||
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
|
||
...
|
||
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
|
||
|
||
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
|
||
|
||
So, the scenario would be:
|
||
|
||
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
|
||
rds_tcp_listen_init().
|
||
2. syz-executor connect()s to it and creates a reqsk.
|
||
3. syz-executor exit()s immediately.
|
||
4. netns is dismantled. [0]
|
||
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
|
||
6. listener is freed after RCU grace period. [2]
|
||
|
||
Basically, reqsk assumes that the listener guarantees netns safety
|
||
until all reqsk timers are expired by holding the listener's refcount.
|
||
However, this was not the case for kernel sockets.
|
||
|
||
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
|
||
inet_twsk_purge()") fixed this issue only for per-netns ehash.
|
||
|
||
Let's apply the same fix for the global ehash.
|
||
|
||
[0]:
|
||
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
|
||
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
|
||
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
|
||
__sock_create (net/socket.c:1572)
|
||
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
|
||
rds_tcp_init_net (net/rds/tcp.c:577)
|
||
ops_init (net/core/net_namespace.c:137)
|
||
setup_net (net/core/net_namespace.c:340)
|
||
copy_net_ns (net/core/net_namespace.c:497)
|
||
create_new_namespaces (kernel/nsproxy.c:110)
|
||
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
|
||
ksys_unshare (kernel/fork.c:3429)
|
||
__x64_sys_unshare (kernel/fork.c:3496)
|
||
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
|
||
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
||
...
|
||
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
|
||
|
||
[1]:
|
||
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
||
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
||
Call Trace:
|
||
<IRQ>
|
||
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
|
||
print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
|
||
kasan_report (mm/kasan/report.c:603)
|
||
inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
||
reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
|
||
call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
|
||
__run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
|
||
run_timer_softirq (kernel/time/timer.c:2053)
|
||
__do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
|
||
irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
|
||
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
|
||
</IRQ>
|
||
|
||
Allocated by task 258 on cpu 0 at 83.612050s:
|
||
kasan_save_stack (mm/kasan/common.c:48)
|
||
kasan_save_track (mm/kasan/common.c:68)
|
||
__kasan_slab_alloc (mm/kasan/common.c:343)
|
||
kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
|
||
copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
|
||
create_new_namespaces (kernel/nsproxy.c:110)
|
||
unshare_nsproxy_name
|
||
---truncated---
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，这个 CVE 与 namespace 相关。具体来说，问题涉及 `unshare(CLONE_NEWNET)` 创建一个新的网络命名空间 (`netns`)，并且在该命名空间被拆除后，仍然存在对已释放资源的访问（Use-After-Free）。这直接影响了 Linux 的网络命名空间机制，而网络命名空间是容器（如 Docker）实现网络隔离的核心技术之一。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
可能会。由于问题发生在网络命名空间的销毁过程中，如果一个容器使用了独立的网络命名空间，并且触发了此漏洞，则可能会导致内核崩溃或其他未定义行为。这种情况下，不仅可能影响当前容器的稳定性，还可能波及宿主机或其他共享同一内核的容器。
|
||
|
||
3. **结论**：
|
||
根据上述分析，条件 1 和 2 均满足，因此返回相关信息而非 "N/A"。
|
||
|
||
cve: ./data/2024/29xxx/CVE-2024-29018.json
|
||
Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.
|
||
|
||
When containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.
|
||
|
||
Containers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.
|
||
|
||
In addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver.
|
||
|
||
When a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.
|
||
|
||
As a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.
|
||
|
||
Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected.
|
||
|
||
Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers.
|
||
|
||
Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.
|
||
|
||
Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace.
|
||
analysis: ### 分析结果
|
||
|
||
1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与容器和隔离相关。具体来说，问题涉及 Moby（Docker 的核心组件）在处理内部网络（`--internal` 网络）时的行为。`dockerd` 在转发 DNS 请求时绕过了容器网络命名空间的正常路由规则，导致内部网络上的容器可以意外地将 DNS 请求转发到外部名称服务器。这破坏了内部网络的设计初衷，即限制容器与外部网络的通信。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞可能导致容器在运行时影响宿主机或其他容器。攻击者可以通过注册一个受其控制的域名，并利用此漏洞让容器通过 DNS 查询向外发送数据，从而实现数据外泄。虽然这种行为不会直接破坏其他容器或宿主机的安全边界，但它允许容器突破内部网络的隔离限制，间接影响系统的安全性。
|
||
|
||
### 结论
|
||
条件 1 和 2 均满足，因此返回上述分析结果。
|
||
|
||
cve: ./data/2024/29xxx/CVE-2024-29964.json
|
||
Brocade SANnav versions before v2.3.0a do not correctly set permissions on files, including docker files. An unprivileged attacker who gains access to the server can read sensitive information from these files.
|
||
analysis: 1. 该 CVE 描述中提到权限设置不当的问题，涉及 "docker files"。这表明问题与 Docker 相关文件的权限配置有关，可能间接与容器技术相关，但并未明确提及 namespace、cgroup 或容器隔离机制本身。
|
||
|
||
2. 由于权限设置不当，可能导致未授权用户访问敏感信息。如果这些敏感信息与 Docker 的配置或运行时数据相关，则可能存在风险，使得攻击者利用此漏洞影响其他容器或宿主机。然而，描述中没有明确说明此问题是否可以直接突破容器隔离或直接影响其他容器及宿主机。
|
||
|
||
**结论**:
|
||
根据上述分析，条件 1 和 2 部分满足，因此返回以下分析结果：
|
||
|
||
1. 与容器（Docker 文件）相关，但未直接涉及 namespace、cgroup 或隔离机制。
|
||
2. 可能通过访问敏感信息间接影响其他容器或宿主机，但具体影响取决于敏感信息的内容和用途。
|
||
|
||
如果需要更精确的判断，建议进一步了解 "docker files" 的具体内容及其在系统中的作用。
|
||
|
||
cve: ./data/2024/29xxx/CVE-2024-29967.json
|
||
In Brocade SANnav before Brocade SANnav v2.31 and v2.3.0a, it was observed that Docker instances inside the appliance have insecure mount points, allowing reading and writing access to sensitive files. The vulnerability could allow a sudo privileged user on the host OS to read and write access to these files.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
该CVE提到Docker实例在设备内部存在不安全的挂载点，允许对敏感文件进行读写访问。这明确涉及容器（Docker）及其挂载点的安全性问题，因此与容器和隔离机制相关。
|
||
|
||
2. **分析是否会导致容器影响其他容器或宿主机**：
|
||
根据描述，漏洞允许具有sudo权限的用户在宿主机操作系统上读取和写入敏感文件。这意味着攻击者可以通过此漏洞突破容器隔离，进而影响宿主机或其他运行在宿主机上的容器。因此，该CVE确实可能导致容器影响宿主机和其他容器。
|
||
|
||
**结论**：满足条件1和条件2，不需要返回N/A。
|
||
|
||
cve: ./data/2024/31xxx/CVE-2024-31419.json
|
||
An information disclosure flaw was found in OpenShift Virtualization. The DownwardMetrics feature was introduced to expose host metrics to virtual machine guests and is enabled by default. This issue could expose limited host metrics of a node to any guest in any namespace without being explicitly enabled by an administrator.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
该CVE描述中提到“DownwardMetrics”功能会暴露宿主机的某些指标给虚拟机guest，且此功能默认启用。虽然主要涉及OpenShift Virtualization，但提到“namespace”，并且与虚拟机guest之间的隔离机制有关，因此可以认为它与namespace和隔离相关。
|
||
|
||
2. **分析是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||
该漏洞导致的是信息泄露问题，而非直接的权限提升或资源访问问题。尽管如此，由于任何guest都可以访问宿主机的部分指标，这可能会间接帮助攻击者了解宿主机的状态或架构，从而为进一步攻击提供线索。不过，这种信息泄露本身不会直接影响其他容器或宿主机的安全性。
|
||
|
||
3. **结论**：
|
||
条件1部分满足（与namespace和隔离相关），条件2不完全满足（不会直接影响其他容器或宿主机）。因此，返回以下分析结果：
|
||
|
||
```
|
||
1. 与namespace和隔离相关。
|
||
2. 不会导致容器直接影响其他容器或宿主机，但可能通过信息泄露间接辅助攻击。
|
||
```
|
||
|
||
cve: ./data/2024/31xxx/CVE-2024-31989.json
|
||
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It has been discovered that an unprivileged pod in a different namespace on the same cluster could connect to the Redis server on port 6379. Despite having installed the latest version of the VPC CNI plugin on the EKS cluster, it requires manual enablement through configuration to enforce network policies. This raises concerns that many clients might unknowingly have open access to their Redis servers. This vulnerability could lead to Privilege Escalation to the level of cluster controller, or to information leakage, affecting anyone who does not have strict access controls on their Redis instance. This issue has been patched in version(s) 2.8.19, 2.9.15 and 2.10.10.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE信息与namespace和容器隔离相关。问题描述中提到“unprivileged pod in a different namespace”（不同命名空间中的非特权Pod）能够连接到Redis服务器，这表明存在跨命名空间的访问问题。此外，问题涉及Kubernetes集群中的网络策略配置不足，可能导致容器间的隔离性被破坏。
|
||
|
||
2. **是否会导致容器（如Docker等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器影响其他容器或宿主机。由于未正确配置网络策略，非特权Pod可以访问Redis服务器，这可能引发权限提升或信息泄露。攻击者可能利用此漏洞进一步危害同一集群中的其他容器或甚至宿主机，具体取决于Redis服务器上存储的数据和权限。
|
||
|
||
3. **结论**：
|
||
该CVE满足条件1和条件2，因此不会返回“N/A”。
|
||
|
||
cve: ./data/2024/31xxx/CVE-2024-31994.json
|
||
Mealie is a self hosted recipe manager and meal planner. Prior to 1.4.0, an attacker can point the image request to an arbitrarily large file. Mealie will attempt to retrieve this file in whole. If it can be retrieved, it may be stored on the file system in whole (leading to possible disk consumption), however the more likely scenario given resource limitations is that the container will OOM during file retrieval if the target file size is greater than the allocated memory of the container. At best this can be used to force the container to infinitely restart due to OOM (if so configured in `docker-compose.yml), or at worst this can be used to force the Mealie container to crash and remain offline. In the event that the file can be retrieved, the lack of rate limiting on this endpoint also permits an attacker to generate ongoing requests to any target of their choice, potentially contributing to an external-facing DoS attack. This vulnerability is fixed in 1.4.0.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息明确提到 Mealie 运行在一个容器中（例如 Docker），并且描述了容器由于内存耗尽（OOM）而崩溃或无限重启的问题。这涉及到容器的资源限制（由 cgroup 管理）以及容器的隔离性。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
该漏洞可能导致 Mealie 容器因 OOM 而崩溃或无限重启，但没有直接证据表明它会影响其他容器或宿主机。然而，如果容器配置了共享资源池（例如未正确设置内存限制），则可能会间接影响其他容器的稳定性。此外，如果攻击者利用此漏洞生成大量外部请求，还可能引发更大范围的 DoS 攻击，从而间接影响宿主机或其他服务。
|
||
|
||
**结论：**
|
||
条件 1 和条件 2 部分满足，因此返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2024/32xxx/CVE-2024-32473.json
|
||
Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. In 26.0.0, IPv6 is not disabled on network interfaces, including those belonging to networks where `--ipv6=false`. An container with an `ipvlan` or `macvlan` interface will normally be configured to share an external network link with the host machine. Because of this direct access, (1) Containers may be able to communicate with other hosts on the local network over link-local IPv6 addresses, (2) if router advertisements are being broadcast over the local network, containers may get SLAAC-assigned addresses, and (3) the interface will be a member of IPv6 multicast groups. This means interfaces in IPv4-only networks present an unexpectedly and unnecessarily increased attack surface. The issue is patched in 26.0.2. To completely disable IPv6 in a container, use `--sysctl=net.ipv6.conf.all.disable_ipv6=1` in the `docker create` or `docker run` command. Or, in the service configuration of a `compose` file.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与容器和隔离相关。它描述了 Moby（Docker 的核心组件）在处理 IPv6 配置时的问题，特别是当 `--ipv6=false` 时，IPv6 并未正确禁用。这直接影响到使用 `ipvlan` 或 `macvlan` 接口的容器，这些接口通常用于共享主机的外部网络链接。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞可能导致容器影响其他容器或宿主机。由于 IPv6 未被正确禁用，容器可能会通过链路本地 IPv6 地址与其他主机通信，甚至可能通过 SLAAC 获取分配的地址。此外，容器的网络接口会加入 IPv6 多播组，从而增加攻击面。这种行为可能破坏预期的网络隔离，使容器能够访问不该访问的资源，或者让攻击者利用此漏洞从容器中发起针对宿主机或其他容器的攻击。
|
||
|
||
3. **结论：**
|
||
根据以上分析，条件 1 和条件 2 均满足，因此返回具体分析内容，而不是 "N/A"。
|
||
|
||
cve: ./data/2024/35xxx/CVE-2024-35139.json
|
||
IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could allow a local user to obtain sensitive information from the container due to incorrect default permissions. IBM X-Force ID: 292415.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 明确提到 IBM Security Access Manager 的 Docker 容器版本存在默认权限配置错误的问题，这直接影响到容器的安全性以及其隔离机制。因此，它与容器和隔离相关。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机**：
|
||
根据描述，由于默认权限配置不正确，本地用户可以利用此漏洞从容器中获取敏感信息。这种权限配置问题可能会破坏容器的隔离性，允许攻击者访问本应被隔离的数据。虽然描述中没有明确提到对其他容器或宿主机的影响，但权限配置错误通常可能进一步被利用来提升权限，从而影响宿主机或其他共享资源的容器。因此，存在一定的风险会影响宿主机或其它容器。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/35xxx/CVE-2024-35846.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
mm: zswap: fix shrinker NULL crash with cgroup_disable=memory
|
||
|
||
Christian reports a NULL deref in zswap that he bisected down to the zswap
|
||
shrinker. The issue also cropped up in the bug trackers of libguestfs [1]
|
||
and the Red Hat bugzilla [2].
|
||
|
||
The problem is that when memcg is disabled with the boot time flag, the
|
||
zswap shrinker might get called with sc->memcg == NULL. This is okay in
|
||
many places, like the lruvec operations. But it crashes in
|
||
memcg_page_state() - which is only used due to the non-node accounting of
|
||
cgroup's the zswap memory to begin with.
|
||
|
||
Nhat spotted that the memcg can be NULL in the memcg-disabled case, and I
|
||
was then able to reproduce the crash locally as well.
|
||
|
||
[1] https://github.com/libguestfs/libguestfs/issues/139
|
||
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2275252
|
||
analysis: 1. 该 CVE 信息与 cgroup 相关，因为问题涉及 `cgroup_disable=memory` 引发的内存控制组（memcg）为 NULL 的情况。此外，zswap 和 shrinker 的行为也与 cgroup 的内存管理有关。
|
||
|
||
2. 尽管该漏洞与 cgroup 相关，但它主要影响内核中 zswap 缩减器的行为，并不会直接影响容器（如 Docker）之间的隔离性或对宿主机的安全性造成威胁。此问题更倾向于在特定配置（如禁用 memcg）下引发崩溃，而不是导致容器逃逸或其他容器受影响的情况。
|
||
|
||
因此，最终分析结果是：
|
||
**N/A**
|
||
|
||
cve: ./data/2024/38xxx/CVE-2024-38564.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
|
||
|
||
bpf_prog_attach uses attach_type_to_prog_type to enforce proper
|
||
attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
|
||
bpf_prog_get and relies on bpf_prog_attach_check_attach_type
|
||
to properly verify prog_type <> attach_type association.
|
||
|
||
Add missing attach_type enforcement for the link_create case.
|
||
Otherwise, it's currently possible to attach cgroup_skb prog
|
||
types to other cgroup hooks.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**
|
||
该CVE涉及`BPF_PROG_TYPE_CGROUP_SKB`，这是Linux内核中用于cgroup（控制组）的eBPF程序类型。cgroup是容器技术（如Docker）实现资源限制和隔离的核心机制之一。因此，该漏洞与cgroup直接相关，也间接与容器和隔离机制相关。
|
||
|
||
2. **分析是否会导致容器在运行时影响其他容器或宿主机**
|
||
根据描述，问题在于缺少对`attach_type`的正确验证，可能导致`cgroup_skb`类型的eBPF程序被错误地附加到其他cgroup钩子上。这种错误可能会破坏预期的行为，甚至可能允许攻击者通过精心构造的eBPF程序影响其他cgroup或宿主机的资源管理逻辑。虽然具体影响未明确说明，但理论上这种漏洞可能被利用来绕过容器隔离，进而影响其他容器或宿主机的安全性。
|
||
|
||
**结论**：满足条件1和条件2，因此返回上述分析内容。
|
||
|
||
cve: ./data/2024/38xxx/CVE-2024-38663.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
blk-cgroup: fix list corruption from resetting io stat
|
||
|
||
Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"),
|
||
each iostat instance is added to blkcg percpu list, so blkcg_reset_stats()
|
||
can't reset the stat instance by memset(), otherwise the llist may be
|
||
corrupted.
|
||
|
||
Fix the issue by only resetting the counter part.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
该 CVE 提到 `blk-cgroup`，这是 Linux 内核中控制块设备 I/O 资源分配和限制的子系统，属于 cgroup（control group）的一部分。因此，该漏洞与 cgroup 相关，而 cgroup 是容器技术（如 Docker）实现资源隔离的重要组成部分。
|
||
|
||
2. **分析是否会影响其他容器或宿主机**：
|
||
该漏洞修复了 `blkcg_reset_stats()` 函数在重置 I/O 统计信息时可能导致链表（llist）损坏的问题。如果链表损坏，可能会导致不可预测的行为，例如内核崩溃或数据不一致。这种问题可能会影响使用相同 cgroup 的其他容器或宿主机的稳定性。因此，此漏洞有可能在特定条件下影响其他容器或宿主机。
|
||
|
||
**结论**：满足条件 1 和 2，无需返回 "N/A"。
|
||
|
||
cve: ./data/2024/39xxx/CVE-2024-39503.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type
|
||
|
||
Lion Ackermann reported that there is a race condition between namespace cleanup
|
||
in ipset and the garbage collection of the list:set type. The namespace
|
||
cleanup can destroy the list:set type of sets while the gc of the set type is
|
||
waiting to run in rcu cleanup. The latter uses data from the destroyed set which
|
||
thus leads use after free. The patch contains the following parts:
|
||
|
||
- When destroying all sets, first remove the garbage collectors, then wait
|
||
if needed and then destroy the sets.
|
||
- Fix the badly ordered "wait then remove gc" for the destroy a single set
|
||
case.
|
||
- Fix the missing rcu locking in the list:set type in the userspace test
|
||
case.
|
||
- Use proper RCU list handlings in the list:set type.
|
||
|
||
The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**
|
||
是的，该漏洞与namespace相关。描述中明确提到“namespace cleanup”和“list:set type”的竞争条件问题，这表明问题发生在网络命名空间（net namespace）的清理过程中。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**
|
||
有可能。由于该漏洞涉及命名空间的竞争条件，并且可能导致“use after free”问题，如果攻击者能够触发这一漏洞，可能会利用它破坏容器之间的隔离性，甚至影响宿主机的稳定性。具体来说，网络命名空间是容器实现网络隔离的重要组成部分，因此该漏洞可能被用来干扰其他容器或宿主机的网络配置。
|
||
|
||
**结论：满足条件1和条件2，需要进行分析。**
|
||
|
||
cve: ./data/2024/39xxx/CVE-2024-39690.json
|
||
Capsule is a multi-tenancy and policy-based framework for Kubernetes. In Capsule v0.7.0 and earlier, the tenant-owner can patch any arbitrary namespace that has not been taken over by a tenant (i.e., namespaces without the ownerReference field), thereby gaining control of that namespace.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 与 namespace 相关。Capsule 是一个基于 Kubernetes 的多租户框架，而问题的核心在于 tenant-owner 可以 patch 未被租户接管的任意 namespace（即没有 `ownerReference` 字段的 namespace）。这直接影响了 Kubernetes 中 namespace 的管理和控制。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
不会直接导致容器运行时影响其他容器或宿主机。此漏洞主要涉及 namespace 的管理权限问题，而不是容器运行时的隔离性或 cgroup 配置问题。虽然 namespace 是容器隔离的一部分，但这里的漏洞并不直接影响容器的运行时行为或宿主机的安全性。
|
||
|
||
3. **结论**：
|
||
由于条件 1 满足，条件 2 不满足，因此返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2024/3xxx/CVE-2024-3033.json
|
||
An improper authorization vulnerability exists in the mintplex-labs/anything-llm application, specifically within the '/api/v/' endpoint and its sub-routes. This flaw allows unauthenticated users to perform destructive actions on the VectorDB, including resetting the database and deleting specific namespaces, without requiring any authorization or permissions. The issue affects all versions up to and including the latest version, with a fix introduced in version 1.0.0. Exploitation of this vulnerability can lead to complete data loss of document embeddings across all workspaces, rendering workspace chats and embeddable chat widgets non-functional. Additionally, attackers can list all namespaces, potentially exposing private workspace names.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该漏洞涉及 "namespace"。描述中提到攻击者可以删除特定的 namespaces，并列出所有 namespaces，这表明问题与 namespaces 的管理和操作有关。然而，这里的 namespace 特指 VectorDB 中的数据组织单元，而非 Linux 命名空间（如用于容器隔离的 namespace）。因此，它与容器或隔离机制没有直接关联。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
不会。此漏洞仅影响 mintplex-labs/anything-llm 应用程序中的 VectorDB 数据管理功能，导致数据丢失或暴露。它并不涉及容器的底层技术（如 cgroup 或 namespace），也不会突破容器的隔离机制去影响其他容器或宿主机。
|
||
|
||
---
|
||
|
||
综上所述，虽然 CVE 提到 "namespace"，但它是数据库上下文中的概念，而不是容器隔离相关的 Linux 命名空间。同时，该漏洞不会对容器运行时或其他容器及宿主机产生影响。
|
||
|
||
**结论：N/A**
|
||
|
||
cve: ./data/2024/3xxx/CVE-2024-3056.json
|
||
A flaw was found in Podman. This issue may allow an attacker to create a specially crafted container that, when configured to share the same IPC with at least one other container, can create a large number of IPC resources in /dev/shm. The malicious container will continue to exhaust resources until it is out-of-memory (OOM) killed. While the malicious container's cgroup will be removed, the IPC resources it created are not. Those resources are tied to the IPC namespace that will not be removed until all containers using it are stopped, and one non-malicious container is holding the namespace open. The malicious container is restarted, either automatically or by attacker control, repeating the process and increasing the amount of memory consumed. With a container configured to restart always, such as `podman run --restart=always`, this can result in a memory-based denial of service of the system.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器隔离相关**：
|
||
是的，该 CVE 信息与 namespace 和 cgroup 直接相关。问题描述中提到 IPC（进程间通信）共享和 IPC 命名空间的概念，并且涉及 cgroup 的资源管理机制。攻击者通过创建恶意容器，在共享的 IPC 命名空间中生成大量 IPC 资源（如 `/dev/shm` 中的对象），导致资源耗尽。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器运行时影响其他容器或宿主机。具体来说，恶意容器可以消耗大量的内存资源（通过 `/dev/shm`），即使该容器被 OOM 杀死，其创建的 IPC 资源仍然存在，因为这些资源绑定到 IPC 命名空间，而 IPC 命名空间只有在所有使用它的容器停止后才会释放。如果有一个非恶意容器保持 IPC 命名空间打开，恶意容器可以反复重启并继续消耗更多内存，最终可能导致宿主机上的内存耗尽，引发系统级的拒绝服务（DoS）。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/40xxx/CVE-2024-40949.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
mm: shmem: fix getting incorrect lruvec when replacing a shmem folio
|
||
|
||
When testing shmem swapin, I encountered the warning below on my machine.
|
||
The reason is that replacing an old shmem folio with a new one causes
|
||
mem_cgroup_migrate() to clear the old folio's memcg data. As a result,
|
||
the old folio cannot get the correct memcg's lruvec needed to remove
|
||
itself from the LRU list when it is being freed. This could lead to
|
||
possible serious problems, such as LRU list crashes due to holding the
|
||
wrong LRU lock, and incorrect LRU statistics.
|
||
|
||
To fix this issue, we can fallback to use the mem_cgroup_replace_folio()
|
||
to replace the old shmem folio.
|
||
|
||
[ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960
|
||
[ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
|
||
[ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)
|
||
[ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000
|
||
[ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
|
||
[ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000
|
||
[ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
|
||
[ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000
|
||
[ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000
|
||
[ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled())
|
||
[ 5241.100338] ------------[ cut here ]------------
|
||
[ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150
|
||
[...]
|
||
[ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150
|
||
[ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150
|
||
[ 5241.100376] sp : ffff80008b38b930
|
||
[...]
|
||
[ 5241.100398] Call trace:
|
||
[ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150
|
||
[ 5241.100401] __page_cache_release+0x90/0x300
|
||
[ 5241.100404] __folio_put+0x50/0x108
|
||
[ 5241.100406] shmem_replace_folio+0x1b4/0x240
|
||
[ 5241.100409] shmem_swapin_folio+0x314/0x528
|
||
[ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930
|
||
[ 5241.100412] shmem_fault+0x74/0x160
|
||
[ 5241.100414] __do_fault+0x40/0x218
|
||
[ 5241.100417] do_shared_fault+0x34/0x1b0
|
||
[ 5241.100419] do_fault+0x40/0x168
|
||
[ 5241.100420] handle_pte_fault+0x80/0x228
|
||
[ 5241.100422] __handle_mm_fault+0x1c4/0x440
|
||
[ 5241.100424] handle_mm_fault+0x60/0x1f0
|
||
[ 5241.100426] do_page_fault+0x120/0x488
|
||
[ 5241.100429] do_translation_fault+0x4c/0x68
|
||
[ 5241.100431] do_mem_abort+0x48/0xa0
|
||
[ 5241.100434] el0_da+0x38/0xc0
|
||
[ 5241.100436] el0t_64_sync_handler+0x68/0xc0
|
||
[ 5241.100437] el0t_64_sync+0x14c/0x150
|
||
[ 5241.100439] ---[ end trace 0000000000000000 ]---
|
||
|
||
[baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，这个 CVE 信息与 cgroup 相关。问题的核心在于 `mem_cgroup_migrate()` 函数在替换旧的 shmem folio 时清除了旧 folio 的 memcg 数据，导致在释放旧 folio 时无法正确获取其所属的 LRUVec（与内存控制组相关的数据结构）。这表明该漏洞涉及内存控制组（cgroup）的功能。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
是的，可能会产生影响。由于问题涉及到内存控制组（cgroup），而 cgroup 是容器技术（如 Docker）实现资源隔离的重要组成部分，因此此漏洞可能导致以下情况：
|
||
- 容器内的内存管理出现问题，可能会影响宿主机或其他容器的稳定性。
|
||
- 错误的 LRU 统计或锁操作可能导致系统范围的内存管理混乱，从而间接影响其他容器或宿主机的正常运行。
|
||
|
||
3. **结论：**
|
||
根据上述分析，条件 1 和条件 2 均满足，因此需要返回具体的分析内容，而不是 "N/A"。
|
||
|
||
cve: ./data/2024/41xxx/CVE-2024-41000.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
block/ioctl: prefer different overflow check
|
||
|
||
Running syzkaller with the newly reintroduced signed integer overflow
|
||
sanitizer shows this report:
|
||
|
||
[ 62.982337] ------------[ cut here ]------------
|
||
[ 62.985692] cgroup: Invalid name
|
||
[ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46
|
||
[ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1
|
||
[ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long'
|
||
[ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1
|
||
[ 62.999369] random: crng reseeded on system resumption
|
||
[ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)
|
||
[ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
|
||
[ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
|
||
[ 63.000682] Call Trace:
|
||
[ 63.000686] <TASK>
|
||
[ 63.000731] dump_stack_lvl+0x93/0xd0
|
||
[ 63.000919] __get_user_pages+0x903/0xd30
|
||
[ 63.001030] __gup_longterm_locked+0x153e/0x1ba0
|
||
[ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50
|
||
[ 63.001072] ? try_get_folio+0x29c/0x2d0
|
||
[ 63.001083] internal_get_user_pages_fast+0x1119/0x1530
|
||
[ 63.001109] iov_iter_extract_pages+0x23b/0x580
|
||
[ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220
|
||
[ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410
|
||
[ 63.001297] __iomap_dio_rw+0xab4/0x1810
|
||
[ 63.001316] iomap_dio_rw+0x45/0xa0
|
||
[ 63.001328] ext4_file_write_iter+0xdde/0x1390
|
||
[ 63.001372] vfs_write+0x599/0xbd0
|
||
[ 63.001394] ksys_write+0xc8/0x190
|
||
[ 63.001403] do_syscall_64+0xd4/0x1b0
|
||
[ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60
|
||
[ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
||
[ 63.001535] RIP: 0033:0x7f7fd3ebf539
|
||
[ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
||
[ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
||
[ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539
|
||
[ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004
|
||
[ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000
|
||
[ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
||
[ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8
|
||
...
|
||
[ 63.018142] ---[ end trace ]---
|
||
|
||
Historically, the signed integer overflow sanitizer did not work in the
|
||
kernel due to its interaction with `-fwrapv` but this has since been
|
||
changed [1] in the newest version of Clang; It was re-enabled in the
|
||
kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow
|
||
sanitizer").
|
||
|
||
Let's rework this overflow checking logic to not actually perform an
|
||
overflow during the check itself, thus avoiding the UBSAN splat.
|
||
|
||
[1]: https://github.com/llvm/llvm-project/pull/82432
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**
|
||
从描述中可以看到，这个漏洞涉及 `cgroup: Invalid name` 的信息，表明它与 cgroup（控制组）相关。cgroup 是 Linux 内核中的一个功能模块，用于限制、记录和隔离进程组的资源（如 CPU、内存、磁盘 I/O 等）。因此，这个 CVE 与 cgroup 直接相关，而 cgroup 是容器技术（如 Docker）实现资源隔离的重要组成部分。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机**
|
||
虽然这个漏洞涉及到 cgroup，但从描述来看，主要问题是一个整数溢出检查逻辑的问题，导致 UBSAN（Undefined Behavior Sanitizer）触发了一个警告（splat）。这种问题通常不会直接导致容器突破隔离，也不会直接影响其他容器或宿主机的安全性。然而，如果攻击者能够利用这个整数溢出问题触发更严重的后果（如内存损坏或内核崩溃），则可能间接影响容器的稳定性或宿主机的安全性。但根据目前提供的信息，没有明确证据表明该漏洞可以直接被利用来突破容器隔离。
|
||
|
||
3. **结论**
|
||
根据上述分析，这个 CVE 与 cgroup 相关，但没有明确证据表明它会导致容器突破隔离或影响其他容器及宿主机。因此，最终结论为：
|
||
**N/A**
|
||
|
||
cve: ./data/2024/41xxx/CVE-2024-41010.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
bpf: Fix too early release of tcx_entry
|
||
|
||
Pedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported
|
||
an issue that the tcx_entry can be released too early leading to a use
|
||
after free (UAF) when an active old-style ingress or clsact qdisc with a
|
||
shared tc block is later replaced by another ingress or clsact instance.
|
||
|
||
Essentially, the sequence to trigger the UAF (one example) can be as follows:
|
||
|
||
1. A network namespace is created
|
||
2. An ingress qdisc is created. This allocates a tcx_entry, and
|
||
&tcx_entry->miniq is stored in the qdisc's miniqp->p_miniq. At the
|
||
same time, a tcf block with index 1 is created.
|
||
3. chain0 is attached to the tcf block. chain0 must be connected to
|
||
the block linked to the ingress qdisc to later reach the function
|
||
tcf_chain0_head_change_cb_del() which triggers the UAF.
|
||
4. Create and graft a clsact qdisc. This causes the ingress qdisc
|
||
created in step 1 to be removed, thus freeing the previously linked
|
||
tcx_entry:
|
||
|
||
rtnetlink_rcv_msg()
|
||
=> tc_modify_qdisc()
|
||
=> qdisc_create()
|
||
=> clsact_init() [a]
|
||
=> qdisc_graft()
|
||
=> qdisc_destroy()
|
||
=> __qdisc_destroy()
|
||
=> ingress_destroy() [b]
|
||
=> tcx_entry_free()
|
||
=> kfree_rcu() // tcx_entry freed
|
||
|
||
5. Finally, the network namespace is closed. This registers the
|
||
cleanup_net worker, and during the process of releasing the
|
||
remaining clsact qdisc, it accesses the tcx_entry that was
|
||
already freed in step 4, causing the UAF to occur:
|
||
|
||
cleanup_net()
|
||
=> ops_exit_list()
|
||
=> default_device_exit_batch()
|
||
=> unregister_netdevice_many()
|
||
=> unregister_netdevice_many_notify()
|
||
=> dev_shutdown()
|
||
=> qdisc_put()
|
||
=> clsact_destroy() [c]
|
||
=> tcf_block_put_ext()
|
||
=> tcf_chain0_head_change_cb_del()
|
||
=> tcf_chain_head_change_item()
|
||
=> clsact_chain_head_change()
|
||
=> mini_qdisc_pair_swap() // UAF
|
||
|
||
There are also other variants, the gist is to add an ingress (or clsact)
|
||
qdisc with a specific shared block, then to replace that qdisc, waiting
|
||
for the tcx_entry kfree_rcu() to be executed and subsequently accessing
|
||
the current active qdisc's miniq one way or another.
|
||
|
||
The correct fix is to turn the miniq_active boolean into a counter. What
|
||
can be observed, at step 2 above, the counter transitions from 0->1, at
|
||
step [a] from 1->2 (in order for the miniq object to remain active during
|
||
the replacement), then in [b] from 2->1 and finally [c] 1->0 with the
|
||
eventual release. The reference counter in general ranges from [0,2] and
|
||
it does not need to be atomic since all access to the counter is protected
|
||
by the rtnl mutex. With this in place, there is no longer a UAF happening
|
||
and the tcx_entry is freed at the correct time.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**
|
||
是的，这个 CVE 信息与 namespace 相关。具体来说，问题涉及到网络命名空间 (network namespace) 的使用。在步骤 1 中明确提到创建了一个网络命名空间，并且后续的操作（如 qdisc 的创建和销毁）都在该命名空间中进行。网络命名空间是 Linux 容器（如 Docker）实现网络隔离的重要组成部分。
|
||
|
||
2. **分析是否会导致容器在运行时影响其他容器或宿主机**
|
||
这个漏洞可能导致 Use-After-Free (UAF) 问题，从而可能被利用来破坏容器的隔离性。具体来说，如果攻击者能够在容器内触发此漏洞，则可能通过 UAF 访问或操控已经释放的内存，进而影响宿主机或其他容器的稳定性甚至安全性。虽然该漏洞本身并不直接针对容器技术，但由于它涉及网络命名空间，而网络命名空间是容器网络隔离的核心机制之一，因此该漏洞可能会间接影响容器的隔离性。
|
||
|
||
3. **结论**
|
||
条件 1 和条件 2 均满足，因此需要返回上述分析内容，而不是 "N/A"。
|
||
|
||
cve: ./data/2024/41xxx/CVE-2024-41110.json
|
||
Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.
|
||
|
||
Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.
|
||
|
||
A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.
|
||
|
||
Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.
|
||
|
||
docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
该 CVE 描述的是 Docker Engine 中的一个授权插件 (AuthZ) 绕过漏洞，涉及 API 请求的处理。虽然它与容器技术（Docker）相关，但并未直接提到或涉及 namespace、cgroup 或容器隔离机制。
|
||
|
||
2. **分析是否会导致容器在运行时影响其他容器或宿主机**：
|
||
此漏洞允许通过精心构造的 API 请求绕过授权检查，从而可能导致未经授权的操作，包括潜在的权限提升。如果攻击者利用此漏洞成功绕过授权插件，他们可能执行未被允许的操作，例如访问或修改其他容器资源，甚至可能影响宿主机的安全性。因此，该漏洞有可能导致容器运行时影响其他容器或宿主机。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 至少有一个满足，因此返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2024/41xxx/CVE-2024-41932.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
sched: fix warning in sched_setaffinity
|
||
|
||
Commit 8f9ea86fdf99b added some logic to sched_setaffinity that included
|
||
a WARN when a per-task affinity assignment races with a cpuset update.
|
||
|
||
Specifically, we can have a race where a cpuset update results in the
|
||
task affinity no longer being a subset of the cpuset. That's fine; we
|
||
have a fallback to instead use the cpuset mask. However, we have a WARN
|
||
set up that will trigger if the cpuset mask has no overlap at all with
|
||
the requested task affinity. This shouldn't be a warning condition; its
|
||
trivial to create this condition.
|
||
|
||
Reproduced the warning by the following setup:
|
||
|
||
- $PID inside a cpuset cgroup
|
||
- another thread repeatedly switching the cpuset cpus from 1-2 to just 1
|
||
- another thread repeatedly setting the $PID affinity (via taskset) to 2
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**
|
||
是的，这个 CVE 信息与 cgroup 和隔离相关。问题涉及到 `sched_setaffinity` 函数中任务亲和性（task affinity）与 cpuset 更新之间的竞争条件。`cpuset` 是 Linux 控制组（cgroup）子系统的一部分，用于限制进程可以在哪些 CPU 上运行以及可以访问哪些内存节点。因此，这个问题直接涉及 cgroup 的功能。
|
||
|
||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**
|
||
可能会。由于问题涉及到 `cpuset` 和任务亲和性的竞争条件，如果一个容器的任务亲和性设置与宿主机的 cpuset 配置发生冲突，可能会触发警告（WARN）。虽然当前的修复只是去掉了不必要的警告，但如果类似的竞争条件未被妥善处理，可能会导致更严重的问题，例如任务调度异常或性能下降。这种异常可能会影响同一宿主机上的其他容器或宿主机本身。
|
||
|
||
### 结论：
|
||
- 该 CVE 与 cgroup 和容器隔离相关。
|
||
- 存在潜在风险，可能影响同一宿主机上的其他容器或宿主机。
|
||
|
||
cve: ./data/2024/41xxx/CVE-2024-41968.json
|
||
A low privileged remote attacker may modify the docker settings setup of the device, leading to a limited DoS.
|
||
analysis: 1. 该 CVE 描述中提到 "docker settings"，因此与容器（Docker）相关。
|
||
2. 攻击者可以修改 Docker 的设置，导致有限的拒绝服务（DoS）。这可能会影响其他容器或宿主机的正常运行，因为 Docker 设置的更改可能会波及到整个 Docker 环境及其上的所有容器。
|
||
|
||
结论：满足条件 1 和条件 2。
|
||
|
||
cve: ./data/2024/41xxx/CVE-2024-41997.json
|
||
An issue was discovered in version of Warp Terminal prior to 2024.07.18 (v0.2024.07.16.08.02). A command injection vulnerability exists in the Docker integration functionality. An attacker can create a specially crafted hyperlink using the `warp://action/docker/open_subshell` intent that when clicked by the victim results in command execution on the victim's machine.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与容器相关。问题出现在 Warp Terminal 的 Docker 集成功能中，涉及通过 `warp://action/docker/open_subshell` 意图触发的操作，这表明它与 Docker 容器的交互有关。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
这个漏洞可能导致命令注入，从而使攻击者能够在受害者的机器上执行命令。由于命令执行发生在受害者机器上，而该功能与 Docker 集成相关，因此有可能利用此漏洞影响宿主机或宿主机上的其他容器，具体取决于攻击者注入的命令以及 Docker 环境的配置。
|
||
|
||
**结论：**
|
||
- 该漏洞与容器和隔离机制相关。
|
||
- 可能会影响宿主机或其他容器，具体取决于攻击场景和环境配置。
|
||
|
||
cve: ./data/2024/42xxx/CVE-2024-42486.json
|
||
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. In versions on the 1.15.x branch prior to 1.15.8 and the 1.16.x branch prior to 1.16.1, ReferenceGrant changes are not correctly propagated in Cilium's GatewayAPI controller, which could lead to Gateway resources being able to access secrets for longer than intended, or to Routes having the ability to forward traffic to backends in other namespaces for longer than intended. This issue has been patched in Cilium v1.15.8 and v1.16.1. As a workaround, any modification of a related Gateway/HTTPRoute/GRPCRoute/TCPRoute CRD (for example, adding any label to any of these resources) will trigger a reconciliation of ReferenceGrants on an affected cluster.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 与 namespace 相关。问题描述中提到 "Routes having the ability to forward traffic to backends in other namespaces for longer than intended"，这表明由于 ReferenceGrant 的传播错误，可能导致某些资源（如 Gateway 或 Route）访问其他命名空间中的后端服务或敏感数据。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
虽然该问题涉及跨命名空间的流量转发，但它主要影响 Cilium 的网络控制平面和 GatewayAPI 的行为，而不是直接破坏容器的隔离性或影响宿主机的安全性。因此，虽然它可能间接影响容器间的通信（例如，允许不适当的跨命名空间访问），但不会直接导致容器逃逸或直接影响宿主机。
|
||
|
||
**结论：**
|
||
该 CVE 与 namespace 和容器网络相关，可能间接影响容器间的隔离性，但不会直接影响宿主机或其他容器的安全性。
|
||
|
||
cve: ./data/2024/43xxx/CVE-2024-43397.json
|
||
Apollo is a configuration management system. A vulnerability exists in the synchronization configuration feature that allows users to craft specific requests to bypass permission checks. This exploit enables them to modify a namespace without the necessary permissions. The issue was addressed with an input parameter check which was released in version 2.3.0.
|
||
analysis: 1. 该 CVE 信息与 namespace 相关，因为它提到了用户可以通过构造特定请求绕过权限检查来修改 namespace。然而，这里的 namespace 是指 Apollo 配置管理系统中的配置命名空间，而不是操作系统或容器相关的 namespace。
|
||
|
||
2. 该 CVE 不涉及容器（如 Docker）的运行时行为，也不会影响其他容器或宿主机。它仅影响 Apollo 配置管理系统的权限控制机制。
|
||
|
||
3. 由于条件 1 和 2 中的部分内容不完全满足（仅与 Apollo 系统中的 namespace 相关，但不涉及容器或隔离技术），因此不符合完全不满足的 N/A 条件。
|
||
|
||
**结论：N/A**
|
||
|
||
cve: ./data/2024/43xxx/CVE-2024-43803.json
|
||
The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere).
|
||
|
||
BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a `BareMetalHost`. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.
|
||
|
||
The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.
|
||
analysis: 1. **分析这个CVE信息是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE与namespace相关。问题的核心在于Bare Metal Operator (BMO) 在处理 `Secret` 时，允许从任意namespace读取数据，而不是限制在当前namespace内。这破坏了Kubernetes中namespace之间的隔离性。
|
||
|
||
2. **分析这个CVE是否会导致容器（例如Docker等）在运行时会影响其他容器或宿主机：**
|
||
不会直接影响容器或宿主机。此漏洞主要影响的是Kubernetes中的namespace隔离机制，使得具有特定权限的用户可以跨namespace访问敏感数据（如Secret）。虽然它不直接涉及容器运行时的行为，但间接可能导致敏感信息泄露，从而对整个集群的安全性造成威胁。
|
||
|
||
3. **结论：**
|
||
由于条件1满足，条件2不满足，因此返回以下分析结果：
|
||
- 与namespace隔离相关，可能导致跨namespace的数据泄露。
|
||
- 不直接影响容器运行时或其他容器/宿主机的安全性。
|
||
|
||
cve: ./data/2024/43xxx/CVE-2024-43853.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
cgroup/cpuset: Prevent UAF in proc_cpuset_show()
|
||
|
||
An UAF can happen when /proc/cpuset is read as reported in [1].
|
||
|
||
This can be reproduced by the following methods:
|
||
1.add an mdelay(1000) before acquiring the cgroup_lock In the
|
||
cgroup_path_ns function.
|
||
2.$cat /proc/<pid>/cpuset repeatly.
|
||
3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/
|
||
$umount /sys/fs/cgroup/cpuset/ repeatly.
|
||
|
||
The race that cause this bug can be shown as below:
|
||
|
||
(umount) | (cat /proc/<pid>/cpuset)
|
||
css_release | proc_cpuset_show
|
||
css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id);
|
||
css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...);
|
||
cgroup_destroy_root | mutex_lock(&cgroup_mutex);
|
||
rebind_subsystems |
|
||
cgroup_free_root |
|
||
| // cgrp was freed, UAF
|
||
| cgroup_path_ns_locked(cgrp,..);
|
||
|
||
When the cpuset is initialized, the root node top_cpuset.css.cgrp
|
||
will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will
|
||
allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated
|
||
&cgroup_root.cgrp. When the umount operation is executed,
|
||
top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.
|
||
|
||
The problem is that when rebinding to cgrp_dfl_root, there are cases
|
||
where the cgroup_root allocated by setting up the root for cgroup v1
|
||
is cached. This could lead to a Use-After-Free (UAF) if it is
|
||
subsequently freed. The descendant cgroups of cgroup v1 can only be
|
||
freed after the css is released. However, the css of the root will never
|
||
be released, yet the cgroup_root should be freed when it is unmounted.
|
||
This means that obtaining a reference to the css of the root does
|
||
not guarantee that css.cgrp->root will not be freed.
|
||
|
||
Fix this problem by using rcu_read_lock in proc_cpuset_show().
|
||
As cgroup_root is kfree_rcu after commit d23b5c577715
|
||
("cgroup: Make operations on the cgroup root_list RCU safe"),
|
||
css->cgroup won't be freed during the critical section.
|
||
To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to
|
||
replace task_get_css with task_css.
|
||
|
||
[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器隔离相关**：
|
||
是的，该 CVE 信息与 cgroup 直接相关。具体来说，问题出现在 `proc_cpuset_show()` 函数中，涉及到 cgroup 的 cpuset 子系统。Cgroup 是 Linux 内核中的一个关键特性，用于限制和隔离资源使用（如 CPU、内存等），并且是容器技术（如 Docker）实现资源隔离的基础。
|
||
|
||
2. **是否会导致容器运行时影响其他容器或宿主机**：
|
||
这个漏洞可能导致 Use-After-Free (UAF) 问题，从而可能引发系统不稳定或被恶意利用来执行任意代码。由于 cgroup 是容器隔离的核心机制之一，如果攻击者能够利用此漏洞，可能会破坏容器之间的隔离性，甚至影响宿主机的稳定性。例如，通过触发 UAF，攻击者可能访问或操控其他容器或宿主机的资源。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均满足，因此需要返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2024/43xxx/CVE-2024-43888.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
mm: list_lru: fix UAF for memory cgroup
|
||
|
||
The mem_cgroup_from_slab_obj() is supposed to be called under rcu lock or
|
||
cgroup_mutex or others which could prevent returned memcg from being
|
||
freed. Fix it by adding missing rcu read lock.
|
||
|
||
Found by code inspection.
|
||
|
||
[songmuchun@bytedance.com: only grab rcu lock when necessary, per Vlastimil]
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 与 cgroup 相关。具体来说，问题出现在 `mem_cgroup_from_slab_obj()` 函数中，该函数用于从 slab 对象中获取内存控制组（memory cgroup）。cgroup 是 Linux 内核中用于限制和隔离资源使用的重要机制，广泛应用于容器技术（如 Docker）中以实现资源隔离。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
可能会。由于该漏洞涉及内存 cgroup 的使用，如果未正确处理 RCU 锁，可能会导致 Use-After-Free (UAF) 问题。这种问题可能被恶意利用，从而破坏内存隔离性。在容器环境中，这可能导致一个容器访问或影响其他容器或宿主机的内存资源，进而引发安全风险。
|
||
|
||
**结论**：满足条件 1 和 2，因此需要进行上述分析。
|
||
|
||
cve: ./data/2024/43xxx/CVE-2024-43892.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
memcg: protect concurrent access to mem_cgroup_idr
|
||
|
||
Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after
|
||
many small jobs") decoupled the memcg IDs from the CSS ID space to fix the
|
||
cgroup creation failures. It introduced IDR to maintain the memcg ID
|
||
space. The IDR depends on external synchronization mechanisms for
|
||
modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace()
|
||
happen within css callback and thus are protected through cgroup_mutex
|
||
from concurrent modifications. However idr_remove() for mem_cgroup_idr
|
||
was not protected against concurrency and can be run concurrently for
|
||
different memcgs when they hit their refcnt to zero. Fix that.
|
||
|
||
We have been seeing list_lru based kernel crashes at a low frequency in
|
||
our fleet for a long time. These crashes were in different part of
|
||
list_lru code including list_lru_add(), list_lru_del() and reparenting
|
||
code. Upon further inspection, it looked like for a given object (dentry
|
||
and inode), the super_block's list_lru didn't have list_lru_one for the
|
||
memcg of that object. The initial suspicions were either the object is
|
||
not allocated through kmem_cache_alloc_lru() or somehow
|
||
memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
|
||
returned success. No evidence were found for these cases.
|
||
|
||
Looking more deeply, we started seeing situations where valid memcg's id
|
||
is not present in mem_cgroup_idr and in some cases multiple valid memcgs
|
||
have same id and mem_cgroup_idr is pointing to one of them. So, the most
|
||
reasonable explanation is that these situations can happen due to race
|
||
between multiple idr_remove() calls or race between
|
||
idr_alloc()/idr_replace() and idr_remove(). These races are causing
|
||
multiple memcgs to acquire the same ID and then offlining of one of them
|
||
would cleanup list_lrus on the system for all of them. Later access from
|
||
other memcgs to the list_lru cause crashes due to missing list_lru_one.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，这个 CVE 信息与 cgroup（控制组）直接相关。具体来说，问题出在 `memcg`（内存控制组）中对 `mem_cgroup_idr` 的并发访问保护不足。`memcg` 是 Linux 内核中用于管理内存资源分配和限制的重要机制，广泛应用于容器技术（如 Docker）中的资源隔离。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
是的，这个问题可能会导致容器运行时影响其他容器或宿主机。由于 `memcg` 是容器资源隔离的核心组件之一，如果 `mem_cgroup_idr` 的并发访问未被正确保护，可能导致以下后果：
|
||
- 不同容器之间的内存资源分配出现竞争或冲突。
|
||
- 宿主机上的全局内存管理结构（如 `list_lru`）可能因错误的清理操作而崩溃，进而影响整个系统的稳定性。
|
||
- 某个容器的资源释放操作可能误删其他容器或宿主机的内存管理数据结构，导致系统不稳定或崩溃。
|
||
|
||
因此，该漏洞确实可能破坏容器之间的隔离性，并对宿主机造成潜在威胁。
|
||
|
||
**结论：满足条件 1 和 2。**
|
||
|
||
cve: ./data/2024/44xxx/CVE-2024-44975.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
cgroup/cpuset: fix panic caused by partcmd_update
|
||
|
||
We find a bug as below:
|
||
BUG: unable to handle page fault for address: 00000003
|
||
PGD 0 P4D 0
|
||
Oops: 0000 [#1] PREEMPT SMP NOPTI
|
||
CPU: 3 PID: 358 Comm: bash Tainted: G W I 6.6.0-10893-g60d6
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4
|
||
RIP: 0010:partition_sched_domains_locked+0x483/0x600
|
||
Code: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9
|
||
RSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202
|
||
RAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000
|
||
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80
|
||
RBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000
|
||
R10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002
|
||
R13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000
|
||
FS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0
|
||
Call Trace:
|
||
<TASK>
|
||
? show_regs+0x8c/0xa0
|
||
? __die_body+0x23/0xa0
|
||
? __die+0x3a/0x50
|
||
? page_fault_oops+0x1d2/0x5c0
|
||
? partition_sched_domains_locked+0x483/0x600
|
||
? search_module_extables+0x2a/0xb0
|
||
? search_exception_tables+0x67/0x90
|
||
? kernelmode_fixup_or_oops+0x144/0x1b0
|
||
? __bad_area_nosemaphore+0x211/0x360
|
||
? up_read+0x3b/0x50
|
||
? bad_area_nosemaphore+0x1a/0x30
|
||
? exc_page_fault+0x890/0xd90
|
||
? __lock_acquire.constprop.0+0x24f/0x8d0
|
||
? __lock_acquire.constprop.0+0x24f/0x8d0
|
||
? asm_exc_page_fault+0x26/0x30
|
||
? partition_sched_domains_locked+0x483/0x600
|
||
? partition_sched_domains_locked+0xf0/0x600
|
||
rebuild_sched_domains_locked+0x806/0xdc0
|
||
update_partition_sd_lb+0x118/0x130
|
||
cpuset_write_resmask+0xffc/0x1420
|
||
cgroup_file_write+0xb2/0x290
|
||
kernfs_fop_write_iter+0x194/0x290
|
||
new_sync_write+0xeb/0x160
|
||
vfs_write+0x16f/0x1d0
|
||
ksys_write+0x81/0x180
|
||
__x64_sys_write+0x21/0x30
|
||
x64_sys_call+0x2f25/0x4630
|
||
do_syscall_64+0x44/0xb0
|
||
entry_SYSCALL_64_after_hwframe+0x78/0xe2
|
||
RIP: 0033:0x7f44a553c887
|
||
|
||
It can be reproduced with cammands:
|
||
cd /sys/fs/cgroup/
|
||
mkdir test
|
||
cd test/
|
||
echo +cpuset > ../cgroup.subtree_control
|
||
echo root > cpuset.cpus.partition
|
||
cat /sys/fs/cgroup/cpuset.cpus.effective
|
||
0-3
|
||
echo 0-3 > cpuset.cpus // taking away all cpus from root
|
||
|
||
This issue is caused by the incorrect rebuilding of scheduling domains.
|
||
In this scenario, test/cpuset.cpus.partition should be an invalid root
|
||
and should not trigger the rebuilding of scheduling domains. When calling
|
||
update_parent_effective_cpumask with partcmd_update, if newmask is not
|
||
null, it should recheck newmask whether there are cpus is available
|
||
for parect/cs that has tasks.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**
|
||
是的，这个 CVE 信息与 cgroup 和容器隔离相关。具体来说，问题出现在 `cgroup/cpuset` 的实现中，涉及调度域（scheduling domains）的重建逻辑。`cpuset` 是 cgroup 的一个子系统，用于限制进程可以使用的 CPU 和内存节点。因此，该漏洞直接影响 cgroup 的功能，而 cgroup 是容器技术（如 Docker）实现资源隔离的核心组件。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机**
|
||
是的，该漏洞可能导致容器运行时影响其他容器或宿主机。由于问题发生在 `cpuset.cpus.partition` 的处理过程中，错误的调度域重建可能导致以下情况：
|
||
- 宿主机的 CPU 调度混乱，影响整个系统的稳定性。
|
||
- 如果容器通过 cgroup 配置了 CPU 分配，错误的调度域重建可能允许容器访问未分配给它的 CPU 资源，从而破坏隔离性。
|
||
- 在极端情况下，可能会导致内核崩溃（panic），进而影响所有运行中的容器和宿主机本身。
|
||
|
||
3. **结论**
|
||
条件 1 和 2 均满足，因此需要返回分析结果。
|
||
|
||
cve: ./data/2024/45xxx/CVE-2024-45310.json
|
||
runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.
|
||
|
||
Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual
|
||
user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该 CVE 与容器和隔离相关。具体来说，它涉及 `runc` 工具（用于根据 OCI 规范运行容器）以及容器之间的共享卷配置。问题的核心是一个竞争条件漏洞，攻击者可以通过共享卷在宿主机文件系统中创建空文件或目录。
|
||
|
||
2. **分析是否会导致容器在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器影响宿主机或其他容器。攻击者可以利用此漏洞通过共享卷在宿主机文件系统的任意位置创建空文件或目录。虽然现有文件不会被截断，但这种行为可能破坏宿主机的文件系统完整性，从而间接影响其他容器的正常运行。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均满足，因此返回上述分析结果。
|
||
|
||
cve: ./data/2024/45xxx/CVE-2024-45313.json
|
||
Overleaf is a web-based collaborative LaTeX editor. When installing Server Pro using the Overleaf Toolkit from before 2024-07-17 or legacy docker-compose.yml from before 2024-08-28, the configuration for LaTeX compiles was insecure by default, requiring the administrator to enable the security features via a configuration setting (`SIBLING_CONTAINERS_ENABLED` in Toolkit, `SANDBOXED_COMPILES` in legacy docker-compose/custom deployments). If these security features are not enabled then users have access to the `sharelatex` container resources (filesystem, network, environment variables) when running compiles, leading to multiple file access vulnerabilities, either directly or via symlinks created during compiles. The setting has now been changed to be secure by default for new installs in the Toolkit and legacy docker-compose deployment. The Overleaf Toolkit has been updated to set `SIBLING_CONTAINERS_ENABLED=true` by default for new installs. It is recommended that any existing installations using the previous default setting migrate to using sibling containers. Existing installations can set `SIBLING_CONTAINERS_ENABLED=true` in `config/overleaf.rc` as a mitigation. In legacy docker-compose/custom deployments `SANDBOXED_COMPILES=true` should be used.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE信息明确提到与容器（`sharelatex` 容器）及其资源访问相关。具体来说，如果未启用安全特性（如 `SIBLING_CONTAINERS_ENABLED` 或 `SANDBOXED_COMPILES`），用户可以在运行 LaTeX 编译时访问容器的文件系统、网络和环境变量，这涉及容器的隔离问题。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机：**
|
||
是的，由于默认配置不安全，用户可以访问 `sharelatex` 容器的资源（包括文件系统、网络等）。这种访问权限可能会被滥用，从而影响其他容器或宿主机的安全性。例如，通过文件系统访问或网络操作，攻击者可能进一步突破隔离边界，危害整个容器环境或宿主机。
|
||
|
||
**结论：满足条件1和条件2。**
|
||
|
||
cve: ./data/2024/45xxx/CVE-2024-45497.json
|
||
A flaw was found in the OpenShift build process, where the docker-build container is configured with a hostPath volume mount that maps the node's /var/lib/kubelet/config.json file into the build pod. This file contains sensitive credentials necessary for pulling images from private repositories. The mount is not read-only, which allows the attacker to overwrite it. By modifying the config.json file, the attacker can cause a denial of service by preventing the node from pulling new images and potentially exfiltrating sensitive secrets. This flaw impacts the availability of services dependent on image pulls and exposes sensitive information to unauthorized parties.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 与容器和隔离相关。问题出现在 OpenShift 的构建过程中，涉及 `docker-build` 容器配置了一个 `hostPath` 卷挂载，将宿主机的 `/var/lib/kubelet/config.json` 文件映射到构建 Pod 中。由于挂载不是只读的，攻击者可以修改该文件，从而破坏节点的正常功能并泄露敏感信息。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，此漏洞会影响宿主机和其他容器。通过修改 `/var/lib/kubelet/config.json` 文件，攻击者可以阻止节点拉取新镜像，导致依赖这些镜像的服务不可用（DoS）。此外，攻击者还可以窃取文件中的敏感凭据，进一步威胁宿主机的安全性，并可能利用这些凭据访问私有镜像仓库或其他资源。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/49xxx/CVE-2024-49974.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
NFSD: Limit the number of concurrent async COPY operations
|
||
|
||
Nothing appears to limit the number of concurrent async COPY
|
||
operations that clients can start. In addition, AFAICT each async
|
||
COPY can copy an unlimited number of 4MB chunks, so can run for a
|
||
long time. Thus IMO async COPY can become a DoS vector.
|
||
|
||
Add a restriction mechanism that bounds the number of concurrent
|
||
background COPY operations. Start simple and try to be fair -- this
|
||
patch implements a per-namespace limit.
|
||
|
||
An async COPY request that occurs while this limit is exceeded gets
|
||
NFS4ERR_DELAY. The requesting client can choose to send the request
|
||
again after a delay or fall back to a traditional read/write style
|
||
copy.
|
||
|
||
If there is need to make the mechanism more sophisticated, we can
|
||
visit that in future patches.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，此 CVE 与 namespace 相关。漏洞描述中提到实现了一个“per-namespace limit”机制，用于限制每个命名空间中并发的异步 COPY 操作数量。这表明该漏洞涉及 Linux 命名空间的使用。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
可能会。由于该漏洞涉及到 NFS 异步 COPY 操作的限制机制，并且是基于命名空间的限制，如果一个容器（或客户端）滥用异步 COPY 操作（例如发起大量请求），可能会导致资源耗尽，从而影响同一宿主机上的其他容器或宿主机本身。这种行为可能成为一种 DoS（拒绝服务）攻击向量。
|
||
|
||
因此，该 CVE 满足条件 1 和条件 2。
|
||
|
||
cve: ./data/2024/4xxx/CVE-2024-4369.json
|
||
An information disclosure flaw was found in OpenShift's internal image registry operator. The AZURE_CLIENT_SECRET can be exposed through an environment variable defined in the pod definition, but is limited to Azure environments. An attacker controlling an account that has high enough permissions to obtain pod information from the openshift-image-registry namespace could use this obtained client secret to perform actions as the registry operator's Azure service account.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，这个 CVE 信息与 namespace 和容器相关。问题出现在 OpenShift 的内部镜像 registry operator 中，涉及 `openshift-image-registry` 命名空间中的 Pod 定义。Pod 是 Kubernetes/容器编排系统中的基本单元，因此该问题直接与容器环境相关。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
这个漏洞本身不会直接影响其他容器或宿主机的安全性。它主要是一个信息泄露问题，泄露的是 Azure 环境下的 `AZURE_CLIENT_SECRET`。然而，如果攻击者获取了该密钥，他们可以利用该密钥以 registry operator 的 Azure 服务账户身份执行操作，这可能会间接影响整个 Azure 环境中的资源，包括可能影响其他容器或宿主机。因此，虽然漏洞本身不直接导致容器逃逸或宿主机受攻击，但其后果可能被扩展到更广泛的范围。
|
||
|
||
**结论：**
|
||
- 满足条件 1 和 2 的部分分析要求。
|
||
- 不属于完全无关的情况，因此不返回 "N/A"。
|
||
|
||
cve: ./data/2024/50xxx/CVE-2024-50130.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
netfilter: bpf: must hold reference on net namespace
|
||
|
||
BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0
|
||
Read of size 8 at addr ffff8880106fe400 by task repro/72=
|
||
bpf_nf_link_release+0xda/0x1e0
|
||
bpf_link_free+0x139/0x2d0
|
||
bpf_link_release+0x68/0x80
|
||
__fput+0x414/0xb60
|
||
|
||
Eric says:
|
||
It seems that bpf was able to defer the __nf_unregister_net_hook()
|
||
after exit()/close() time.
|
||
Perhaps a netns reference is missing, because the netns has been
|
||
dismantled/freed already.
|
||
bpf_nf_link_attach() does :
|
||
link->net = net;
|
||
But I do not see a reference being taken on net.
|
||
|
||
Add such a reference and release it after hook unreg.
|
||
Note that I was unable to get syzbot reproducer to work, so I
|
||
do not know if this resolves this splat.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**
|
||
是的，此 CVE 信息与 namespace 相关。具体来说，问题涉及到 `net namespace` 的引用计数管理。在 Linux 内核中，`net namespace` 是网络隔离的重要组成部分，广泛用于容器技术（如 Docker）以实现网络资源的隔离。
|
||
|
||
2. **是否会导致容器运行时影响其他容器或宿主机**
|
||
是的，此漏洞可能会影响容器的隔离性。由于问题涉及 `net namespace` 的引用计数管理不当，可能导致在容器退出或关闭网络钩子时，错误地访问已释放的内存（use-after-free）。这种行为可能会破坏容器的隔离性，甚至允许攻击者利用该漏洞影响其他容器或宿主机的稳定性。
|
||
|
||
3. **结论**
|
||
根据上述分析，条件 1 和 2 均满足，因此返回以下分析结果：
|
||
- 与 `net namespace` 相关，涉及网络隔离。
|
||
- 可能影响容器的隔离性，导致容器运行时影响其他容器或宿主机。
|
||
|
||
cve: ./data/2024/50xxx/CVE-2024-50204.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
fs: don't try and remove empty rbtree node
|
||
|
||
When copying a namespace we won't have added the new copy into the
|
||
namespace rbtree until after the copy succeeded. Calling free_mnt_ns()
|
||
will try to remove the copy from the rbtree which is invalid. Simply
|
||
free the namespace skeleton directly.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 与 namespace 相关。描述中提到 "copying a namespace" 和 "namespace rbtree"，这表明问题发生在 Linux 内核对 namespace 的操作过程中。Namespace 是容器技术（如 Docker）实现隔离的核心机制之一。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
从描述来看，此漏洞可能会影响容器的正常运行。如果在复制 namespace 的过程中调用 `free_mnt_ns()`，可能会尝试移除一个尚未添加到红黑树（rbtree）中的节点，从而导致内存管理错误或崩溃。这种问题可能会影响容器的稳定性，但没有明确提到会直接突破容器隔离或影响宿主机的安全性。因此，虽然存在潜在风险，但目前信息不足以证明它会直接影响其他容器或宿主机。
|
||
|
||
**结论：**
|
||
- 条件 1 满足（与 namespace 相关）。
|
||
- 条件 2 不完全满足（无明确证据表明会影响其他容器或宿主机）。
|
||
|
||
cve: ./data/2024/52xxx/CVE-2024-52799.json
|
||
Argo Workflows Chart is used to set up argo and its needed dependencies through one command. Prior to 0.44.0, the workflow-role has excessive privileges, the worst being create pods/exec, which will allow kubectl exec into any Pod in the same namespace, i.e. arbitrary code execution within those Pods. If a user can be made to run a malicious template, their whole namespace can be compromised. This affects versions of the argo-workflows Chart that use appVersion: 3.4 and above, which no longer need these permissions for the only available Executor, Emissary. It could also affect users below 3.4 depending on their choice of Executor in those versions. This only affects the Helm Chart and not the upstream manifests. This vulnerability is fixed in 0.44.0.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 和容器相关。问题的核心在于 Argo Workflows 的 Helm Chart 中的 `workflow-role` 权限过高，允许恶意模板执行任意代码，并通过 `kubectl exec` 进入同一 namespace 下的任何 Pod。这直接影响了 Kubernetes 集群中的 namespace 隔离性。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，此漏洞可能导致容器间的隔离被破坏。攻击者可以通过恶意模板利用 excessive privileges 创建新的 Pods 或对现有 Pods 执行命令，从而影响同一 namespace 下的其他容器。虽然直接影响宿主机的可能性较低（除非进一步利用其他漏洞），但 namespace 内的资源完全暴露于风险中。
|
||
|
||
**结论：满足条件 1 和 2。**
|
||
|
||
cve: ./data/2024/53xxx/CVE-2024-53095.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
smb: client: Fix use-after-free of network namespace.
|
||
|
||
Recently, we got a customer report that CIFS triggers oops while
|
||
reconnecting to a server. [0]
|
||
|
||
The workload runs on Kubernetes, and some pods mount CIFS servers
|
||
in non-root network namespaces. The problem rarely happened, but
|
||
it was always while the pod was dying.
|
||
|
||
The root cause is wrong reference counting for network namespace.
|
||
|
||
CIFS uses kernel sockets, which do not hold refcnt of the netns that
|
||
the socket belongs to. That means CIFS must ensure the socket is
|
||
always freed before its netns; otherwise, use-after-free happens.
|
||
|
||
The repro steps are roughly:
|
||
|
||
1. mount CIFS in a non-root netns
|
||
2. drop packets from the netns
|
||
3. destroy the netns
|
||
4. unmount CIFS
|
||
|
||
We can reproduce the issue quickly with the script [1] below and see
|
||
the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.
|
||
|
||
When the socket is TCP, it is hard to guarantee the netns lifetime
|
||
without holding refcnt due to async timers.
|
||
|
||
Let's hold netns refcnt for each socket as done for SMC in commit
|
||
9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").
|
||
|
||
Note that we need to move put_net() from cifs_put_tcp_session() to
|
||
clean_demultiplex_info(); otherwise, __sock_create() still could touch a
|
||
freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().
|
||
|
||
Also, maybe_get_net() cannot be put just before __sock_create() because
|
||
the code is not under RCU and there is a small chance that the same
|
||
address happened to be reallocated to another netns.
|
||
|
||
[0]:
|
||
CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...
|
||
CIFS: Serverclose failed 4 times, giving up
|
||
Unable to handle kernel paging request at virtual address 14de99e461f84a07
|
||
Mem abort info:
|
||
ESR = 0x0000000096000004
|
||
EC = 0x25: DABT (current EL), IL = 32 bits
|
||
SET = 0, FnV = 0
|
||
EA = 0, S1PTW = 0
|
||
FSC = 0x04: level 0 translation fault
|
||
Data abort info:
|
||
ISV = 0, ISS = 0x00000004
|
||
CM = 0, WnR = 0
|
||
[14de99e461f84a07] address between user and kernel address ranges
|
||
Internal error: Oops: 0000000096000004 [#1] SMP
|
||
Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs
|
||
CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1
|
||
Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018
|
||
pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
pc : fib_rules_lookup+0x44/0x238
|
||
lr : __fib_lookup+0x64/0xbc
|
||
sp : ffff8000265db790
|
||
x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01
|
||
x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580
|
||
x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500
|
||
x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000
|
||
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
|
||
x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002
|
||
x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294
|
||
x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000
|
||
x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0
|
||
x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500
|
||
Call trace:
|
||
fib_rules_lookup+0x44/0x238
|
||
__fib_lookup+0x64/0xbc
|
||
ip_route_output_key_hash_rcu+0x2c4/0x398
|
||
ip_route_output_key_hash+0x60/0x8c
|
||
tcp_v4_connect+0x290/0x488
|
||
__inet_stream_connect+0x108/0x3d0
|
||
inet_stream_connect+0x50/0x78
|
||
kernel_connect+0x6c/0xac
|
||
generic_ip_conne
|
||
---truncated---
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器隔离相关**：
|
||
是的，该 CVE 信息与网络命名空间（network namespace）相关。具体来说，问题发生在 CIFS 使用内核套接字时未正确引用计数网络命名空间，导致在非根网络命名空间中挂载 CIFS 并销毁该命名空间后出现 use-after-free 漏洞。
|
||
|
||
2. **是否会影响其他容器或宿主机**：
|
||
可能会。由于该漏洞涉及网络命名空间的引用计数问题，如果一个容器使用了非根网络命名空间并挂载了 CIFS 共享，在特定条件下（例如容器销毁时），可能会导致内核崩溃或其他不稳定行为。这种不稳定性可能影响同一宿主机上的其他容器或宿主机本身，尤其是在共享内核的容器环境中（如 Docker）。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均满足，因此返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2024/55xxx/CVE-2024-55964.json
|
||
An issue was discovered in Appsmith before 1.52. An incorrectly configured PostgreSQL instance in the Appsmith image leads to remote command execution inside the Appsmith Docker container. The attacker must be able to access Appsmith, login to it, create a datasource, create a query against that datasource, and execute that query.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或容器隔离相关**：
|
||
该 CVE 描述中提到的是 Appsmith 的 PostgreSQL 实例配置错误，导致远程命令执行漏洞。问题的核心在于数据库配置不当，而非容器本身的 namespace、cgroup 或隔离机制的缺陷。因此，此 CVE 与容器隔离机制无直接关系。
|
||
|
||
2. **分析是否会影响其他容器或宿主机**：
|
||
根据描述，攻击者需要通过 Appsmith 的界面登录并执行特定操作（创建数据源和查询）才能触发漏洞。漏洞的影响范围被限制在 Appsmith 容器内部的 PostgreSQL 实例中。由于没有提到突破容器隔离的能力（如逃逸到宿主机或其他容器），因此可以认为此漏洞不会影响其他容器或宿主机。
|
||
|
||
3. **结论**：
|
||
条件 1 和 2 均不满足，返回 "N/A"。
|
||
|
||
**N/A**
|
||
|
||
cve: ./data/2024/56xxx/CVE-2024-56783.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level
|
||
|
||
cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to
|
||
restrict this maximum depth to a more reasonable value not to harm
|
||
performance. Remove unnecessary WARN_ON_ONCE which is reachable from
|
||
userspace.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或容器、隔离相关**
|
||
该 CVE 提到 `cgroup` 的最大深度问题，并且涉及 `nft_socket` 和 `WARN_ON_ONCE` 的移除。`cgroup` 是 Linux 容器（如 Docker）实现资源限制和隔离的重要组成部分，因此该漏洞与 `cgroup` 直接相关，间接与容器的资源管理有关。
|
||
|
||
2. **分析是否会导致容器在运行时影响其他容器或宿主机**
|
||
虽然该漏洞涉及 `cgroup` 的最大深度配置，但其核心是移除一个从用户空间可触达的 `WARN_ON_ONCE`，这并不会直接导致容器突破隔离机制去影响其他容器或宿主机。不过，如果攻击者能够利用 `cgroup` 配置不当的问题（例如设置过深的层级），可能会间接影响系统性能或资源分配。但从描述来看，这种风险已被限制为性能影响，而非安全隔离破坏。
|
||
|
||
3. **结论**
|
||
条件 1 满足（与 `cgroup` 相关），条件 2 不满足（不会直接影响其他容器或宿主机的安全隔离）。因此，返回以下分析结果：
|
||
|
||
- 与 `cgroup` 相关，可能间接影响容器的资源管理。
|
||
- 不会导致容器突破隔离机制影响其他容器或宿主机。
|
||
|
||
cve: ./data/2024/57xxx/CVE-2024-57977.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
memcg: fix soft lockup in the OOM process
|
||
|
||
A soft lockup issue was found in the product with about 56,000 tasks were
|
||
in the OOM cgroup, it was traversing them when the soft lockup was
|
||
triggered.
|
||
|
||
watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]
|
||
CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G
|
||
Hardware name: Huawei Cloud OpenStack Nova, BIOS
|
||
RIP: 0010:console_unlock+0x343/0x540
|
||
RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13
|
||
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff
|
||
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247
|
||
RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040
|
||
R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0
|
||
R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
vprintk_emit+0x193/0x280
|
||
printk+0x52/0x6e
|
||
dump_task+0x114/0x130
|
||
mem_cgroup_scan_tasks+0x76/0x100
|
||
dump_header+0x1fe/0x210
|
||
oom_kill_process+0xd1/0x100
|
||
out_of_memory+0x125/0x570
|
||
mem_cgroup_out_of_memory+0xb5/0xd0
|
||
try_charge+0x720/0x770
|
||
mem_cgroup_try_charge+0x86/0x180
|
||
mem_cgroup_try_charge_delay+0x1c/0x40
|
||
do_anonymous_page+0xb5/0x390
|
||
handle_mm_fault+0xc4/0x1f0
|
||
|
||
This is because thousands of processes are in the OOM cgroup, it takes a
|
||
long time to traverse all of them. As a result, this lead to soft lockup
|
||
in the OOM process.
|
||
|
||
To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks'
|
||
function per 1000 iterations. For global OOM, call
|
||
'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，这个 CVE 信息与 cgroup（控制组）直接相关。问题出现在 OOM（Out-of-Memory）处理过程中，具体是在 `mem_cgroup_scan_tasks` 函数中对大量任务进行遍历时触发了软锁死（soft lockup）。cgroup 是 Linux 内核中的一个关键特性，用于限制和隔离资源使用，包括内存管理。因此，该问题明确涉及 cgroup。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，这个问题可能会导致容器运行时影响其他容器或宿主机。当大量的任务属于同一个 OOM cgroup 时，遍历这些任务可能导致 CPU 被长时间占用（软锁死），从而使系统无法及时响应其他任务。这种情况可能会影响同一宿主机上的其他容器或宿主机本身，尤其是当多个容器共享宿主机资源时。
|
||
|
||
3. **结论**：
|
||
根据上述分析，条件 1 和条件 2 均满足，因此返回以下分析结果：
|
||
- 与 cgroup 和容器隔离机制相关。
|
||
- 可能会导致容器运行时影响其他容器或宿主机。
|
||
|
||
cve: ./data/2024/58xxx/CVE-2024-58088.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
bpf: Fix deadlock when freeing cgroup storage
|
||
|
||
The following commit
|
||
bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]")
|
||
first introduced deadlock prevention for fentry/fexit programs attaching
|
||
on bpf_task_storage helpers. That commit also employed the logic in map
|
||
free path in its v6 version.
|
||
|
||
Later bpf_cgrp_storage was first introduced in
|
||
c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs")
|
||
which faces the same issue as bpf_task_storage, instead of its busy
|
||
counter, NULL was passed to bpf_local_storage_map_free() which opened
|
||
a window to cause deadlock:
|
||
|
||
<TASK>
|
||
(acquiring local_storage->lock)
|
||
_raw_spin_lock_irqsave+0x3d/0x50
|
||
bpf_local_storage_update+0xd1/0x460
|
||
bpf_cgrp_storage_get+0x109/0x130
|
||
bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170
|
||
? __bpf_prog_enter_recur+0x16/0x80
|
||
bpf_trampoline_6442485186+0x43/0xa4
|
||
cgroup_storage_ptr+0x9/0x20
|
||
(holding local_storage->lock)
|
||
bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160
|
||
bpf_selem_unlink_storage+0x6f/0x110
|
||
bpf_local_storage_map_free+0xa2/0x110
|
||
bpf_map_free_deferred+0x5b/0x90
|
||
process_one_work+0x17c/0x390
|
||
worker_thread+0x251/0x360
|
||
kthread+0xd2/0x100
|
||
ret_from_fork+0x34/0x50
|
||
ret_from_fork_asm+0x1a/0x30
|
||
</TASK>
|
||
|
||
Progs:
|
||
- A: SEC("fentry/cgroup_storage_ptr")
|
||
- cgid (BPF_MAP_TYPE_HASH)
|
||
Record the id of the cgroup the current task belonging
|
||
to in this hash map, using the address of the cgroup
|
||
as the map key.
|
||
- cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)
|
||
If current task is a kworker, lookup the above hash
|
||
map using function parameter @owner as the key to get
|
||
its corresponding cgroup id which is then used to get
|
||
a trusted pointer to the cgroup through
|
||
bpf_cgroup_from_id(). This trusted pointer can then
|
||
be passed to bpf_cgrp_storage_get() to finally trigger
|
||
the deadlock issue.
|
||
- B: SEC("tp_btf/sys_enter")
|
||
- cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)
|
||
The only purpose of this prog is to fill Prog A's
|
||
hash map by calling bpf_cgrp_storage_get() for as
|
||
many userspace tasks as possible.
|
||
|
||
Steps to reproduce:
|
||
- Run A;
|
||
- while (true) { Run B; Destroy B; }
|
||
|
||
Fix this issue by passing its busy counter to the free procedure so
|
||
it can be properly incremented before storage/smap locking.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**
|
||
是的，这个 CVE 信息明确提到了 `bpf_cgrp_storage` 和 `BPF_MAP_TYPE_CGRP_STORAGE`，这些都是与 cgroup（控制组）密切相关的功能。此外，BPF 程序被用于操作 cgroup 存储，这表明该漏洞与 cgroup 的管理和使用直接相关。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**
|
||
这个漏洞主要涉及 BPF 程序在处理 cgroup 存储时可能导致死锁的问题。虽然它与 cgroup 相关，但问题的核心是 BPF 程序在特定情况下触发死锁，而不是直接影响容器隔离性或逃逸。因此，从描述来看，这个漏洞不会直接导致容器影响其他容器或宿主机的安全性，而是可能影响系统的稳定性（例如导致某些任务或线程卡住）。
|
||
|
||
3. **结论**
|
||
根据上述分析，条件 1 满足（与 cgroup 相关），但条件 2 不满足（不会直接影响其他容器或宿主机）。因此，返回以下内容：
|
||
|
||
```
|
||
满足条件 1，不满足条件 2。
|
||
```
|
||
|
||
cve: ./data/2024/5xxx/CVE-2024-5652.json
|
||
In Docker Desktop on Windows before v4.31.0 allows a user in the docker-users group to cause a Windows Denial-of-Service through the exec-path Docker daemon config option in Windows containers mode.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息明确提到 Docker Desktop 和 Windows 容器模式。Docker 是一种容器化技术，因此该问题与容器和隔离机制相关。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
根据描述，攻击者可以通过 `exec-path` 配置选项导致 Windows 上的 Denial-of-Service (DoS)。这种行为会影响 Docker 守护进程，从而可能间接影响其他容器或宿主机的可用性。虽然没有明确说明可以直接控制宿主机或其他容器，但 DoS 攻击会降低整个系统的稳定性，因此可以认为它会对其他容器或宿主机产生间接影响。
|
||
|
||
**结论：满足条件 1 和 2。**
|
||
|
||
cve: ./data/2024/6xxx/CVE-2024-6222.json
|
||
In Docker Desktop before v4.29.0, an attacker who has gained access to the Docker Desktop VM through a container breakout can further escape to the host by passing extensions and dashboard related IPC messages.
|
||
|
||
Docker Desktop v4.29.0 https://docs.docker.com/desktop/release-notes/#4290 fixes the issue on MacOS, Linux and Windows with Hyper-V backend.
|
||
|
||
As exploitation requires "Allow only extensions distributed through the Docker Marketplace" to be disabled, Docker Desktop v4.31.0 https://docs.docker.com/desktop/release-notes/#4310 additionally changes the default configuration to enable this setting by default.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 与容器和隔离相关。它描述了 Docker Desktop 中的一个漏洞，攻击者可以通过容器逃逸访问 Docker Desktop 虚拟机，并进一步通过扩展和仪表板相关的 IPC 消息逃逸到宿主机。这直接影响了容器与宿主机之间的隔离。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞会导致容器运行时影响宿主机。攻击者在获得对 Docker Desktop 虚拟机的访问权限后，可以进一步突破到宿主机，从而可能危及整个系统安全。虽然没有明确提到影响其他容器，但一旦攻击者控制了宿主机，理论上可以间接影响同一宿主机上的其他容器。
|
||
|
||
---
|
||
|
||
**结论：满足条件 1 和 2。**
|
||
|
||
cve: ./data/2024/7xxx/CVE-2024-7387.json
|
||
A flaw was found in openshift/builder. This vulnerability allows command injection via path traversal, where a malicious user can execute arbitrary commands on the OpenShift node running the builder container. When using the “Docker” strategy, executable files inside the privileged build container can be overridden using the `spec.source.secrets.secret.destinationDir` attribute of the `BuildConfig` definition. An attacker running code in a privileged container could escalate their permissions on the node running the container.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE与容器和隔离相关。问题发生在OpenShift的builder容器中，涉及到通过路径遍历进行命令注入，以及在特权容器中覆盖可执行文件的能力。这直接影响了容器的隔离性，特别是当使用“Docker”策略时。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞可能导致运行时影响其他容器或宿主机。攻击者可以通过覆盖特权构建容器中的可执行文件，并利用`spec.source.secrets.secret.destinationDir`属性来执行任意命令，从而突破容器隔离，进一步可能危害到宿主机或其他共享同一节点的容器。
|
||
|
||
**结论：** 该CVE满足条件1和条件2。
|
||
|
||
cve: ./data/2024/7xxx/CVE-2024-7557.json
|
||
A vulnerability was found in OpenShift AI that allows for authentication bypass and privilege escalation across models within the same namespace. When deploying AI models, the UI provides the option to protect models with authentication. However, credentials from one model can be used to access other models and APIs within the same namespace. The exposed ServiceAccount tokens, visible in the UI, can be utilized with oc --token={token} to exploit the elevated view privileges associated with the ServiceAccount, leading to unauthorized access to additional resources.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器、隔离相关：**
|
||
是的，该漏洞与 namespace 相关。描述中明确提到“同一 namespace”内的模型和 API 可以被跨模型访问，这表明问题发生在同一个 namespace 内的资源隔离机制上。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
从描述来看，此漏洞主要涉及 OpenShift AI 的认证绕过和权限提升问题，集中在 ServiceAccount 和 UI 暴露的令牌上。虽然它允许攻击者访问同一 namespace 内的其他资源，但没有直接提到容器运行时或宿主机受到影响。因此，目前信息不足以证明它会直接影响其他容器或宿主机。
|
||
|
||
3. **结论：**
|
||
根据上述分析，条件 1 满足，条件 2 不满足，因此返回以下内容：
|
||
|
||
**分析结果：**
|
||
- 与 namespace 相关，涉及同一 namespace 内的资源隔离问题。
|
||
- 不会影响其他容器或宿主机。
|
||
|
||
cve: ./data/2024/7xxx/CVE-2024-7558.json
|
||
JUJU_CONTEXT_ID is a predictable authentication secret. On a Juju machine (non-Kubernetes) or Juju charm container (on Kubernetes), an unprivileged user in the same network namespace can connect to an abstract domain socket and guess the JUJU_CONTEXT_ID value. This gives the unprivileged user access to the same information and tools as the Juju charm.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE信息提到“Juju charm container (on Kubernetes)”以及“unprivileged user in the same network namespace”，明确涉及到了容器和网络命名空间（network namespace），这些都是容器隔离机制的重要组成部分。因此，它与容器和隔离相关。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||
根据描述，一个非特权用户可以通过猜测`JUJU_CONTEXT_ID`值，连接到抽象域套接字（abstract domain socket），从而获得与Juju charm相同的权限和工具访问。这表明，如果攻击者位于同一个网络命名空间内，他们可能利用此漏洞突破容器的隔离，访问或操控其他容器或宿主机上的资源。因此，这个漏洞确实可能导致容器运行时影响其他容器或宿主机。
|
||
|
||
### 结论：
|
||
- 条件1满足：与容器和隔离相关。
|
||
- 条件2满足：可能影响其他容器或宿主机。
|
||
|
||
cve: ./data/2024/7xxx/CVE-2024-7598.json
|
||
A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，此 CVE 信息与 namespace 和容器隔离相关。问题描述中提到，在 Kubernetes 中，当 namespace 被删除时，网络策略（Network Policies）可能在被保护的 Pod 之前被删除，导致网络限制在一段时间内无法生效。Namespace 是 Kubernetes 中用于隔离资源的核心概念之一，因此该问题直接影响到 namespace 的隔离性。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致恶意或受攻击的 Pod 在 namespace 删除期间绕过网络策略限制，从而访问其他 Pod 或宿主机上的资源。尽管这种影响是短暂的，但在此窗口期内，恶意 Pod 可能会利用未被强制执行的网络策略发起攻击或泄露数据。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/7xxx/CVE-2024-7771.json
|
||
A vulnerability in the Dockerized version of mintplex-labs/anything-llm (latest, digest 1d9452da2b92) allows for a denial of service. Uploading an audio file with a very low sample rate causes the functionality responsible for transcribing it to crash the entire site instance. The issue arises from the localWhisper implementation, where resampling the audio file from 1 Hz to 16000 Hz quickly exceeds available memory, leading to the Docker instance being killed by the instance manager.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 与容器相关。问题出现在 Docker 化版本的 mintplex-labs/anything-llm 应用中，且描述中提到由于内存耗尽导致 Docker 实例被实例管理器杀死，这表明问题发生在容器环境中，并且涉及到容器资源限制（如 cgroup 的内存限制）。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
在这种情况下，漏洞的影响仅限于单个容器实例（mintplex-labs/anything-llm）。虽然该容器可能会因为内存耗尽而被杀死，但没有证据表明此问题会直接影响其他容器或宿主机。如果容器的资源限制（如 cgroup）配置得当，这种资源耗尽的情况通常不会波及到宿主机或其他容器。
|
||
|
||
3. **结论**：
|
||
由于条件 1 满足，条件 2 不满足，因此返回以下分析结果：
|
||
- 与容器和隔离相关：是。
|
||
- 是否影响其他容器或宿主机：否。
|
||
|
||
cve: ./data/2024/8xxx/CVE-2024-8037.json
|
||
Vulnerable juju hook tool abstract UNIX domain socket. When combined with an attack of JUJU_CONTEXT_ID, any user on the local system with access to the default network namespace may connect to the @/var/lib/juju/agents/unit-xxxx-yyyy/agent.socket and perform actions that are normally reserved to a juju charm.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
该 CVE 提及了 "default network namespace"，这表明问题涉及 Linux 命名空间（namespace），特别是网络命名空间。此外，Juju 是一个用于部署和管理应用程序的工具，通常在容器化环境中使用，因此可以间接关联到容器和隔离机制。
|
||
|
||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
根据描述，任何拥有默认网络命名空间访问权限的用户都可以连接到特定的 UNIX 域套接字，并执行通常仅限于 Juju charm 的操作。如果此漏洞存在于容器化环境中，攻击者可能利用它从一个容器突破到宿主机或其他共享同一网络命名空间的容器。因此，该漏洞可能会对容器隔离产生影响，导致跨容器或容器对宿主机的潜在威胁。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/8xxx/CVE-2024-8038.json
|
||
Vulnerable juju introspection abstract UNIX domain socket. An abstract UNIX domain socket responsible for introspection is available without authentication locally to network namespace users. This enables denial of service attacks.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
该 CVE 提及了一个“abstract UNIX domain socket”用于 introspection（内省），并且明确提到它在“network namespace users”中可用。这表明问题与网络命名空间（network namespace）有关，而网络命名空间是 Linux 容器（如 Docker）实现隔离的重要组成部分之一。因此，这个问题与命名空间和隔离机制相关。
|
||
|
||
2. **分析是否会影响其他容器或宿主机：**
|
||
由于该漏洞允许“network namespace users”在没有身份验证的情况下访问抽象 UNIX 域套接字，攻击者可能利用此漏洞对目标系统进行拒绝服务（DoS）攻击。如果多个容器共享同一个网络命名空间（例如，在某些非默认配置下），那么一个容器中的恶意用户可能通过此漏洞影响其他容器或宿主机的稳定性。因此，这种漏洞有可能导致容器运行时影响其他容器或宿主机。
|
||
|
||
**结论：**
|
||
条件 1 和 2 都满足。
|
||
|
||
cve: ./data/2024/8xxx/CVE-2024-8060.json
|
||
OpenWebUI version 0.3.0 contains a vulnerability in the audio API endpoint `/audio/api/v1/transcriptions` that allows for arbitrary file upload. The application performs insufficient validation on the `file.content_type` and allows user-controlled filenames, leading to a path traversal vulnerability. This can be exploited by an authenticated user to overwrite critical files within the Docker container, potentially leading to remote code execution as the root user.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞与容器相关。描述中明确提到漏洞影响的是一个运行在 Docker 容器中的应用，并且攻击者可以通过该漏洞覆盖容器内的关键文件。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**：
|
||
从描述来看，攻击者可以利用该漏洞在容器内执行任意代码（作为 root 用户）。如果容器没有正确配置隔离机制（例如共享宿主机的文件系统或其他资源），可能会进一步影响宿主机或其他容器。因此，该漏洞有可能间接影响宿主机或其他容器的安全性。
|
||
|
||
结论：满足条件 1 和 2。
|
||
|
||
cve: ./data/2024/8xxx/CVE-2024-8695.json
|
||
A remote code execution (RCE) vulnerability via crafted extension description/changelog could be abused by a malicious extension in Docker Desktop before 4.34.2.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞涉及 Docker Desktop，而 Docker Desktop 是一个用于运行容器的平台。因此，它与容器技术及其隔离机制相关。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**：
|
||
该漏洞描述提到的是通过恶意扩展（crafted extension）触发远程代码执行 (RCE)。如果攻击者利用此漏洞成功执行代码，可能会突破容器的隔离机制，从而影响其他容器或宿主机的安全性。因此，答案是可能的。
|
||
|
||
**结论**：满足条件1和条件2。
|
||
|
||
cve: ./data/2024/8xxx/CVE-2024-8696.json
|
||
A remote code execution (RCE) vulnerability via crafted extension publisher-url/additional-urls could be abused by a malicious extension in Docker Desktop before 4.34.2.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞与容器相关。描述中明确提到“Docker Desktop”，这是一个用于运行容器的平台，因此与容器技术直接相关。
|
||
|
||
2. **分析是否会导致容器在运行时影响其他容器或宿主机**：
|
||
该漏洞允许通过恶意扩展实现远程代码执行 (RCE)，而此行为可能会影响 Docker Desktop 所管理的容器环境，甚至可能波及宿主机。如果攻击者利用此漏洞成功执行恶意代码，可能会突破容器的隔离机制，进而影响其他容器或宿主机的安全性。
|
||
|
||
3. **结论**：
|
||
条件 1 和 2 均满足，因此返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2024/9xxx/CVE-2024-9407.json
|
||
A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞与容器和隔离机制直接相关。漏洞存在于 Dockerfile 的 `RUN --mount` 指令中的 `bind-propagation` 选项，涉及容器构建过程中主机目录被挂载到容器内的行为。这直接影响了容器与宿主机之间的隔离性。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器在构建过程中访问并修改宿主机上的敏感目录和文件。通过利用此漏洞，攻击者可以绕过 SELinux 等安全机制，对宿主机文件系统进行未授权的访问和修改。这种行为可能进一步影响其他容器的运行环境，甚至导致宿主机被完全控制。
|
||
|
||
结论：该 CVE 满足条件 1 和条件 2。
|
||
|
||
cve: ./data/2024/9xxx/CVE-2024-9676.json
|
||
A vulnerability was found in Podman, Buildah, and CRI-O. A symlink traversal vulnerability in the containers/storage library can cause Podman, Buildah, and CRI-O to hang and result in a denial of service via OOM kill when running a malicious image using an automatically assigned user namespace (`--userns=auto` in Podman and Buildah). The containers/storage library will read /etc/passwd inside the container, but does not properly validate if that file is a symlink, which can be used to cause the library to read an arbitrary file on the host.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 信息与 namespace 和容器相关。具体来说，问题出现在容器的存储库 `containers/storage` 中，涉及用户命名空间 (`user namespace`) 的使用 (`--userns=auto`)。此外，漏洞利用了符号链接（symlink）遍历的问题，可能影响宿主机文件系统的隔离性。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器运行时影响宿主机。由于 `containers/storage` 库没有正确验证 `/etc/passwd` 是否为符号链接，攻击者可以通过恶意容器镜像读取宿主机上的任意文件，从而破坏隔离性。虽然这主要是一个拒绝服务 (DoS) 漏洞（通过 OOM kill），但潜在的文件系统访问风险也可能导致进一步的安全问题。
|
||
|
||
因此，根据以上分析，条件 1 和 2 均满足。
|