844 lines
92 KiB
Plaintext
844 lines
92 KiB
Plaintext
cve: ./data/2023/0xxx/CVE-2023-0627.json
|
||
Docker Desktop 4.11.x allows --no-windows-containers flag bypass via IPC response spoofing which may lead to Local Privilege Escalation (LPE).This issue affects Docker Desktop: 4.11.X.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 与容器技术相关。具体来说，它涉及 Docker Desktop 的 Windows 容器功能，并通过 IPC（进程间通信）响应伪造绕过 `--no-windows-containers` 标志。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致本地权限提升 (LPE)，从而允许攻击者通过 IPC 响应伪造绕过限制，进而影响宿主机的安全性。这种情况下，攻击者可能利用该漏洞突破容器隔离，对宿主机或其他容器造成潜在威胁。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2023/0xxx/CVE-2023-0628.json
|
||
Docker Desktop before 4.17.0 allows an attacker to execute an arbitrary command inside a Dev Environments container during initialization by tricking a user to open a crafted malicious docker-desktop:// URL.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE明确提到了Docker Desktop和Dev Environments容器，这表明它与容器技术相关。此外，问题涉及在容器初始化期间执行任意命令，这也与容器的隔离性有关。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机：**
|
||
有可能。通过利用此漏洞，攻击者可以在Dev Environments容器中执行任意命令。如果该容器没有正确配置隔离机制（例如共享了宿主机的命名空间或资源），则可能会进一步影响其他容器或宿主机的安全性。
|
||
|
||
**结论：** 满足条件1和条件2，需要关注此漏洞对容器隔离性和宿主机安全的影响。
|
||
|
||
cve: ./data/2023/0xxx/CVE-2023-0629.json
|
||
Docker Desktop before 4.17.0 allows an unprivileged user to bypass Enhanced Container Isolation (ECI) restrictions by setting the Docker host to docker.raw.sock, or npipe:////.pipe/docker_engine_linux on Windows, via the -H (--host) CLI flag or the DOCKER_HOST environment variable and launch containers without the additional hardening features provided by ECI. This would not affect already running containers, nor containers launched through the usual approach (without Docker's raw socket).
|
||
|
||
The affected functionality is available for Docker Business customers only and assumes an environment where users are not granted local root or Administrator privileges.
|
||
This issue has been fixed in Docker Desktop 4.17.0.
|
||
|
||
Affected Docker Desktop versions: from 4.13.0 before 4.17.0.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，这个 CVE 与容器隔离相关。它描述了 Docker Desktop 的 Enhanced Container Isolation (ECI) 功能存在漏洞，允许未授权用户通过特定方式绕过 ECI 提供的额外隔离和加固功能。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，此漏洞可能会导致容器隔离失效。攻击者可以通过设置 `docker.raw.sock` 或类似方法绕过 ECI 的限制，从而可能以较低的安全性启动容器。这可能间接影响其他容器或宿主机的安全性，因为缺少 ECI 提供的加固措施可能导致更高的风险暴露。
|
||
|
||
**结论：满足条件 1 和 2。**
|
||
|
||
cve: ./data/2023/0xxx/CVE-2023-0923.json
|
||
A flaw was found in the Kubernetes service for notebooks in RHODS, where it does not prevent pods from other namespaces and applications from making requests to the Jupyter API. This flaw can lead to file content exposure and other issues.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，这个 CVE 信息与 namespace 和容器隔离相关。问题在于 Kubernetes 服务未能正确限制其他命名空间中的 Pods 对 Jupyter API 的访问，这表明跨命名空间的隔离存在漏洞。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
这个漏洞可能会导致一个命名空间中的容器通过未受限制的 API 请求访问另一个命名空间中容器的数据（如文件内容）。因此，虽然它不会直接影响宿主机，但它确实可能导致一个容器或 Pod 泄露敏感信息给其他容器或 Pod。
|
||
|
||
**结论：满足条件 1 和 2。**
|
||
|
||
cve: ./data/2023/1xxx/CVE-2023-1174.json
|
||
This vulnerability exposes a network port in minikube running on macOS with Docker driver that could enable unexpected remote access to the minikube container.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞与容器和隔离相关。描述中提到的是 minikube 在 macOS 上使用 Docker 驱动时暴露出一个网络端口，这直接影响到 minikube 容器的网络隔离性。
|
||
|
||
2. **分析是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，可能会产生影响。由于网络端口被意外暴露，攻击者可能通过此端口访问 minikube 容器，并进一步利用该容器作为跳板，尝试访问同一宿主机上的其他容器或直接攻击宿主机。这种行为破坏了容器之间的隔离性，也可能对宿主机的安全性构成威胁。
|
||
|
||
因此，条件 1 和 2 均满足。
|
||
|
||
cve: ./data/2023/1xxx/CVE-2023-1555.json
|
||
An issue has been discovered in GitLab affecting all versions starting from 15.2 before 16.1.5, all versions starting from 16.2 before 16.2.5, all versions starting from 16.3 before 16.3.1. A namespace-level banned user can access the API.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
该 CVE 描述提到“namespace-level banned user can access the API”，表明问题与 namespace 相关。然而，这里的 namespace 更像是 GitLab 内部的逻辑概念（例如项目或组的命名空间），而不是操作系统级别的 namespace（如 Linux namespace 用于容器隔离）。因此，严格来说，这并不直接涉及操作系统级别的 namespace、cgroup、container 或容器隔离机制。
|
||
|
||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
根据描述，这个问题是关于 GitLab 的一个权限管理漏洞，允许被禁用的用户在某个命名空间级别访问 API。这主要是应用层面上的安全问题，与容器运行时的隔离性无关，也不会直接影响其他容器或宿主机。
|
||
|
||
3. **结论：**
|
||
条件 1 和条件 2 均不满足，因此返回：
|
||
**N/A**
|
||
|
||
cve: ./data/2023/1xxx/CVE-2023-1636.json
|
||
A vulnerability was found in OpenStack Barbican containers. This vulnerability is only applicable to deployments that utilize an all-in-one configuration. Barbican containers share the same CGROUP, USER, and NET namespace with the host system and other OpenStack services. If any service is compromised, it could gain access to the data transmitted to and from Barbican.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE信息明确提到Barbican容器与主机系统以及其他OpenStack服务共享相同的CGROUP、USER和NET namespace。这表明该问题与容器的隔离机制直接相关。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机：**
|
||
是的，由于Barbican容器与主机系统和其他OpenStack服务共享相同的CGROUP、USER和NET namespace，一旦某个服务被攻破，攻击者可能能够访问传输到和来自Barbican的数据。这种共享配置可能导致安全边界被突破，从而使攻击者能够影响其他容器或宿主机。
|
||
|
||
3. **结论：**
|
||
由于条件1和条件2均满足，因此返回上述分析内容。
|
||
|
||
cve: ./data/2023/20xxx/CVE-2023-20235.json
|
||
A vulnerability in the on-device application development workflow feature for the Cisco IOx application hosting infrastructure in Cisco IOS XE Software could allow an authenticated, remote attacker to access the underlying operating system as the root user.
|
||
|
||
This vulnerability exists because Docker containers with the privileged runtime option are not blocked when they are in application development mode. An attacker could exploit this vulnerability by using the Docker CLI to access an affected device. The application development workflow is meant to be used only on development systems and not in production systems.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE信息与容器和隔离相关。描述中提到Docker容器在启用`privileged`运行时选项时未被阻止，这直接影响了容器的隔离性。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器突破隔离，访问底层操作系统并获取root权限。具体来说，攻击者可以通过Docker CLI利用此漏洞，在应用开发模式下访问宿主机的操作系统，从而影响其他容器或宿主机的安全。
|
||
|
||
3. **结论**：
|
||
条件1和条件2均满足，因此返回上述分析结果。
|
||
|
||
cve: ./data/2023/22xxx/CVE-2023-22495.json
|
||
Izanami is a shared configuration service well-suited for micro-service architecture implementation. Attackers can bypass the authentication in this application when deployed using the official Docker image. Because a hard coded secret is used to sign the authentication token (JWT), an attacker could compromise another instance of Izanami. This issue has been patched in version 1.11.0.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该 CVE 信息提到 Izanami 应用程序在使用官方 Docker 镜像部署时存在安全问题。这表明它与容器化环境（如 Docker）相关。
|
||
|
||
2. **是否会导致容器运行时影响其他容器或宿主机**：
|
||
该漏洞本身是由于硬编码的秘密密钥（JWT 签名）导致的认证绕过问题。虽然它会影响同一个容器中的 Izanami 实例，但没有直接证据表明此漏洞会突破容器隔离机制，进而影响其他容器或宿主机。因此，它不会直接影响其他容器或宿主机的安全性。
|
||
|
||
**结论**：N/A
|
||
|
||
cve: ./data/2023/23xxx/CVE-2023-23468.json
|
||
IBM Robotic Process Automation for Cloud Pak 21.0.1 through 21.0.7.3 and 23.0.0 through 23.0.3 is vulnerable to insufficient security configuration which may allow creation of namespaces within a cluster. IBM X-Force ID: 244500.
|
||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE提到了“creation of namespaces within a cluster”，明确涉及到了namespace的概念，而namespace是容器隔离机制中的一个核心组成部分。因此，该漏洞与namespace以及容器隔离相关。
|
||
|
||
2. **分析是否会导致容器（如Docker等）在运行时影响其他容器或宿主机**：
|
||
该描述提到“insufficient security configuration which may allow creation of namespaces within a cluster”，即由于安全配置不足，可能允许在集群内创建新的namespace。如果攻击者能够利用此漏洞创建新的namespace，可能会绕过现有的隔离机制，从而对同一宿主机上的其他容器或宿主机本身造成潜在影响。因此，该漏洞有可能导致容器运行时影响其他容器或宿主机。
|
||
|
||
**结论**：该CVE满足条件1和条件2。
|
||
|
||
cve: ./data/2023/23xxx/CVE-2023-23586.json
|
||
Due to a vulnerability in the io_uring subsystem, it is possible to leak kernel memory information to the user process. timens_install calls current_is_single_threaded to determine if the current process is single-threaded, but this call does not consider io_uring's io_worker threads, thus it is possible to insert a time namespace's vvar page to process's memory space via a page fault. When this time namespace is destroyed, the vvar page is also freed, but not removed from the process' memory, and a next page allocated by the kernel will be still available from the user-space process and can leak memory contents via this (read-only) use-after-free vulnerability. We recommend upgrading past version 5.10.161 or commit 788d0824269bef539fe31a785b1517882eafed93 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/io_uring
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该漏洞与 namespace 相关。具体来说，它涉及到时间命名空间（time namespace）。时间命名空间是 Linux 内核中的一种隔离机制，用于为不同的进程提供独立的时间视图。此漏洞利用了时间命名空间的 vvar 页面在进程内存中的处理不当，导致内核内存泄漏。
|
||
|
||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞可能会影响容器的隔离性。由于时间命名空间是容器隔离机制的一部分，此漏洞可能导致容器内的进程访问到宿主机或其他容器的敏感内核数据。这会破坏容器之间的隔离，并可能进一步被利用来攻击宿主机或其他容器。
|
||
|
||
3. **结论：**
|
||
条件 1 和条件 2 均满足，因此返回上述分析结果。
|
||
|
||
cve: ./data/2023/25xxx/CVE-2023-25173.json
|
||
containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and 1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. Downstream applications that use the containerd client library may be affected as well.
|
||
|
||
This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd's client library should check that application for a separate advisory and instructions. As a workaround, ensure that the `"USER $USERNAME"` Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to `ENTRYPOINT ["su", "-", "user"]` to allow `su` to properly set up supplementary groups.
|
||
analysis: ### 分析结果：
|
||
|
||
1. **是否与 namespace、cgroup、container 或容器、隔离相关：**
|
||
是的，该 CVE 与容器相关。具体来说，问题出现在 `containerd` 中，这是一个开源的容器运行时工具。问题涉及容器内的补充组（supplementary groups）设置不正确，这可能会影响容器内的权限管理。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
从描述来看，该漏洞的影响范围仅限于受影响的容器内部。攻击者可以通过操纵补充组访问权限来绕过某些限制，但没有提到可以突破容器隔离机制，进而影响其他容器或宿主机。因此，该漏洞不会直接影响其他容器或宿主机。
|
||
|
||
---
|
||
|
||
### 最终结论：
|
||
满足条件 1，但不满足条件 2，因此返回以下分析：
|
||
|
||
- **与容器相关：是**
|
||
- **是否影响其他容器或宿主机：否**
|
||
|
||
cve: ./data/2023/25xxx/CVE-2023-25809.json
|
||
runc is a CLI tool for spawning and running containers according to the OCI specification. In affected versions it was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) or 2. when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc spec --rootless`; this condition is very rare). A container may gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host . Other users's cgroup hierarchies are not affected. Users are advised to upgrade to version 1.1.5. Users unable to upgrade may unshare the cgroup namespace (`(docker|podman|nerdctl) run --cgroupns=private)`. This is the default behavior of Docker/Podman/nerdctl on cgroup v2 hosts. or add `/sys/fs/cgroup` to `maskedPaths`.
|
||
analysis: ### 分析结果：
|
||
|
||
1. **是否与 namespace、cgroup、container 或者容器、隔离相关**
|
||
是的，该 CVE 信息明确提到了 `runc` 工具在处理容器时的问题，特别是与 cgroup 和用户命名空间（user namespace）相关的配置。问题的核心在于 rootless runc 在特定条件下使得 `/sys/fs/cgroup` 可写，这直接影响了 cgroup 的隔离性。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**
|
||
是的，此漏洞可能导致容器获得对宿主机上用户拥有的 cgroup 层次结构（`/sys/fs/cgroup/user.slice/...`）的写访问权限。虽然其他用户的 cgroup 层次结构不受影响，但攻击者可能利用这一权限逃逸容器隔离环境，进而影响宿主机或其他依赖相同 cgroup 配置的容器。
|
||
|
||
3. **结论**
|
||
条件 1 和条件 2 均满足，因此返回以下分析内容：
|
||
|
||
---
|
||
|
||
### 漏洞分析总结：
|
||
- **受影响组件**：`runc`（符合 OCI 规范的容器运行时工具）。
|
||
- **问题描述**：在特定条件下，rootless runc 会使宿主机上的 `/sys/fs/cgroup` 可写，从而破坏 cgroup 的隔离性。
|
||
- **影响范围**：
|
||
- 容器可能获得对宿主机上用户拥有的 cgroup 层次结构的写访问权限。
|
||
- 这种访问权限可能会被滥用以突破容器隔离，影响宿主机或其他容器。
|
||
- **修复建议**：
|
||
- 升级到 `runc` 版本 1.1.5。
|
||
- 如果无法升级，可以通过以下方式缓解：
|
||
- 使用 `--cgroupns=private` 参数以单独隔离 cgroup 命名空间。
|
||
- 将 `/sys/fs/cgroup` 添加到 `maskedPaths` 中以屏蔽其访问。
|
||
|
||
此漏洞直接涉及容器隔离机制，需及时修复以避免潜在的安全风险。
|
||
|
||
cve: ./data/2023/26xxx/CVE-2023-26490.json
|
||
mailcow is a dockerized email package, with multiple containers linked in one bridged network. The Sync Job feature - which can be made available to standard users by assigning them the necessary permission - suffers from a shell command injection. A malicious user can abuse this vulnerability to obtain shell access to the Docker container running dovecot. The imapsync Perl script implements all the necessary functionality for this feature, including the XOAUTH2 authentication mechanism. This code path creates a shell command to call openssl. However, since different parts of the specified user password are included without any validation, one can simply execute additional shell commands. Notably, the default ACL for a newly-created mailcow account does not include the necessary permission. The Issue has been fixed within the 2023-03 Update (March 3rd 2023). As a temporary workaround the Syncjob ACL can be removed from all mailbox users, preventing from creating or changing existing Syncjobs.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器、隔离相关：**
|
||
是的，该 CVE 与容器相关。具体来说，mailcow 是一个基于 Docker 的电子邮件解决方案，涉及多个容器通过桥接网络连接在一起。漏洞影响的是运行 dovecot 的 Docker 容器。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
从描述来看，此漏洞允许恶意用户通过 Sync Job 特性执行命令注入，从而获得对运行 dovecot 的容器的 shell 访问权限。然而，攻击范围被限制在该特定容器内，因为没有提到突破容器隔离机制（例如逃逸到宿主机或其他容器）。因此，此漏洞不会直接影响其他容器或宿主机，除非攻击者进一步利用其他漏洞实现容器逃逸。
|
||
|
||
**结论：**
|
||
- 满足条件 1（与容器相关）。
|
||
- 不满足条件 2（不会直接影响其他容器或宿主机）。
|
||
|
||
cve: ./data/2023/27xxx/CVE-2023-27290.json
|
||
Docker based datastores for IBM Instana (IBM Observability with Instana 239-0 through 239-2, 241-0 through 241-2, and 243-0) do not currently require authentication. Due to this, an attacker within the network could access the datastores with read/write access. IBM X-Force ID: 248737.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE信息与容器相关。问题描述中明确提到“Docker based datastores”，表明该漏洞涉及基于Docker的容器化数据存储。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||
该漏洞描述指出，IBM Instana的数据存储未启用身份验证，导致攻击者可以在网络内获得对这些数据存储的读写访问权限。虽然此问题主要影响数据存储的安全性，但它并不直接涉及容器间的隔离机制或对宿主机的直接影响。然而，如果攻击者利用此漏洞修改或破坏共享数据存储的内容，可能会间接影响依赖该数据存储的其他容器或服务。
|
||
|
||
综上所述，该CVE与容器相关，并可能通过数据存储的滥用对其他容器产生间接影响，但不直接破坏容器隔离或直接影响宿主机。
|
||
|
||
cve: ./data/2023/27xxx/CVE-2023-27595.json
|
||
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. In version 1.13.0, when Cilium is started, there is a short period when Cilium eBPF programs are not attached to the host. During this period, the host does not implement any of Cilium's featureset. This can cause disruption to newly established connections during this period due to the lack of Load Balancing, or can cause Network Policy bypass due to the lack of Network Policy enforcement during the window. This vulnerability impacts any Cilium-managed endpoints on the node (such as Kubernetes Pods), as well as the host network namespace (including Host Firewall). This vulnerability is fixed in Cilium 1.13.1 or later. Cilium releases 1.12.x, 1.11.x, and earlier are not affected. There are no known workarounds.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，此 CVE 与容器和隔离相关。Cilium 是一个用于容器网络和安全的解决方案，其主要功能是通过 eBPF 程序实现对容器（如 Kubernetes Pods）和主机网络命名空间的管理。漏洞描述中提到，在 Cilium 启动时，eBPF 程序未正确附加到主机，导致在此期间缺少网络策略强制执行和负载均衡功能。这直接影响了 Cilium 管理的端点（例如 Kubernetes Pods）以及主机网络命名空间。
|
||
|
||
2. **分析是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，此漏洞可能导致容器之间的隔离性被破坏。由于在 Cilium 启动期间缺乏网络策略强制执行，可能会导致网络策略绕过（Network Policy bypass），从而使某些容器能够访问本应被禁止的资源或网络。此外，主机网络命名空间也会受到影响，可能增加宿主机被攻击的风险。
|
||
|
||
因此，条件 1 和 2 都满足。
|
||
|
||
cve: ./data/2023/28xxx/CVE-2023-28840.json
|
||
Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby, is commonly referred to as *Docker*.
|
||
|
||
Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
|
||
|
||
The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
|
||
|
||
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
|
||
|
||
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
|
||
|
||
Two iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.
|
||
|
||
The injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.
|
||
|
||
Patches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
|
||
|
||
Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.
|
||
analysis: ### 分析结果：
|
||
|
||
1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，此 CVE 与容器和隔离相关。具体来说，它涉及 Docker 的 Swarm Mode 和 overlay 网络驱动，这是用于在容器集群中提供网络隔离的核心功能之一。问题出在 iptables 规则配置上，这些规则旨在确保加密的 overlay 网络流量不会被未加密的流量干扰，从而影响网络隔离。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，该漏洞可能导致未加密的 VXLAN 数据包绕过预期的安全检查，进入加密的 overlay 网络。这可能会导致以下后果：
|
||
- 攻击者可以通过注入任意以太网帧来发起拒绝服务 (DoS) 攻击。
|
||
- 高级攻击者可能利用此漏洞建立本应被防火墙阻止的 UDP 或 TCP 连接。
|
||
- 这种行为可能破坏容器之间的网络隔离，甚至可能影响宿主机的安全性。
|
||
|
||
### 结论：
|
||
满足条件 1 和 2，因此返回分析内容。
|
||
|
||
cve: ./data/2023/28xxx/CVE-2023-28841.json
|
||
Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.
|
||
|
||
Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
|
||
|
||
The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
|
||
|
||
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
|
||
|
||
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
|
||
|
||
An iptables rule designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation.
|
||
|
||
Encrypted overlay networks on affected platforms silently transmit unencrypted data. As a result, `overlay` networks may appear to be functional, passing traffic as expected, but without any of the expected confidentiality or data integrity guarantees.
|
||
|
||
It is possible for an attacker sitting in a trusted position on the network to read all of the application traffic that is moving across the overlay network, resulting in unexpected secrets or user data disclosure. Thus, because many database protocols, internal APIs, etc. are not protected by a second layer of encryption, a user may use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed.
|
||
|
||
Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
|
||
|
||
Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器、隔离相关**：
|
||
是的，该 CVE 信息与容器和隔离相关。具体来说，它涉及 Docker 和 Moby 的 Swarm Mode 功能，以及 `overlay` 网络驱动程序。`overlay` 网络驱动程序通过 VXLAN 提供容器和服务之间的跨集群通信，并且支持加密模式以增强隔离性和安全性。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器在网络层面的安全性受到威胁。由于加密的 `overlay` 网络未能正确实施 IPsec 封装，攻击者可能在网络中嗅探到未加密的数据流，从而导致敏感信息泄露。这种漏洞可能影响整个 Swarm 集群中的容器通信安全，但不会直接影响宿主机的操作系统或资源隔离。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均满足，因此返回分析结果。
|
||
|
||
cve: ./data/2023/28xxx/CVE-2023-28842.json
|
||
Moby) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.
|
||
|
||
Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
|
||
|
||
The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
|
||
|
||
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
|
||
|
||
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
|
||
|
||
The `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.
|
||
|
||
Encrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration.
|
||
|
||
Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
|
||
|
||
Some workarounds are available. In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec.
|
||
analysis: ### 分析结果：
|
||
|
||
1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
- 是。该 CVE 涉及 Moby（Docker 的核心组件）中的 `overlay` 网络驱动，这是一个用于容器间通信的核心功能。`overlay` 网络通过 VXLAN 提供跨节点的容器网络隔离。此外，加密的 overlay 网络依赖于 iptables 规则和 IPsec 来确保数据的机密性和完整性，这直接影响容器之间的网络隔离。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
- 是。由于加密的 overlay 网络会错误地接受未加密的 VXLAN 数据包，攻击者可以通过注入任意以太网帧来破坏网络隔离。这种漏洞可能允许攻击者从一个容器中发送恶意流量到另一个容器或宿主机，从而突破容器间的隔离，甚至可能对宿主机或其他容器造成进一步的危害。
|
||
|
||
### 结论：
|
||
该 CVE 信息满足条件 1 和条件 2，因此分析表明它与容器隔离相关，并可能导致容器运行时影响其他容器或宿主机。
|
||
|
||
cve: ./data/2023/28xxx/CVE-2023-28960.json
|
||
An Incorrect Permission Assignment for Critical Resource vulnerability in Juniper Networks Junos OS Evolved allows a local, authenticated low-privileged attacker to copy potentially malicious files into an existing Docker container on the local system. A follow-on administrator could then inadvertently start the Docker container leading to the malicious files being executed as root. This issue only affects systems with Docker configured and enabled, which is not enabled by default. Systems without Docker started are not vulnerable to this issue. This issue affects Juniper Networks Junos OS Evolved: 20.4 versions prior to 20.4R3-S5-EVO; 21.2 versions prior to 21.2R3-EVO; 21.3 versions prior to 21.3R3-EVO; 21.4 versions prior to 21.4R2-EVO. This issue does not affect Juniper Networks Junos OS Evolved versions prior to 19.2R1-EVO.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE信息明确提到与Docker容器相关。攻击者可以通过权限分配错误将恶意文件复制到现有的Docker容器中，这表明问题与容器的文件系统和资源隔离机制有关。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器内的恶意文件被执行，并且以root权限运行。如果容器共享了宿主机的某些资源（例如通过不恰当的配置），这种行为可能会进一步影响宿主机或其他容器的安全性。此外，攻击需要本地低权限用户发起，说明容器环境可能存在权限管理或隔离上的缺陷。
|
||
|
||
因此，根据分析，该CVE满足条件1和条件2。
|
||
|
||
cve: ./data/2023/29xxx/CVE-2023-29002.json
|
||
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. When run in debug mode, Cilium will log the contents of the `cilium-secrets` namespace. This could include data such as TLS private keys for Ingress and GatewayAPI resources. An attacker with access to debug output from the Cilium containers could use the resulting output to intercept and modify traffic to and from the affected cluster. Output of the sensitive information would occur at Cilium agent restart, when secrets in the namespace are modified, and on creation of Ingress or GatewayAPI resources. This vulnerability is fixed in Cilium releases 1.11.16, 1.12.9, and 1.13.2. Users unable to upgrade should disable debug mode.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 相关。具体来说，Cilium 在调试模式下会记录 `cilium-secrets` 命名空间的内容，这可能包含敏感数据（例如 TLS 私钥）。命名空间是 Linux 容器隔离机制的一部分，因此这里涉及到了 namespace 的概念。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
这个漏洞本身不会直接导致容器影响其他容器或宿主机。然而，如果攻击者能够访问调试输出（例如通过获取 Cilium 容器的日志），他们可以利用泄露的敏感信息（如 TLS 私钥）来拦截和修改流量，从而对整个集群的安全性造成威胁。这种威胁主要体现在数据泄露和潜在的流量操控上，而不是直接破坏容器隔离或宿主机安全。
|
||
|
||
3. **结论：**
|
||
条件 1 满足（与 namespace 相关），条件 2 不完全满足（不会直接影响其他容器或宿主机，但可能导致间接威胁）。因此，返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2023/30xxx/CVE-2023-30549.json
|
||
Apptainer is an open source container platform for Linux. There is an ext4 use-after-free flaw that is exploitable through versions of Apptainer < 1.1.0 and installations that include apptainer-suid < 1.1.8 on older operating systems where that CVE has not been patched. That includes Red Hat Enterprise Linux 7, Debian 10 buster (unless the linux-5.10 package is installed), Ubuntu 18.04 bionic and Ubuntu 20.04 focal. Use-after-free flaws in the kernel can be used to attack the kernel for denial of service and potentially for privilege escalation.
|
||
|
||
Apptainer 1.1.8 includes a patch that by default disables mounting of extfs filesystem types in setuid-root mode, while continuing to allow mounting of extfs filesystems in non-setuid "rootless" mode using fuse2fs.
|
||
|
||
Some workarounds are possible. Either do not install apptainer-suid (for versions 1.1.0 through 1.1.7) or set `allow setuid = no` in apptainer.conf. This requires having unprivileged user namespaces enabled and except for apptainer 1.1.x versions will disallow mounting of sif files, extfs files, and squashfs files in addition to other, less significant impacts. (Encrypted sif files are also not supported unprivileged in apptainer 1.1.x.). Alternatively, use the `limit containers` options in apptainer.conf/singularity.conf to limit sif files to trusted users, groups, and/or paths, and set `allow container extfs = no` to disallow mounting of extfs overlay files. The latter option by itself does not disallow mounting of extfs overlay partitions inside SIF files, so that's why the former options are also needed.
|
||
analysis: ### 分析结果：
|
||
|
||
1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 与容器技术相关。Apptainer（前身为 Singularity）是一个开源的容器平台，用于在 Linux 系统上运行容器化应用程序。此漏洞涉及 Apptainer 的文件系统挂载功能，特别是在使用 setuid-root 模式时挂载 extfs 文件系统时可能存在 use-after-free 漏洞。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，此漏洞可能会影响宿主机的安全性。具体来说，use-after-free 漏洞可以被利用来攻击内核，导致拒绝服务（DoS）或潜在的权限提升（privilege escalation）。由于 Apptainer 的设计允许容器直接与宿主机内核交互（特别是在 setuid-root 模式下），这种漏洞可能会波及宿主机或其他容器。
|
||
|
||
3. **结论：**
|
||
条件 1 和条件 2 均满足，因此返回分析结果而非 "N/A"。
|
||
|
||
cve: ./data/2023/30xxx/CVE-2023-30840.json
|
||
Fluid is an open source Kubernetes-native distributed dataset orchestrator and accelerator for data-intensive applications. Starting in version 0.7.0 and prior to version 0.8.6, if a malicious user gains control of a Kubernetes node running fluid csi pod (controlled by the `csi-nodeplugin-fluid` node-daemonset), they can leverage the fluid-csi service account to modify specs of all the nodes in the cluster. However, since this service account lacks `list node` permissions, the attacker may need to use other techniques to identify vulnerable nodes.
|
||
|
||
Once the attacker identifies and modifies the node specs, they can manipulate system-level-privileged components to access all secrets in the cluster or execute pods on other nodes. This allows them to elevate privileges beyond the compromised node and potentially gain full privileged access to the whole cluster.
|
||
|
||
To exploit this vulnerability, the attacker can make all other nodes unschedulable (for example, patch node with taints) and wait for system-critical components with high privilege to appear on the compromised node. However, this attack requires two prerequisites: a compromised node and identifying all vulnerable nodes through other means.
|
||
|
||
Version 0.8.6 contains a patch for this issue. As a workaround, delete the `csi-nodeplugin-fluid` daemonset in `fluid-system` namespace and avoid using CSI mode to mount FUSE file systems. Alternatively, using sidecar mode to mount FUSE file systems is recommended.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞与容器和Kubernetes集群中的隔离性相关。具体来说，Fluid 是一个 Kubernetes 原生的分布式数据集编排和加速工具，涉及 CSI（Container Storage Interface）插件的使用。漏洞描述中提到，攻击者可以通过控制 `csi-nodeplugin-fluid` 的 DaemonSet，利用 Fluid 的 CSI 服务账户权限来修改节点规格，从而影响整个集群的资源调度和安全性。这表明该问题与容器运行时环境及 Kubernetes 集群的隔离机制密切相关。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致攻击者突破单个节点的限制，影响其他节点上的容器或宿主机的安全性。通过修改节点规格，攻击者可以操控系统级特权组件，访问集群中的所有机密信息，甚至在其他节点上执行恶意 Pod。这表明该漏洞可能破坏容器之间的隔离性，并对整个集群构成威胁。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均满足，因此需要返回分析结果。
|
||
|
||
cve: ./data/2023/30xxx/CVE-2023-30997.json
|
||
IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could allow a local user to obtain root access due to improper access controls. IBM X-Force ID: 254638.
|
||
analysis: 1. 该 CVE 信息与 namespace、cgroup、container 或容器隔离机制无直接关系。描述中提到的是 IBM Security Access Manager Docker 版本中存在的问题，但问题是由于不恰当的访问控制导致本地用户可以获得 root 权限，而不是容器隔离机制本身的漏洞。
|
||
|
||
2. 该 CVE 可能会影响运行中的容器或宿主机安全。由于不恰当的访问控制，本地用户可以获取 root 权限，这可能允许攻击者在容器内提升权限，进而可能影响到宿主机或其他共享同一宿主机的容器。
|
||
|
||
因此，根据分析结果，这个 CVE 满足条件 1 和条件 2 的部分要求。
|
||
|
||
cve: ./data/2023/30xxx/CVE-2023-30998.json
|
||
IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could allow a local user to obtain root access due to improper access controls. IBM X-Force ID: 254649.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，此 CVE 提及了 IBM Security Access Manager 的 Docker 版本，明确涉及容器技术。问题源于“improper access controls”，这可能与容器的访问控制或权限隔离机制有关。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，根据描述，“a local user to obtain root access” 表明本地用户可以获取 root 权限。如果攻击者在一个容器内利用此漏洞获得 root 权限，可能会突破容器的隔离机制，进一步影响同一宿主机上的其他容器或直接危害宿主机本身。
|
||
|
||
3. **结论：**
|
||
由于条件 1 和 2 均满足，因此返回上述分析结果。
|
||
|
||
cve: ./data/2023/31xxx/CVE-2023-31004.json
|
||
IBM Security Access Manager Container (IBM Security Verify Access Appliance 10.0.0.0 through 10.0.6.1 and IBM Security Verify Access Docker 10.0.0.0 through 10.0.6.1) could allow a remote attacker to gain access to the underlying system using man in the middle techniques. IBM X-Force ID: 254765.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE明确提到了IBM Security Access Manager Container以及IBM Security Verify Access Docker，这表明它与容器技术相关。此外，描述中提到攻击者可以通过中间人（Man-in-the-Middle, MitM）技术访问底层系统，这可能涉及容器的隔离机制被绕过或破坏。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机**：
|
||
根据描述，攻击者能够通过MitM技术访问底层系统（即宿主机）。这意味着该漏洞可能会导致容器的隔离机制失效，从而使攻击者可以影响宿主机或其他在同一宿主机上运行的容器。
|
||
|
||
**结论**：满足条件1和条件2。
|
||
|
||
cve: ./data/2023/31xxx/CVE-2023-31005.json
|
||
IBM Security Access Manager Container (IBM Security Verify Access Appliance 10.0.0.0 through 10.0.6.1 and IBM Security Verify Access Docker 10.0.0.0 through 10.0.6.1) could allow a local user to escalate their privileges due to an improper security configuration. IBM X-Force ID: 254767.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE明确提到了IBM Security Access Manager Container以及IBM Security Verify Access Docker，这表明它与容器技术（如Docker）相关。此外，漏洞描述中提到的安全配置问题可能涉及容器的隔离机制。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机：**
|
||
根据描述，该漏洞允许本地用户通过不当的安全配置提升权限。如果攻击者成功利用此漏洞，可能会突破容器的隔离机制，进一步影响宿主机或其他在同一宿主机上运行的容器。因此，这种漏洞存在影响其他容器或宿主机的可能性。
|
||
|
||
**结论：** 该CVE信息满足条件1和条件2。
|
||
|
||
cve: ./data/2023/31xxx/CVE-2023-31006.json
|
||
IBM Security Access Manager Container (IBM Security Verify Access Appliance 10.0.0.0 through 10.0.6.1 and IBM Security Verify Access Docker 10.0.0.0 through 10.0.6.1) is vulnerable to a denial of service attacks on the DSC server. IBM X-Force ID: 254776.
|
||
analysis: 1. 该 CVE 描述了 IBM Security Access Manager Container 存在一个针对 DSC（Distributed Session Cache）服务器的拒绝服务漏洞。描述中提到的是容器化产品（IBM Security Verify Access Appliance 和 Docker 版本），但并未明确提及 namespace、cgroup、container 或者隔离机制本身的缺陷，而是专注于特定服务（DSC 服务器）的漏洞。
|
||
|
||
2. 根据描述，此漏洞可能导致对 DSC 服务器的拒绝服务攻击，影响的是容器内的 DSC 服务功能。没有证据表明该漏洞会影响其他容器或宿主机的安全性或稳定性。因此，它不会直接导致运行时影响其他容器或宿主机。
|
||
|
||
### 结论：
|
||
N/A
|
||
|
||
cve: ./data/2023/31xxx/CVE-2023-31248.json
|
||
Linux Kernel nftables Use-After-Free Local Privilege Escalation Vulnerability; `nft_chain_lookup_byid()` failed to check whether a chain was active and CAP_NET_ADMIN is in any user or network namespace
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞涉及 `CAP_NET_ADMIN` 权限在用户命名空间或网络命名空间中的使用。这表明它与 Linux 命名空间（namespace）有关，而命名空间是容器技术（如 Docker）实现隔离的重要组成部分。
|
||
|
||
2. **是否会导致容器影响其他容器或宿主机**：
|
||
有可能。由于漏洞允许本地权限提升，并且涉及 `CAP_NET_ADMIN` 权限在命名空间中的检查缺失，攻击者可能利用此漏洞从一个容器中逃脱，获取宿主机的更高权限，或者影响其他运行在同一宿主机上的容器。具体来说，如果攻击者能够在容器内利用此漏洞，则可能会绕过容器的隔离机制，进而对宿主机或其他容器造成威胁。
|
||
|
||
**结论**：满足条件1和条件2，因此需要返回上述分析内容。
|
||
|
||
cve: ./data/2023/32xxx/CVE-2023-32191.json
|
||
When RKE provisions a cluster, it stores the cluster state in a configmap called `full-cluster-state` inside the `kube-system` namespace of the cluster itself. The information available in there allows non-admin users to escalate to admin.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器隔离相关：**
|
||
是的，该 CVE 与 namespace 相关。描述中提到 `kube-system` namespace 中存储了一个名为 `full-cluster-state` 的 configmap，这明确涉及 Kubernetes 集群中的 namespace 概念。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
不会直接影响其他容器或宿主机。该漏洞的核心问题是权限提升，非管理员用户可以通过访问 `full-cluster-state` configmap 获得管理员权限。虽然这可能导致进一步的攻击（例如通过管理员权限操作其他容器或宿主机），但本身并不直接导致容器逃逸或对宿主机的直接影响。
|
||
|
||
3. **结论：**
|
||
条件 1 满足，条件 2 不满足，因此不返回 "N/A"。
|
||
|
||
**总结分析：**
|
||
该 CVE 涉及 Kubernetes 集群的配置管理问题，特别是 `kube-system` namespace 中敏感信息的暴露，可能导致权限提升。但不会直接导致容器逃逸或影响其他容器/宿主机的安全性。
|
||
|
||
cve: ./data/2023/32xxx/CVE-2023-32194.json
|
||
A vulnerability has been identified when granting a create or * global role for a resource type of "namespaces"; no matter the API group, the subject will receive *
|
||
permissions for core namespaces. This can lead to someone being capable
|
||
of accessing, creating, updating, or deleting a namespace in the
|
||
project.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该漏洞与namespace直接相关。描述中明确提到“namespaces”资源类型，并指出如果授予创建或全局角色权限，用户将获得对核心命名空间的广泛权限（`*`权限）。这直接影响到namespace的管理，而namespace是容器隔离机制的重要组成部分。
|
||
|
||
2. **是否会导致容器（如Docker等）在运行时影响其他容器或宿主机**：
|
||
有可能。由于该漏洞赋予了对namespace的广泛操作权限（包括创建、更新、删除），攻击者可能利用此权限来破坏容器隔离。例如，通过创建或删除特定namespace，攻击者可能干扰其他容器的正常运行，甚至可能逃逸到宿主机层面，从而影响整个容器环境的安全性。
|
||
|
||
**结论**：满足条件1和条件2，因此返回上述分析结果。
|
||
|
||
cve: ./data/2023/34xxx/CVE-2023-34242.json
|
||
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. Prior to version 1.13.4, when Gateway API is enabled in Cilium, the absence of a check on the namespace in which a ReferenceGrant is created could result in Cilium unintentionally gaining visibility of secrets (including certificates) and services across namespaces. An attacker on an affected cluster can leverage this issue to use cluster secrets that should not be visible to them, or communicate with services that they should not have access to. Gateway API functionality is disabled by default. This vulnerability is fixed in Cilium release 1.13.4. As a workaround, restrict the creation of `ReferenceGrant` resources to admin users by using Kubernetes RBAC.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 相关。问题的核心在于 Cilium 在处理 Gateway API 时，未对 ReferenceGrant 所在的 namespace 进行检查，从而导致跨 namespace 的秘密（如证书和服务）被无意中暴露。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
该漏洞可能会间接影响其他容器的安全性。由于 Cilium 是一个网络和安全解决方案，负责管理容器之间的网络通信和访问控制，因此如果攻击者利用此漏洞获取了不应访问的秘密或服务，他们可能能够绕过隔离机制，进而影响其他容器或宿主机的安全。
|
||
|
||
**结论：**
|
||
满足条件 1 和 2，因此返回上述分析内容。
|
||
|
||
cve: ./data/2023/34xxx/CVE-2023-34844.json
|
||
Play With Docker < 0.0.2 has an insecure CAP_SYS_ADMIN privileged mode causing the docker container to escape.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 与容器和隔离相关。描述中提到 Docker 容器的特权模式 (`CAP_SYS_ADMIN`) 存在安全问题，可能导致容器逃逸。容器逃逸通常涉及破坏容器与宿主机之间的隔离机制，因此直接关联到容器隔离技术（如 namespace 和 cgroup）。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
是的，该 CVE 可能导致容器逃逸，从而使攻击者能够影响宿主机或其他在相同宿主机上运行的容器。具体来说，`CAP_SYS_ADMIN` 特权模式的不安全实现可能允许攻击者突破容器的限制，访问宿主机资源或干扰其他容器的正常运行。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2023/35xxx/CVE-2023-35001.json
|
||
Linux Kernel nftables Out-Of-Bounds Read/Write Vulnerability; nft_byteorder poorly handled vm register contents when CAP_NET_ADMIN is in any user or network namespace
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 相关。描述中提到 "CAP_NET_ADMIN is in any user or network namespace"，说明问题涉及网络命名空间和用户命名空间，这些是 Linux 容器（如 Docker）实现隔离的重要组成部分。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
可能会。由于该漏洞涉及 `nftables` 的出界读写问题，并且与 `CAP_NET_ADMIN` 权限在命名空间中的处理有关，攻击者可能利用此漏洞突破容器的隔离，影响其他容器或宿主机的安全性。具体影响取决于容器配置以及是否赋予了相关权限。
|
||
|
||
**结论：满足条件 1 和 2，需注意此漏洞对容器环境的潜在威胁。**
|
||
|
||
cve: ./data/2023/37xxx/CVE-2023-37273.json
|
||
Auto-GPT is an experimental open-source application showcasing the capabilities of the GPT-4 language model. Running Auto-GPT version prior to 0.4.3 by cloning the git repo and executing `docker compose run auto-gpt` in the repo root uses a different docker-compose.yml file from the one suggested in the official docker set up instructions. The docker-compose.yml file located in the repo root mounts itself into the docker container without write protection. This means that if malicious custom python code is executed via the `execute_python_file` and `execute_python_code` commands, it can overwrite the docker-compose.yml file and abuse it to gain control of the host system the next time Auto-GPT is started. The issue has been patched in version 0.4.3.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，此 CVE 信息与容器和隔离相关。问题涉及 Docker 容器中 `docker-compose.yml` 文件被错误地挂载到容器内，并且没有启用写保护。这破坏了容器应有的隔离性，使得恶意代码可以在容器内修改宿主机上的文件。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，此漏洞可能导致容器内的恶意代码覆盖宿主机上的 `docker-compose.yml` 文件。当宿主机下次启动 Auto-GPT 时，攻击者可以通过篡改后的配置文件进一步控制宿主机系统，从而对其他容器或整个宿主机造成威胁。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均满足，因此需要返回上述分析内容。
|
||
|
||
cve: ./data/2023/37xxx/CVE-2023-37274.json
|
||
Auto-GPT is an experimental open-source application showcasing the capabilities of the GPT-4 language model. When Auto-GPT is executed directly on the host system via the provided run.sh or run.bat files, custom Python code execution is sandboxed using a temporary dedicated docker container which should not have access to any files outside of the Auto-GPT workspace directory.
|
||
Before v0.4.3, the `execute_python_code` command (introduced in v0.4.1) does not sanitize the `basename` arg before writing LLM-supplied code to a file with an LLM-supplied name. This allows for a path traversal attack that can overwrite any .py file outside the workspace directory by specifying a `basename` such as `../../../main.py`. This can further be abused to achieve arbitrary code execution on the host running Auto-GPT by e.g. overwriting autogpt/main.py which will be executed outside of the docker environment meant to sandbox custom python code execution the next time Auto-GPT is started. The issue has been patched in version 0.4.3. As a workaround, the risk introduced by this vulnerability can be remediated by running Auto-GPT in a virtual machine, or another environment in which damage to files or corruption of the program is not a critical problem.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 信息与容器和隔离相关。Auto-GPT 使用了一个临时的专用 Docker 容器来沙箱化自定义 Python 代码的执行，以确保其不会访问 Auto-GPT 工作区目录之外的任何文件。然而，由于 `execute_python_code` 命令未对 `basename` 参数进行适当的 sanitization（清理），导致路径遍历攻击可以绕过这种隔离机制，从而影响宿主机上的文件。
|
||
|
||
2. **分析是否会导致容器（如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器内的操作影响宿主机。通过路径遍历攻击，攻击者可以覆盖宿主机上的关键文件（例如 `autogpt/main.py`），并在宿主机上实现任意代码执行。这种行为破坏了容器的隔离性，使得容器内的漏洞能够直接影响宿主机，进而可能间接影响同一宿主机上的其他容器。
|
||
|
||
3. **结论**：
|
||
由于条件 1 和条件 2 都满足，因此返回上述分析内容。
|
||
|
||
cve: ./data/2023/39xxx/CVE-2023-39347.json
|
||
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. An attacker with the ability to update pod labels can cause Cilium to apply incorrect network policies. This issue arises due to the fact that on pod update, Cilium incorrectly uses user-provided pod labels to select the policies which apply to the workload in question. This can affect Cilium network policies that use the namespace, service account or cluster constructs to restrict traffic, Cilium clusterwide network policies that use Cilium namespace labels to select the Pod and Kubernetes network policies. Non-existent construct names can be provided, which bypass all network policies applicable to the construct. For example, providing a pod with a non-existent namespace as the value of the `io.kubernetes.pod.namespace` label results in none of the namespaced CiliumNetworkPolicies applying to the pod in question. This attack requires the attacker to have Kubernetes API Server access, as described in the Cilium Threat Model. This issue has been resolved in: Cilium versions 1.14.2, 1.13.7, and 1.12.14. Users are advised to upgrade. As a workaround an admission webhook can be used to prevent pod label updates to the `k8s:io.kubernetes.pod.namespace` and `io.cilium.k8s.policy.*` keys.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 和容器隔离相关。问题的核心在于 Cilium 在处理 pod 更新时，错误地使用了用户提供的 pod 标签（labels），这可能导致不正确的网络策略被应用到特定的工作负载上。特别是，当提供一个不存在的命名空间（namespace）标签时，所有与该命名空间相关的 Cilium 网络策略将不再生效。因此，这直接影响了基于命名空间的隔离机制。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
是的，此漏洞可能会影响容器之间的隔离性。通过利用该漏洞，攻击者可以绕过网络策略，导致本应隔离的容器之间能够进行未授权的通信。虽然该漏洞本身不会直接破坏宿主机的安全性，但它可能会间接削弱容器之间的隔离，从而为攻击者提供进一步渗透的机会。
|
||
|
||
**结论：** 该 CVE 满足条件 1 和条件 2，因此需要进行上述分析。
|
||
|
||
cve: ./data/2023/39xxx/CVE-2023-39523.json
|
||
ScanCode.io is a server to script and automate software composition analysis with ScanPipe pipelines. Prior to version 32.5.1, the software has a possible command injection vulnerability in the docker fetch process as it allows to append malicious commands in the `docker_reference` parameter.
|
||
|
||
In the function `scanpipe/pipes/fetch.py:fetch_docker_image` the parameter `docker_reference` is user controllable. The `docker_reference` variable is then passed to the vulnerable function `get_docker_image_platform`. However, the `get_docker_image_plaform` function constructs a shell command with the passed `docker_reference`. The `pipes.run_command` then executes the shell command without any prior sanitization, making the function vulnerable to command injections. A malicious user who is able to create or add inputs to a project can inject commands. Although the command injections are blind and the user will not receive direct feedback without logs, it is still possible to cause damage to the server/container. The vulnerability appears for example if a malicious user adds a semicolon after the input of `docker://;`, it would allow appending malicious commands.
|
||
|
||
Version 32.5.1 contains a patch for this issue. The `docker_reference` input should be sanitized to avoid command injections and, as a workaround, one may avoid creating commands with user controlled input directly.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，此漏洞与容器相关。漏洞出现在 `ScanCode.io` 的 `docker fetch` 过程中，涉及 `docker_reference` 参数的处理。该参数被传递到一个函数中，最终用于构造并执行 shell 命令，而这些命令可能在容器环境中运行。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**：
|
||
是的，此漏洞可能导致容器运行时影响宿主机或其他容器。由于命令注入漏洞的存在，攻击者可以通过恶意构造的 `docker_reference` 参数执行任意命令。如果容器以特权模式运行或共享宿主机的资源（如文件系统、网络等），攻击者可以利用此漏洞对宿主机或其他容器造成损害。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 均满足，因此返回分析结果。
|
||
|
||
cve: ./data/2023/3xxx/CVE-2023-3027.json
|
||
The grc-policy-propagator allows security escalation within the cluster. The propagator allows policies which contain some dynamically obtained values (instead of the policy apply a static manifest on a managed cluster) of taking advantage of cluster scoped access in a created policy. This feature does not restrict properly to lookup content from the namespace where the policy was created.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或容器、隔离相关：**
|
||
是的，该 CVE 信息提到 "namespace" 和 "cluster scoped access"，并且描述了策略在集群中的传播问题。这表明它涉及 Kubernetes 集群中的命名空间隔离机制，可能影响命名空间级别的隔离。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机：**
|
||
虽然该漏洞主要涉及策略传播和命名空间访问控制，但它可能导致安全权限提升（security escalation），从而允许攻击者利用集群范围的访问权限来破坏其他命名空间或整个集群的隔离性。这种情况下，可能间接影响到运行在受影响命名空间中的容器，甚至可能波及宿主机的安全性。
|
||
|
||
**结论：**
|
||
条件 1 和 2 均满足，因此返回分析结果如上。
|
||
|
||
cve: ./data/2023/3xxx/CVE-2023-3774.json
|
||
An unhandled error in Vault Enterprise's namespace creation may cause the Vault process to crash, potentially resulting in denial of service. Fixed in 1.14.1, 1.13.5, and 1.12.9.
|
||
analysis: 1. 该 CVE 提到 Vault Enterprise 的命名空间创建过程中存在未处理的错误，可能导致 Vault 进程崩溃，进而引发拒绝服务（DoS）。这与 namespace 的操作相关，但没有直接提到 cgroup、container 或容器隔离。
|
||
|
||
2. 该 CVE 并未提及此漏洞会影响其他容器或宿主机，描述中仅表明 Vault 进程可能会崩溃，导致拒绝服务。因此，没有证据表明此问题会对其他容器或宿主机产生影响。
|
||
|
||
### 结论：
|
||
- 满足条件 1（与 namespace 相关）。
|
||
- 不满足条件 2（不会影响其他容器或宿主机）。
|
||
|
||
分析完成。
|
||
|
||
cve: ./data/2023/3xxx/CVE-2023-3775.json
|
||
A Vault Enterprise Sentinel Role Governing Policy created by an operator to restrict access to resources in one namespace can be applied to requests outside in another non-descendant namespace, potentially resulting in denial of service. Fixed in Vault Enterprise 1.15.0, 1.14.4, 1.13.8.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
该 CVE 提到的是 Vault Enterprise 中的 Sentinel Role Governing Policy 的问题，具体涉及namespace 的访问控制策略。问题描述中明确提到“one namespace” 和 “another non-descendant namespace”，表明它与 namespace 相关。但没有提到 cgroup、container 或容器隔离相关内容。
|
||
|
||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
该漏洞的影响范围仅限于 Vault Enterprise 的 namespace 访问控制策略，可能导致拒绝服务（DoS）。它并未涉及容器运行时的行为，也没有提到会影响其他容器或宿主机的安全性。
|
||
|
||
**结论**：
|
||
条件 1 满足（与 namespace 相关），条件 2 不满足（不会影响其他容器或宿主机）。
|
||
|
||
cve: ./data/2023/40xxx/CVE-2023-40453.json
|
||
Docker Machine through 0.16.2 allows an attacker, who has control of a worker node, to provide crafted version data, which might potentially trick an administrator into performing an unsafe action (via escape sequence injection), or might have a data size that causes a denial of service to a bastion node. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
|
||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
该 CVE 描述中提到 Docker Machine 的版本数据处理问题，可能通过逃逸序列注入或数据大小导致拒绝服务。这与容器的运行时行为有关，但并未直接涉及 namespace、cgroup 或隔离机制的具体实现。
|
||
|
||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
根据描述，攻击者可以通过控制 worker 节点提供恶意版本数据，从而可能影响 bastion 节点。这种影响可能间接导致管理员执行不安全操作，或者通过大尺寸数据引发拒绝服务。虽然没有明确提到容器逃逸，但 bastion 节点可能与宿主机或其他容器共享资源，因此存在潜在影响宿主机或间接影响其他容器的风险。
|
||
|
||
3. **结论**：
|
||
条件 1 和条件 2 部分满足，因此返回以下分析：
|
||
- 与容器相关，但未直接涉及 namespace 或 cgroup。
|
||
- 存在通过恶意输入影响宿主机或其他容器的潜在风险。
|
||
|
||
cve: ./data/2023/41xxx/CVE-2023-41333.json
|
||
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. An attacker with the ability to create or modify CiliumNetworkPolicy objects in a particular namespace is able to affect traffic on an entire Cilium cluster, potentially bypassing policy enforcement in other namespaces. By using a crafted `endpointSelector` that uses the `DoesNotExist` operator on the `reserved:init` label, the attacker can create policies that bypass namespace restrictions and affect the entire Cilium cluster. This includes potentially allowing or denying all traffic. This attack requires API server access, as described in the Kubernetes API Server Attacker section of the Cilium Threat Model. This issue has been resolved in Cilium versions 1.14.2, 1.13.7, and 1.12.14. As a workaround an admission webhook can be used to prevent the use of `endpointSelectors` that use the `DoesNotExist` operator on the `reserved:init` label in CiliumNetworkPolicies.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，这个 CVE 信息与 namespace 和容器隔离相关。问题的核心在于攻击者可以通过修改 CiliumNetworkPolicy 对象，利用特定的 `endpointSelector` 规则（如 `DoesNotExist` 操作符作用于 `reserved:init` 标签），绕过 namespace 的限制，从而影响整个 Cilium 集群的网络策略执行。这表明该漏洞破坏了 namespace 级别的隔离性。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
这个 CVE 主要影响的是 Cilium 网络策略的执行，而不是直接对容器或宿主机的安全性造成威胁。然而，由于攻击者可以绕过 namespace 的限制并影响整个集群的流量规则，可能会间接导致某些容器之间的通信被错误地允许或拒绝。虽然这不是直接的容器逃逸漏洞，但它确实可能削弱容器间的网络隔离，进而对容器环境的整体安全性产生负面影响。
|
||
|
||
因此，根据以上分析，结论如下：
|
||
- 该 CVE 与 namespace 和容器隔离相关。
|
||
- 它不会直接导致容器逃逸，但会削弱容器间的网络隔离，可能间接影响其他容器或宿主机的安全性。
|
||
|
||
**最终答案：满足条件 1 和 2 的部分要求，非 N/A。**
|
||
|
||
cve: ./data/2023/42xxx/CVE-2023-42125.json
|
||
Avast Premium Security Sandbox Protection Link Following Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Avast Premium Security. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
|
||
|
||
The specific flaw exists within the implementation of the sandbox feature. By creating a symbolic link, an attacker can abuse the service to create arbitrary namespace objects. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM.
|
||
. Was ZDI-CAN-20383.
|
||
analysis: 1. 该 CVE 信息与 namespace 相关，因为描述中提到攻击者可以通过创建符号链接滥用服务来创建任意的 namespace 对象。
|
||
2. 该 CVE 不直接影响容器（如 Docker）或其隔离机制。虽然提到了 namespace，但此漏洞是特定于 Avast Premium Security 的沙箱功能实现问题，而不是容器运行时或 cgroup、container 隔离相关的通用问题。因此，它不会导致容器影响其他容器或宿主机。
|
||
3. 综上所述，条件 1 满足（与 namespace 相关），但条件 2 不满足（不影响容器或其他容器/宿主机的隔离）。
|
||
|
||
**分析结果：**
|
||
- 与 namespace 相关。
|
||
- 不会影响容器或宿主机的隔离。
|
||
|
||
cve: ./data/2023/48xxx/CVE-2023-48225.json
|
||
Laf is a cloud development platform. Prior to version 1.0.0-beta.13, the control of LAF app enV is not strict enough, and in certain scenarios of privatization environment, it may lead to sensitive information leakage in secret and configmap. In ES6 syntax, if an obj directly references another obj, the name of the obj itself will be used as the key, and the entire object structure will be integrated intact. When constructing the deployment instance of the app, env was found from the database and directly inserted into the template, resulting in controllability here. Sensitive information in the secret and configmap can be read through the k8s envFrom field. In a privatization environment, when `namespaceConf. fixed` is marked, it may lead to the leakage of sensitive information in the system. As of time of publication, it is unclear whether any patches or workarounds exist.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 和容器相关。描述中提到在 Kubernetes 环境下，通过 `envFrom` 字段可能导致敏感信息泄漏，而 `namespaceConf.fixed` 的配置也表明了问题涉及 Kubernetes 的命名空间（namespace）管理。Kubernetes 是一个容器编排平台，因此该问题间接与容器和隔离机制相关。
|
||
|
||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
是的，可能存在影响。由于问题涉及 Kubernetes 的环境变量注入（`envFrom`），如果敏感信息（如 secrets 和 configmaps）被泄漏，攻击者可能利用这些信息访问其他容器或宿主机资源，特别是在共享同一命名空间的场景下。虽然该漏洞本身并不直接破坏容器隔离，但泄漏的敏感信息可能会被滥用，从而间接影响其他容器或宿主机的安全。
|
||
|
||
**结论：**
|
||
满足条件 1 和 2，分析完毕。
|
||
|
||
cve: ./data/2023/48xxx/CVE-2023-48311.json
|
||
dockerspawner is a tool to spawn JupyterHub single user servers in Docker containers. Users of JupyterHub deployments running DockerSpawner starting with 0.11.0 without specifying `DockerSpawner.allowed_images` configuration allow users to launch _any_ pullable docker image, instead of restricting to only the single configured image, as intended. This issue has been addressed in commit `3ba4b665b` which has been included in dockerspawner release version 13. Users are advised to upgrade. Users unable to upgrade should explicitly set `DockerSpawner.allowed_images` to a non-empty list containing only the default image will result in the intended default behavior.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||
是的，该 CVE 信息与容器相关。`dockerspawner` 是一个用于在 Docker 容器中启动 JupyterHub 单用户服务器的工具，涉及容器的配置和使用。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||
该漏洞允许用户启动任意可拉取的 Docker 镜像，而不是限制为单个配置的镜像。这可能会导致以下风险：
|
||
- 用户可以启动具有更高权限或恶意行为的容器。
|
||
- 恶意容器可能尝试逃逸或利用其他漏洞来影响宿主机或其他容器。
|
||
- 如果没有适当的隔离配置（如 namespace 或 cgroup），这种行为可能会对宿主机的安全性造成威胁。
|
||
|
||
因此，该漏洞可能会影响其他容器或宿主机的安全性。
|
||
|
||
**结论**：满足条件 1 和 2。
|
||
|
||
cve: ./data/2023/49xxx/CVE-2023-49103.json
|
||
An issue was discovered in ownCloud owncloud/graphapi 0.2.x before 0.2.1 and 0.3.x before 0.3.1. The graphapi app relies on a third-party GetPhpInfo.php library that provides a URL. When this URL is accessed, it reveals the configuration details of the PHP environment (phpinfo). This information includes all the environment variables of the webserver. In containerized deployments, these environment variables may include sensitive data such as the ownCloud admin password, mail server credentials, and license key. Simply disabling the graphapi app does not eliminate the vulnerability. Additionally, phpinfo exposes various other potentially sensitive configuration details that could be exploited by an attacker to gather information about the system. Therefore, even if ownCloud is not running in a containerized environment, this vulnerability should still be a cause for concern. Note that Docker containers from before February 2023 are not vulnerable to the credential disclosure.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 提到在容器化部署中，环境变量可能包含敏感信息（例如 ownCloud 管理员密码、邮件服务器凭据和许可证密钥）。这表明它与容器化环境相关，尤其是涉及容器内部的环境变量暴露问题。
|
||
|
||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机：**
|
||
从描述来看，此漏洞主要导致敏感信息泄露，而不是直接破坏容器隔离性或影响其他容器或宿主机。然而，泄露的敏感信息（如管理员密码、邮件服务器凭据等）可能会被攻击者利用，间接对系统造成进一步威胁。虽然 Docker 容器在 2023 年 2 月之前的版本不受凭据泄露影响，但信息泄露本身仍然是一个严重问题。
|
||
|
||
**结论：**
|
||
- 该 CVE 与容器化环境相关，尤其是涉及容器内的环境变量暴露。
|
||
- 虽然不会直接破坏容器隔离性或直接影响其他容器或宿主机，但泄露的信息可能被用于进一步攻击。
|
||
|
||
cve: ./data/2023/50xxx/CVE-2023-50253.json
|
||
Laf is a cloud development platform. In the Laf version design, the log uses communication with k8s to quickly retrieve logs from the container without the need for additional storage. However, in version 1.0.0-beta.13 and prior, this interface does not verify the permissions of the pod, which allows authenticated users to obtain any pod logs under the same namespace through this method, thereby obtaining sensitive information printed in the logs. As of time of publication, no known patched versions exist.
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||
是的，该 CVE 信息与 namespace 和容器相关。问题描述中提到通过未验证权限的接口可以获取同一 namespace 下的任何 pod 日志，这表明问题发生在 Kubernetes 的 namespace 范围内，并且涉及容器日志的访问。
|
||
|
||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||
不会直接影响其他容器或宿主机。虽然攻击者可以通过此漏洞获取同一 namespace 下其他 pod 的日志，但并未提到此漏洞允许直接访问其他容器的资源或宿主机系统。因此，影响主要集中在日志中的敏感信息泄露，而不是对容器或宿主机的进一步控制。
|
||
|
||
**结论：**
|
||
- 满足条件 1，与 namespace 和容器相关。
|
||
- 不满足条件 2，不会直接影响其他容器或宿主机。
|
||
|
||
cve: ./data/2023/52xxx/CVE-2023-52707.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
sched/psi: Fix use-after-free in ep_remove_wait_queue()
|
||
|
||
If a non-root cgroup gets removed when there is a thread that registered
|
||
trigger and is polling on a pressure file within the cgroup, the polling
|
||
waitqueue gets freed in the following path:
|
||
|
||
do_rmdir
|
||
cgroup_rmdir
|
||
kernfs_drain_open_files
|
||
cgroup_file_release
|
||
cgroup_pressure_release
|
||
psi_trigger_destroy
|
||
|
||
However, the polling thread still has a reference to the pressure file and
|
||
will access the freed waitqueue when the file is closed or upon exit:
|
||
|
||
fput
|
||
ep_eventpoll_release
|
||
ep_free
|
||
ep_remove_wait_queue
|
||
remove_wait_queue
|
||
|
||
This results in use-after-free as pasted below.
|
||
|
||
The fundamental problem here is that cgroup_file_release() (and
|
||
consequently waitqueue's lifetime) is not tied to the file's real lifetime.
|
||
Using wake_up_pollfree() here might be less than ideal, but it is in line
|
||
with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")
|
||
since the waitqueue's lifetime is not tied to file's one and can be
|
||
considered as another special case. While this would be fixable by somehow
|
||
making cgroup_file_release() be tied to the fput(), it would require
|
||
sizable refactoring at cgroups or higher layer which might be more
|
||
justifiable if we identify more cases like this.
|
||
|
||
BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0
|
||
Write of size 4 at addr ffff88810e625328 by task a.out/4404
|
||
|
||
CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
|
||
Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
|
||
Call Trace:
|
||
<TASK>
|
||
dump_stack_lvl+0x73/0xa0
|
||
print_report+0x16c/0x4e0
|
||
kasan_report+0xc3/0xf0
|
||
kasan_check_range+0x2d2/0x310
|
||
_raw_spin_lock_irqsave+0x60/0xc0
|
||
remove_wait_queue+0x1a/0xa0
|
||
ep_free+0x12c/0x170
|
||
ep_eventpoll_release+0x26/0x30
|
||
__fput+0x202/0x400
|
||
task_work_run+0x11d/0x170
|
||
do_exit+0x495/0x1130
|
||
do_group_exit+0x100/0x100
|
||
get_signal+0xd67/0xde0
|
||
arch_do_signal_or_restart+0x2a/0x2b0
|
||
exit_to_user_mode_prepare+0x94/0x100
|
||
syscall_exit_to_user_mode+0x20/0x40
|
||
do_syscall_64+0x52/0x90
|
||
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
||
</TASK>
|
||
|
||
Allocated by task 4404:
|
||
|
||
kasan_set_track+0x3d/0x60
|
||
__kasan_kmalloc+0x85/0x90
|
||
psi_trigger_create+0x113/0x3e0
|
||
pressure_write+0x146/0x2e0
|
||
cgroup_file_write+0x11c/0x250
|
||
kernfs_fop_write_iter+0x186/0x220
|
||
vfs_write+0x3d8/0x5c0
|
||
ksys_write+0x90/0x110
|
||
do_syscall_64+0x43/0x90
|
||
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
||
|
||
Freed by task 4407:
|
||
|
||
kasan_set_track+0x3d/0x60
|
||
kasan_save_free_info+0x27/0x40
|
||
____kasan_slab_free+0x11d/0x170
|
||
slab_free_freelist_hook+0x87/0x150
|
||
__kmem_cache_free+0xcb/0x180
|
||
psi_trigger_destroy+0x2e8/0x310
|
||
cgroup_file_release+0x4f/0xb0
|
||
kernfs_drain_open_files+0x165/0x1f0
|
||
kernfs_drain+0x162/0x1a0
|
||
__kernfs_remove+0x1fb/0x310
|
||
kernfs_remove_by_name_ns+0x95/0xe0
|
||
cgroup_addrm_files+0x67f/0x700
|
||
cgroup_destroy_locked+0x283/0x3c0
|
||
cgroup_rmdir+0x29/0x100
|
||
kernfs_iop_rmdir+0xd1/0x140
|
||
vfs_rmdir+0xfe/0x240
|
||
do_rmdir+0x13d/0x280
|
||
__x64_sys_rmdir+0x2c/0x30
|
||
do_syscall_64+0x43/0x90
|
||
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**
|
||
是的，这个 CVE 信息与 cgroup 直接相关。漏洞描述中提到的问题发生在 cgroup 的压力文件（pressure file）被移除时，涉及到 `cgroup_rmdir` 和 `cgroup_file_release` 等函数。Cgroup 是 Linux 内核中的一个关键机制，用于限制和隔离资源使用，也是容器技术（如 Docker）实现资源隔离的基础。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机**
|
||
是的，这个问题可能会导致容器运行时影响其他容器或宿主机。具体来说，如果一个非 root cgroup 被移除时，仍然有线程在该 cgroup 的压力文件上进行轮询操作，那么可能会触发 use-after-free 漏洞。这种问题可能会影响宿主机的稳定性，甚至可能导致内核崩溃或其他未定义行为。由于 cgroup 是容器隔离的核心组件之一，这种漏洞可能会破坏容器之间的隔离性，从而对整个容器环境造成潜在威胁。
|
||
|
||
3. **结论**
|
||
根据上述分析，条件 1 和条件 2 均满足，因此返回具体的分析内容。
|
||
|
||
cve: ./data/2023/52xxx/CVE-2023-52880.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
|
||
|
||
Any unprivileged user can attach N_GSM0710 ldisc, but it requires
|
||
CAP_NET_ADMIN to create a GSM network anyway.
|
||
|
||
Require initial namespace CAP_NET_ADMIN to do that.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该漏洞涉及 `CAP_NET_ADMIN` 权限和命名空间（namespace）的概念。具体来说，修复措施要求在初始命名空间中具备 `CAP_NET_ADMIN` 权限才能附加 `N_GSM0710` 行规解释器（ldisc）。这表明该问题与 Linux 命名空间的权限控制机制有关，而命名空间是容器技术（如 Docker）实现隔离的重要组成部分。
|
||
|
||
2. **是否会导致容器在运行时影响其他容器或宿主机：**
|
||
可能会。由于任何非特权用户都可以附加 `N_GSM0710` ldisc，而创建 GSM 网络通常需要 `CAP_NET_ADMIN` 权限，这可能导致权限提升的风险。如果攻击者在容器内利用此漏洞，可能会绕过容器的隔离机制，进而影响同一宿主机上的其他容器或直接危害宿主机的安全。
|
||
|
||
3. **结论：**
|
||
该 CVE 满足条件 1 和条件 2，因此需要进行详细分析并采取相应的安全措施以防止潜在的容器逃逸或权限提升问题。
|
||
|
||
cve: ./data/2023/52xxx/CVE-2023-52940.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
mm: multi-gen LRU: fix crash during cgroup migration
|
||
|
||
lru_gen_migrate_mm() assumes lru_gen_add_mm() runs prior to itself. This
|
||
isn't true for the following scenario:
|
||
|
||
CPU 1 CPU 2
|
||
|
||
clone()
|
||
cgroup_can_fork()
|
||
cgroup_procs_write()
|
||
cgroup_post_fork()
|
||
task_lock()
|
||
lru_gen_migrate_mm()
|
||
task_unlock()
|
||
task_lock()
|
||
lru_gen_add_mm()
|
||
task_unlock()
|
||
|
||
And when the above happens, kernel crashes because of linked list
|
||
corruption (mm_struct->lru_gen.list).
|
||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**
|
||
- 是的，该 CVE 信息明确提到 `cgroup` 和 `lru_gen_migrate_mm()` 函数。`cgroup`（控制组）是 Linux 内核中用于限制、控制和隔离进程组资源（如 CPU、内存、磁盘 I/O 等）的核心技术之一，也是容器（如 Docker）实现资源隔离的重要组成部分。因此，该漏洞与 `cgroup` 和容器隔离机制密切相关。
|
||
|
||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**
|
||
- 有可能。由于该漏洞涉及 `cgroup` 的迁移逻辑 (`cgroup_procs_write()`) 和内存管理 (`lru_gen_migrate_mm()`) 的交互，如果一个容器内的进程触发了此漏洞，可能会导致内核崩溃（kernel crash）。这种崩溃可能会影响整个宿主机系统，包括宿主机上的其他容器。因此，该漏洞可能被利用来破坏容器之间的隔离性，甚至影响宿主机的稳定性。
|
||
|
||
综上所述，该 CVE 满足条件 1 和条件 2。
|
||
|
||
cve: ./data/2023/52xxx/CVE-2023-52942.json
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask()
|
||
|
||
It was found that the check to see if a partition could use up all
|
||
the cpus from the parent cpuset in update_parent_subparts_cpumask()
|
||
was incorrect. As a result, it is possible to leave parent with no
|
||
effective cpu left even if there are tasks in the parent cpuset. This
|
||
can lead to system panic as reported in [1].
|
||
|
||
Fix this probem by updating the check to fail the enabling the partition
|
||
if parent's effective_cpus is a subset of the child's cpus_allowed.
|
||
|
||
Also record the error code when an error happens in update_prstate()
|
||
and add a test case where parent partition and child have the same cpu
|
||
list and parent has task. Enabling partition in the child will fail in
|
||
this case.
|
||
|
||
[1] https://www.spinics.net/lists/cgroups/msg36254.html
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||
是的，该CVE与cgroup（控制组）直接相关。具体来说，问题出现在`cpuset`子系统中的`update_parent_subparts_cpumask()`函数中，涉及对CPU资源分配的检查逻辑。
|
||
|
||
2. **是否会导致容器（如Docker等）在运行时影响其他容器或宿主机**：
|
||
是的，该漏洞可能导致容器运行时影响宿主机或其他容器的稳定性。由于`cpuset`子系统用于限制和分配CPU资源，错误的检查逻辑可能使得父`cpuset`（通常对应宿主机或其他共享资源的容器）被剥夺所有可用CPU资源，从而导致任务无法正常运行，甚至引发系统崩溃（如描述中提到的“system panic”）。
|
||
|
||
因此，该CVE满足条件1和条件2。
|
||
|
||
cve: ./data/2023/5xxx/CVE-2023-5056.json
|
||
A flaw was found in the Skupper operator, which may permit a certain configuration to create a service account that would allow an authenticated attacker in the adjacent cluster to view deployments in all namespaces in the cluster. This issue permits unauthorized viewing of information outside of the user's purview.
|
||
analysis: 1. 该 CVE 信息与 namespace 相关，因为它涉及到在集群中跨命名空间的信息访问问题。然而，它并未明确提到 cgroup、container 或容器隔离机制。
|
||
2. 根据描述，该漏洞不会直接影响容器的运行时行为，也不会导致一个容器影响其他容器或宿主机。它的影响主要体现在信息泄露方面，即允许攻击者查看本不应访问的部署信息。
|
||
|
||
因此，条件 1 部分满足（与 namespace 相关），但条件 2 不满足。
|
||
|
||
**结论：N/A**
|
||
|
||
cve: ./data/2023/5xxx/CVE-2023-5165.json
|
||
Docker Desktop before 4.23.0 allows an unprivileged user to bypass Enhanced Container Isolation (ECI) restrictions via the debug shell which remains accessible for a short time window after launching Docker Desktop. The affected functionality is available for Docker Business customers only and assumes an environment where users are not granted local root or Administrator privileges.
|
||
|
||
This issue has been fixed in Docker Desktop 4.23.0.
|
||
|
||
Affected Docker Desktop versions: from 4.13.0 before 4.23.0.
|
||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||
是的，该CVE与容器隔离相关。具体来说，它涉及Docker Desktop中的“Enhanced Container Isolation (ECI)”功能，该功能旨在增强容器的隔离性。问题在于调试shell在Docker Desktop启动后的一段时间内仍然可访问，这可能导致隔离机制被绕过。
|
||
|
||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机：**
|
||
是的，此漏洞可能会影响其他容器或宿主机。由于调试shell的短暂可访问性，未授权的用户可以利用这一窗口绕过隔离限制，从而可能对宿主机或其他容器造成潜在威胁。
|
||
|
||
**结论：满足条件1和2。**
|