Init commit.
This commit is contained in:
sleepwithoutbz
687
general_result/21.log
Normal file
687
general_result/21.log
Normal file
@@ -0,0 +1,687 @@
|
||||
cve: ./data/2021/1xxx/CVE-2021-1559.json
|
||||
Multiple vulnerabilities in Cisco DNA Spaces Connector could allow an authenticated, remote attacker to perform a command injection attack on an affected device. These vulnerabilities are due to insufficient input sanitization when executing affected commands. A high-privileged attacker could exploit these vulnerabilities on a Cisco DNA Spaces Connector by injecting crafted input during command execution. A successful exploit could allow the attacker to execute arbitrary commands as root within the Connector docker container.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
是的，该CVE明确提到攻击者可以在Cisco DNA Spaces Connector的Docker容器中执行任意命令。这涉及到容器技术以及其隔离机制。
|
||||
|
||||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||||
由于攻击者可以以root权限在受影响的Docker容器中执行任意命令，这种行为可能会突破容器的隔离机制。如果该容器没有正确配置（例如共享了宿主机的文件系统或其他资源），则可能导致攻击者进一步影响宿主机或其他容器。
|
||||
|
||||
**结论**：满足条件1和条件2。
|
||||
|
||||
cve: ./data/2021/1xxx/CVE-2021-1560.json
|
||||
Multiple vulnerabilities in Cisco DNA Spaces Connector could allow an authenticated, remote attacker to perform a command injection attack on an affected device. These vulnerabilities are due to insufficient input sanitization when executing affected commands. A high-privileged attacker could exploit these vulnerabilities on a Cisco DNA Spaces Connector by injecting crafted input during command execution. A successful exploit could allow the attacker to execute arbitrary commands as root within the Connector docker container.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||||
是的，该漏洞涉及容器（Docker）。具体来说，漏洞允许攻击者在 Cisco DNA Spaces Connector 的 Docker 容器中以 root 权限执行任意命令。
|
||||
|
||||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机：**
|
||||
从描述来看，攻击者可以执行任意命令，但这些命令的执行范围被限制在 "Connector docker container" 中。如果没有提到容器逃逸（container escape）或其他直接影响宿主机的行为，那么此漏洞的影响仅限于受影响的容器本身，不会直接影响其他容器或宿主机。不过，如果该容器具有对宿主机敏感资源的访问权限（例如挂载了宿主机的关键目录），则可能会间接影响宿主机。
|
||||
|
||||
**结论：**
|
||||
满足条件 1，部分满足条件 2（取决于容器配置）。
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20182.json
|
||||
A privilege escalation flaw was found in openshift4/ose-docker-builder. The build container runs with high privileges using a chrooted environment instead of runc. If an attacker can gain access to this build container, they can potentially utilize the raw devices of the underlying node, such as the network and storage devices, to at least escalate their privileges to that of the cluster admin. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
是的，该CVE与容器和隔离相关。描述中提到“build container”运行在高权限下，并且使用了“chrooted environment”而不是“runc”。这表明问题涉及容器的运行环境及其隔离机制。
|
||||
|
||||
2. **是否会导致容器（如Docker等）在运行时影响其他容器或宿主机**：
|
||||
是的，该漏洞可能导致影响宿主机或其他容器。攻击者如果获取了构建容器的访问权限，可以利用底层节点的原始设备（如网络和存储设备），从而可能突破容器隔离，影响宿主机或集群中的其他资源，并进一步提升权限至集群管理员级别。
|
||||
|
||||
3. **结论**：
|
||||
由于条件1和条件2均满足，因此返回上述分析结果。
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20194.json
|
||||
There is a vulnerability in the linux kernel versions higher than 5.2 (if kernel compiled with config params CONFIG_BPF_SYSCALL=y , CONFIG_BPF=y , CONFIG_CGROUPS=y , CONFIG_CGROUP_BPF=y , CONFIG_HARDENED_USERCOPY not set, and BPF hook to getsockopt is registered). As result of BPF execution, the local user can trigger bug in __cgroup_bpf_run_filter_getsockopt() function that can lead to heap overflow (because of non-hardened usercopy). The impact of attack could be deny of service or possibly privileges escalation.
|
||||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**
|
||||
该漏洞涉及 `CONFIG_CGROUPS=y` 和 `CONFIG_CGROUP_BPF=y`，这表明它与 cgroup 和 BPF（Berkeley Packet Filter）功能相关。cgroup 是 Linux 内核中用于限制和隔离资源使用的重要机制，也是容器技术（如 Docker）的核心组成部分之一。因此，该漏洞与 cgroup 和容器隔离机制相关。
|
||||
|
||||
2. **分析是否会导致容器运行时影响其他容器或宿主机**
|
||||
漏洞描述中提到，攻击者可以通过触发 `__cgroup_bpf_run_filter_getsockopt()` 函数中的堆溢出问题，可能导致拒绝服务（DoS）或权限提升（privilege escalation）。如果此漏洞被利用于容器环境中，恶意容器可能利用该漏洞突破隔离，影响宿主机或其他容器的安全性。尤其是当容器共享同一内核时，这种风险更加显著。
|
||||
|
||||
3. **结论**
|
||||
条件 1 和条件 2 均满足，因此返回以下分析结果：
|
||||
- 该 CVE 与 cgroup 和容器隔离机制相关。
|
||||
- 该漏洞可能导致容器运行时影响其他容器或宿主机的安全性。
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20511.json
|
||||
IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to traverse directories on the system. An attacker could send a specially-crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system. IBM X-Force ID: 198300.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
该CVE描述中提到的是IBM Security Verify Access Docker版本10.0.0中存在的目录遍历漏洞。虽然提到了Docker，但问题的核心是应用程序对URL输入的验证不足，导致目录遍历风险，而非Docker本身的namespace、cgroup或隔离机制的问题。因此，这个CVE与namespace、cgroup、container或容器隔离机制无直接关系。
|
||||
|
||||
2. **是否会导致容器在运行时影响其他容器或宿主机**：
|
||||
根据描述，攻击者可以通过构造特殊的URL请求来访问系统上的任意文件。这种行为可能允许攻击者读取宿主机文件系统上的敏感信息（如果Docker容器以不安全的方式挂载了宿主机文件系统）。然而，这并不是Docker容器隔离机制本身的漏洞，而是应用程序对输入验证的缺陷。因此，此漏洞可能会间接影响宿主机，但不会直接影响其他容器。
|
||||
|
||||
3. **结论**：
|
||||
条件1和条件2部分满足，因此返回分析结果，而不是N/A。
|
||||
|
||||
cve: ./data/2021/21xxx/CVE-2021-21284.json
|
||||
In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in which access to remapped root allows privilege escalation to real root. When using "--userns-remap", if the root user in the remapped namespace has access to the host filesystem they can modify files under "/var/lib/docker/<remapping>" that cause writing files with extended privileges. Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user.
|
||||
analysis: ### 分析结果：
|
||||
|
||||
1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||||
是的，该CVE与namespace和容器隔离相关。具体来说，问题涉及`--userns-remap`选项，这是一个与用户命名空间（user namespace）相关的功能，用于增强容器的隔离性。然而，由于漏洞的存在，即使在用户命名空间中运行的容器用户被重新映射为非特权用户，仍然可能通过特定方式提升到真实的root权限。
|
||||
|
||||
2. **是否会导致容器（如Docker）在运行时影响其他容器或宿主机：**
|
||||
是的，该漏洞可能导致容器突破隔离，影响宿主机的安全性。如果攻击者能够在容器内利用此漏洞，他们可以修改宿主机上的文件（例如`/var/lib/docker/<remapping>`路径下的文件），从而导致特权提升到真实的root用户。这将使攻击者能够控制宿主机，并进一步影响其他容器的运行环境。
|
||||
|
||||
3. **结论：**
|
||||
由于条件1和条件2均满足，因此返回上述分析内容。
|
||||
|
||||
cve: ./data/2021/21xxx/CVE-2021-21285.json
|
||||
In Docker before versions 9.03.15, 20.10.3 there is a vulnerability in which pulling an intentionally malformed Docker image manifest crashes the dockerd daemon. Versions 20.10.3 and 19.03.15 contain patches that prevent the daemon from crashing.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
是的，该CVE与容器相关。它涉及Docker软件中的一个漏洞，具体是在处理恶意构造的Docker镜像清单时导致Docker守护进程（dockerd）崩溃。
|
||||
|
||||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||||
该漏洞可能会间接影响宿主机的稳定性。由于恶意镜像清单能够导致Docker守护进程崩溃，这会使整个Docker服务不可用，从而可能影响正在运行的所有容器。然而，此漏洞本身并不直接破坏容器之间的隔离性或允许攻击者访问宿主机资源。
|
||||
|
||||
3. **结论**：
|
||||
条件1满足，条件2部分满足（影响宿主机服务可用性但不破坏隔离性）。因此，返回分析结果而非"N/A"。
|
||||
|
||||
cve: ./data/2021/21xxx/CVE-2021-21979.json
|
||||
In Bitnami Containers, all Laravel container versions prior to: 6.20.0-debian-10-r107 for Laravel 6, 7.30.1-debian-10-r108 for Laravel 7 and 8.5.11-debian-10-r0 for Laravel 8, the file /tmp/app/.env is generated at the time that the docker image bitnami/laravel was built, and the value of APP_KEY is fixed under certain conditions. This value is crucial for the security of the application and must be randomly generated per Laravel installation. If your application's encryption key is in the hands of a malicious party, that party could craft cookie values using the encryption key and exploit vulnerabilities inherent to PHP object serialization / unserialization, such as calling arbitrary class methods within your application.
|
||||
analysis: 1. 该 CVE 信息与 namespace、cgroup、container 或容器隔离机制无直接关系。问题的核心是 Bitnami Laravel 容器镜像中生成的 `/tmp/app/.env` 文件中的 `APP_KEY` 在某些条件下是固定的，而非动态随机生成。这属于应用程序级别的安全配置问题，而不是容器或隔离机制本身的漏洞。
|
||||
|
||||
2. 该 CVE 不会直接导致运行中的容器（例如 Docker）影响其他容器或宿主机。问题主要在于单个容器内的 Laravel 应用程序的安全性，由于 `APP_KEY` 固定可能导致恶意用户利用 PHP 序列化/反序列化漏洞进行攻击。这种攻击的影响范围通常局限于当前容器内的应用逻辑，而不会直接影响其他容器或宿主机，除非应用本身暴露了敏感接口或权限提升漏洞。
|
||||
|
||||
因此，根据分析要求，返回：**N/A**
|
||||
|
||||
cve: ./data/2021/23xxx/CVE-2021-23732.json
|
||||
This affects all versions of package docker-cli-js. If the command parameter of the Docker.command method can at least be partially controlled by a user, they will be in a position to execute any arbitrary OS commands on the host system.
|
||||
analysis: 1. 该 CVE 信息与 namespace、cgroup、container 或者容器、隔离相关。
|
||||
- 描述中提到 Docker.command 方法，这表明问题与 Docker 容器技术有关。
|
||||
|
||||
2. 该 CVE 会导致容器（例如 Docker）在运行时影响其他容器或宿主机。
|
||||
- 描述中明确指出，如果用户能够控制 `Docker.command` 方法的参数，他们可以执行任意操作系统命令，从而直接影响宿主机的安全性。这种情况下，攻击者可能突破容器隔离，对宿主机或其他容器造成威胁。
|
||||
|
||||
**结论：满足条件 1 和 2。**
|
||||
|
||||
cve: ./data/2021/33xxx/CVE-2021-33183.json
|
||||
Improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability container volume management component in Synology Docker before 18.09.0-0515 allows local users to read or write arbitrary files via unspecified vectors.
|
||||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||||
该 CVE 描述中明确提到了 "container volume management component"，这表明问题与容器的卷管理组件有关。容器卷管理涉及文件系统挂载和路径处理，因此与容器技术（如 Docker）直接相关。
|
||||
|
||||
2. **分析是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||||
根据描述，此漏洞允许本地用户通过未指定的向量读取或写入任意文件。这种路径遍历漏洞可能会导致攻击者突破容器的隔离机制，访问宿主机上的文件系统或其他容器的数据。因此，该漏洞可能会影响容器的隔离性，并对宿主机或其他容器造成潜在威胁。
|
||||
|
||||
3. **结论：**
|
||||
条件 1 和条件 2 均满足，因此返回分析结果而非 "N/A"。
|
||||
|
||||
cve: ./data/2021/34xxx/CVE-2021-34079.json
|
||||
OS Command injection vulnerability in Mintzo Docker-Tester through 1.2.1 allows attackers to execute arbitrary commands via shell metacharacters in the 'ports' entry of a crafted docker-compose.yml file.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
是的，该漏洞与容器相关。它涉及 Docker-Tester 工具，该工具用于处理 `docker-compose.yml` 文件，并通过其中的 `ports` 条目进行命令注入。
|
||||
|
||||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||||
有可能。由于这是一个命令注入漏洞，攻击者可以通过精心构造的 `docker-compose.yml` 文件中的 `ports` 条目执行任意命令。如果 Docker-Tester 以特权模式运行或具有对宿主机系统的访问权限，攻击者可能利用此漏洞影响宿主机或其他容器。
|
||||
|
||||
**结论**：满足条件 1 和 2。
|
||||
|
||||
cve: ./data/2021/34xxx/CVE-2021-34824.json
|
||||
Istio (1.8.x, 1.9.0-1.9.5 and 1.10.0-1.10.1) contains a remotely exploitable vulnerability where credentials specified in the Gateway and DestinationRule credentialName field can be accessed from different namespaces.
|
||||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关：**
|
||||
该CVE描述中提到“credentials specified in the Gateway and DestinationRule credentialName field can be accessed from different namespaces”，说明存在跨命名空间（namespace）访问凭证的安全问题。因此，该漏洞与命名空间（namespace）相关。
|
||||
|
||||
2. **分析是否会导致容器（如Docker等）在运行时影响其他容器或宿主机：**
|
||||
该漏洞主要涉及Istio服务网格中的配置问题，导致不同命名空间之间的凭证可以被访问。虽然它与命名空间隔离有关，但并没有直接提及容器运行时的隔离机制（如cgroup或容器本身）。此外，描述中没有提到此漏洞会影响其他容器或宿主机的安全性。因此，该漏洞不会直接导致容器运行时影响其他容器或宿主机。
|
||||
|
||||
3. **结论：**
|
||||
根据以上分析，条件1部分满足（与namespace相关），但条件2不满足（不会影响其他容器或宿主机）。因此，返回以下分析结果：
|
||||
|
||||
- 与namespace相关。
|
||||
- 不会影响其他容器或宿主机。
|
||||
|
||||
cve: ./data/2021/37xxx/CVE-2021-37841.json
|
||||
Docker Desktop before 3.6.0 suffers from incorrect access control. If a low-privileged account is able to access the server running the Windows containers, it can lead to a full container compromise in both process isolation and Hyper-V isolation modes. This security issue leads an attacker with low privilege to read, write and possibly even execute code inside the containers.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
是的，该CVE明确提到Docker Desktop在Windows容器中的问题，并涉及两种隔离模式（进程隔离和Hyper-V隔离）。这表明它与容器技术和隔离机制密切相关。
|
||||
|
||||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机**：
|
||||
是的，该漏洞允许低权限用户完全控制容器（读、写甚至执行代码），从而可能导致容器被攻破。虽然描述中没有明确提到对宿主机的影响，但一旦容器被完全控制，攻击者可能利用容器逃逸技术进一步危害宿主机或其他容器，因此存在潜在风险。
|
||||
|
||||
**结论**：满足条件1和2。
|
||||
|
||||
cve: ./data/2021/38xxx/CVE-2021-38209.json
|
||||
net/netfilter/nf_conntrack_standalone.c in the Linux kernel before 5.12.2 allows observation of changes in any net namespace because these changes are leaked into all other net namespaces. This is related to the NF_SYSCTL_CT_MAX, NF_SYSCTL_CT_EXPECT_MAX, and NF_SYSCTL_CT_BUCKETS sysctls.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||||
是的，该 CVE 与 namespace 相关。具体来说，它涉及网络命名空间（net namespace）中的连接跟踪（connection tracking, conntrack）机制。问题的核心在于，某些 sysctl 参数（如 `NF_SYSCTL_CT_MAX`、`NF_SYSCTL_CT_EXPECT_MAX` 和 `NF_SYSCTL_CT_BUCKETS`）的变化会泄露到所有其他网络命名空间中，这破坏了不同命名空间之间的隔离性。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||||
是的，该漏洞可能会影响容器的隔离性。由于容器通常依赖于网络命名空间来实现网络隔离，而此漏洞会导致一个命名空间中的连接跟踪配置变化泄露到其他命名空间，因此攻击者可能通过这种方式观察或推测其他容器或宿主机的网络活动。这种信息泄露可能会被进一步利用，从而威胁系统的安全性。
|
||||
|
||||
**结论：**
|
||||
满足条件 1 和 2，因此需要返回上述分析内容。
|
||||
|
||||
cve: ./data/2021/39xxx/CVE-2021-39159.json
|
||||
BinderHub is a kubernetes-based cloud service that allows users to share reproducible interactive computing environments from code repositories. In affected versions a remote code execution vulnerability has been identified in BinderHub, where providing BinderHub with maliciously crafted input could execute code in the BinderHub context, with the potential to egress credentials of the BinderHub deployment, including JupyterHub API tokens, kubernetes service accounts, and docker registry credentials. This may provide the ability to manipulate images and other user created pods in the deployment, with the potential to escalate to the host depending on the underlying kubernetes configuration. Users are advised to update to version 0.2.0-n653. If users are unable to update they may disable the git repo provider by specifying the `BinderHub.repo_providers` as a workaround.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或容器、隔离相关**：
|
||||
是的，该 CVE 与容器和隔离相关。BinderHub 是基于 Kubernetes 的服务，而 Kubernetes 使用容器（如 Docker）来运行用户的工作负载。此外，漏洞描述中提到可能通过恶意输入执行代码，并进一步影响 Kubernetes 配置下的主机，这表明问题涉及容器环境及其潜在的隔离机制。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||||
是的，该漏洞可能导致容器影响宿主机。根据描述，攻击者可以通过 BinderHub 的漏洞获取敏感凭据（如 Kubernetes 服务账户、Docker 注册表凭据等），并利用这些凭据操控部署中的其他容器或甚至升级权限到宿主机，具体取决于 Kubernetes 的配置。
|
||||
|
||||
3. **结论**：
|
||||
条件 1 和条件 2 均满足，因此需要返回分析结果。
|
||||
|
||||
cve: ./data/2021/3xxx/CVE-2021-3493.json
|
||||
The overlayfs implementation in the linux kernel did not properly validate with respect to user namespaces the setting of file capabilities on files in an underlying file system. Due to the combination of unprivileged user namespaces along with a patch carried in the Ubuntu kernel to allow unprivileged overlay mounts, an attacker could use this to gain elevated privileges.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||||
是的，该 CVE 信息与 namespace 和容器隔离相关。具体来说，问题涉及 overlayfs 在 Linux 内核中的实现，以及用户命名空间 (user namespaces) 的验证问题。OverlayFS 是一种常用于容器技术（如 Docker）的文件系统，而用户命名空间是容器隔离机制的重要组成部分。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||||
是的，该漏洞可能导致容器内的攻击者提升权限，从而影响宿主机或其他容器的安全性。由于 Ubuntu 内核中携带的一个补丁允许非特权用户挂载 overlay 文件系统，结合用户命名空间的不当验证，攻击者可以在容器内利用此漏洞获得宿主机上的更高权限。
|
||||
|
||||
**结论：**
|
||||
该 CVE 与 namespace 和容器隔离机制相关，并且可能被利用来突破容器隔离，影响宿主机或其他容器的安全性。
|
||||
|
||||
cve: ./data/2021/3xxx/CVE-2021-3557.json
|
||||
A flaw was found in argocd. Any unprivileged user is able to deploy argocd in their namespace and with the created ServiceAccount argocd-argocd-server, the unprivileged user is able to read all resources of the cluster including all secrets which might enable privilege escalations. The highest threat from this vulnerability is to data confidentiality.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||||
是的，该漏洞与namespace相关。描述中提到“unprivileged user is able to deploy argocd in their namespace”，说明攻击者可以在特定的namespace中部署argocd，并利用创建的ServiceAccount（`argocd-argocd-server`）访问集群中的资源。
|
||||
|
||||
2. **是否会导致容器（例如Docker等）在运行时影响其他容器或宿主机：**
|
||||
从描述来看，此漏洞并不会直接影响其他容器或宿主机。它的主要威胁是数据保密性问题，即通过权限提升可以读取集群中的所有资源和秘密信息。然而，这种行为并未直接破坏容器隔离机制，而是通过Kubernetes API权限管理的问题导致了信息泄露。
|
||||
|
||||
3. **结论：**
|
||||
由于条件1部分满足，条件2不满足，因此需要返回分析结果而非"N/A"。
|
||||
|
||||
**分析结果：**
|
||||
- 该CVE与namespace相关，涉及Kubernetes权限管理和资源访问问题。
|
||||
- 不会直接影响其他容器或宿主机，但可能导致敏感信息泄露，从而间接威胁系统的安全性。
|
||||
|
||||
cve: ./data/2021/3xxx/CVE-2021-3602.json
|
||||
An information disclosure flaw was found in Buildah, when building containers using chroot isolation. Running processes in container builds (e.g. Dockerfile RUN commands) can access environment variables from parent and grandparent processes. When run in a container in a CI/CD environment, environment variables may include sensitive information that was shared with the container in order to be used only by Buildah itself (e.g. container registry credentials).
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||||
是的，该 CVE 信息明确提到 Buildah 在使用 chroot 隔离方式构建容器时存在问题。chroot 是一种隔离技术，虽然它不像 namespace 和 cgroup 那样全面，但仍然属于容器隔离的一部分。因此，该问题与容器和隔离机制相关。
|
||||
|
||||
2. **是否会导致容器（例如 Docker）在运行时影响其他容器或宿主机**：
|
||||
该漏洞导致的是信息泄露问题，而不是直接破坏隔离性或影响其他容器或宿主机的运行。具体来说，容器内的进程可以访问到父进程或祖父进程的环境变量，这些变量可能包含敏感信息（如容器镜像仓库凭据）。这种信息泄露可能会间接影响系统的安全性，但不会直接导致容器逃逸或其他容器被影响。
|
||||
|
||||
**结论**：
|
||||
满足条件 1，不满足条件 2。因此，返回以下分析结果：
|
||||
|
||||
- 与容器和隔离机制相关。
|
||||
- 不会直接影响其他容器或宿主机的运行，但可能导致敏感信息泄露。
|
||||
|
||||
cve: ./data/2021/3xxx/CVE-2021-3948.json
|
||||
An incorrect default permissions vulnerability was found in the mig-controller. Due to an incorrect cluster namespaces handling an attacker may be able to migrate a malicious workload to the target cluster, impacting confidentiality, integrity, and availability of the services located on that cluster.
|
||||
analysis: 1. **分析是否与 namespace、cgroup、container 或容器、隔离相关**：
|
||||
该 CVE 提到的是 `mig-controller` 中由于默认权限配置错误，导致对集群命名空间处理不当。这涉及到 Kubernetes 集群中的命名空间（namespace）管理问题，因此与 namespace 相关。虽然没有直接提到 cgroup 或容器隔离机制，但迁移恶意工作负载的行为可能会影响容器化的服务。
|
||||
|
||||
2. **分析是否会导致容器运行时影响其他容器或宿主机**：
|
||||
攻击者可以通过此漏洞将恶意工作负载迁移到目标集群，从而影响目标集群上的服务的机密性、完整性和可用性。如果目标集群上运行了多个容器化服务，这种影响可能会波及其他容器或整个集群环境，甚至可能间接影响宿主机的安全性。
|
||||
|
||||
3. **结论**：
|
||||
根据以上分析，条件 1 和 2 均满足，因此返回以下信息：
|
||||
- 与 namespace 相关，可能间接影响容器和宿主机的安全性。
|
||||
|
||||
cve: ./data/2021/41xxx/CVE-2021-41089.json
|
||||
Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where attempting to copy files using `docker cp` into a specially-crafted container can result in Unix file permission changes for existing files in the host’s filesystem, widening access to others. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers do not need to be restarted.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||||
是的，该 CVE 与容器技术直接相关。它涉及 Moby（Docker Engine）中的 `docker cp` 功能，该功能允许用户在主机和容器之间复制文件。此问题可能导致主机文件系统的权限被意外更改，从而影响隔离性。
|
||||
|
||||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机：**
|
||||
是的，该漏洞可能会影响宿主机的安全性。通过利用此漏洞，攻击者可以改变宿主机文件系统的权限，从而放宽对某些敏感文件的访问控制。虽然这本身不会直接导致文件被读取、修改或执行，但权限的变化可能会为其他攻击提供便利，间接影响其他容器或宿主机的安全。
|
||||
|
||||
**结论：**
|
||||
满足条件 1 和 2，因此返回上述分析内容。
|
||||
|
||||
cve: ./data/2021/41xxx/CVE-2021-41091.json
|
||||
Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where the data directory (typically `/var/lib/docker`) contained subdirectories with insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as `setuid`), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade limit access to the host to trusted users. Limit access to host volumes to trusted containers.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关：**
|
||||
是的，该 CVE 与容器相关。它描述了 Moby（Docker Engine）中 `/var/lib/docker` 数据目录的子目录权限设置不当的问题，这可能导致容器内的文件被宿主机上的非特权用户访问和修改。此外，当容器中包含具有扩展权限位（如 `setuid`）的可执行程序时，这些程序可能被宿主机上的非特权用户发现并执行。
|
||||
|
||||
2. **是否会导致容器在运行时影响其他容器或宿主机：**
|
||||
是的，该漏洞可能会导致容器运行时影响宿主机和其他容器。由于权限设置不当，宿主机上的非特权用户可以访问容器内的文件和程序，甚至执行它们。如果 UID 冲突，用户还可以读取、修改容器内的文件，从而破坏容器的隔离性，并可能进一步影响宿主机或其他容器的安全性。
|
||||
|
||||
**结论：满足条件 1 和 2。**
|
||||
|
||||
cve: ./data/2021/41xxx/CVE-2021-41805.json
|
||||
HashiCorp Consul Enterprise before 1.8.17, 1.9.x before 1.9.11, and 1.10.x before 1.10.4 has Incorrect Access Control. An ACL token (with the default operator:write permissions) in one namespace can be used for unintended privilege escalation in a different namespace.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关：**
|
||||
是的，该 CVE 与 namespace 相关。HashiCorp Consul Enterprise 的问题涉及到 ACL token 在不同 namespace 中的权限控制错误，这表明它利用了 namespace 的概念来实现隔离。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机：**
|
||||
不会直接影响其他容器或宿主机。此漏洞主要涉及 HashiCorp Consul 的多 namespace 隔离机制中的权限控制问题，而不是容器运行时的安全性问题。虽然它可能导致跨 namespace 的权限提升，但并未直接提到对容器或宿主机的威胁。
|
||||
|
||||
**结论：** 满足条件 1，但不满足条件 2。
|
||||
|
||||
cve: ./data/2021/42xxx/CVE-2021-42762.json
|
||||
BubblewrapLauncher.cpp in WebKitGTK and WPE WebKit before 2.34.1 allows a limited sandbox bypass that allows a sandboxed process to trick host processes into thinking the sandboxed process is not confined by the sandbox, by abusing VFS syscalls that manipulate its filesystem namespace. The impact is limited to host services that create UNIX sockets that WebKit mounts inside its sandbox, and the sandboxed process remains otherwise confined. NOTE: this is similar to CVE-2021-41133.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
是的，这个CVE与namespace和隔离相关。描述中提到“sandbox bypass”以及“filesystem namespace”，表明问题涉及文件系统命名空间的隔离机制。具体来说，漏洞允许沙盒内的进程通过滥用VFS系统调用来操控其文件系统命名空间，从而欺骗宿主机上的进程，使其认为该沙盒内进程未被隔离。
|
||||
|
||||
2. **是否会导致容器（如Docker等）在运行时影响其他容器或宿主机**：
|
||||
根据描述，影响是有限的。漏洞仅影响那些创建UNIX套接字并将其挂载到WebKit沙盒内的宿主机服务。沙盒内的进程仍然保持其他方面的隔离。因此，虽然此漏洞可能导致一定程度的隔离失效，但并不会直接导致容器运行时影响其他容器或宿主机（除非宿主机上有特定的服务配置，且这些服务依赖于受影响的沙盒机制）。
|
||||
|
||||
**结论**：满足条件1，部分满足条件2（影响有限）。
|
||||
|
||||
cve: ./data/2021/43xxx/CVE-2021-43784.json
|
||||
runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc, netlink is used internally as a serialization system for specifying the relevant container configuration to the `C` portion of the code (responsible for the based namespace setup of containers). In all versions of runc prior to 1.0.3, the encoder did not handle the possibility of an integer overflow in the 16-bit length field for the byte array attribute type, meaning that a large enough malicious byte array attribute could result in the length overflowing and the attribute contents being parsed as netlink messages for container configuration. This vulnerability requires the attacker to have some control over the configuration of the container and would allow the attacker to bypass the namespace restrictions of the container by simply adding their own netlink payload which disables all namespaces. The main users impacted are those who allow untrusted images with untrusted configurations to run on their machines (such as with shared cloud infrastructure). runc version 1.0.3 contains a fix for this bug. As a workaround, one may try disallowing untrusted namespace paths from your container. It should be noted that untrusted namespace paths would allow the attacker to disable namespace protections entirely even in the absence of this bug.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||||
是的，这个 CVE 与 namespace 和容器隔离直接相关。漏洞描述中明确提到，攻击者可以通过构造恶意的字节数组属性，导致 netlink 消息被错误解析，从而绕过容器的 namespace 限制。Namespace 是 Linux 容器（如 Docker）实现隔离的核心机制之一，因此该漏洞直接影响了容器的隔离性。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||||
是的，该漏洞可能会导致容器突破隔离，影响宿主机或其他容器的安全性。具体来说，攻击者可以通过此漏洞禁用所有 namespaces，从而使容器能够访问宿主机的资源，甚至可能进一步危害宿主机上的其他容器或系统本身。这违反了容器设计中的隔离原则。
|
||||
|
||||
**结论**：满足条件 1 和条件 2，无需返回 "N/A"。
|
||||
|
||||
cve: ./data/2021/44xxx/CVE-2021-44731.json
|
||||
A race condition existed in the snapd 2.54.2 snap-confine binary when preparing a private mount namespace for a snap. This could allow a local attacker to gain root privileges by bind-mounting their own contents inside the snap's private mount namespace and causing snap-confine to execute arbitrary code and hence gain privilege escalation. Fixed in snapd versions 2.54.3+18.04, 2.54.3+20.04 and 2.54.3+21.10.1
|
||||
analysis: 1. 该 CVE 信息与 namespace 相关，因为它提到了 "private mount namespace" 的准备过程中存在竞争条件。
|
||||
2. 该 CVE 可能会导致容器运行时受到影响，因为攻击者可以通过 bind-mount 的方式注入自己的内容到 snap 的私有挂载命名空间中，并导致 snap-confine 执行任意代码。这可能会进一步影响宿主机或其他容器的隔离性，尤其是在共享宿主机的情况下。
|
||||
3. 因此，这个 CVE 满足条件 1 和 2。
|
||||
|
||||
cve: ./data/2021/46xxx/CVE-2021-46283.json
|
||||
nf_tables_newset in net/netfilter/nf_tables_api.c in the Linux kernel before 5.12.13 allows local users to cause a denial of service (NULL pointer dereference and general protection fault) because of the missing initialization for nft_set_elem_expr_alloc. A local user can set a netfilter table expression in their own namespace.
|
||||
analysis: 1. **分析是否与namespace、cgroup、container或者容器、隔离相关**
|
||||
该 CVE 描述中提到 `nft_set_elem_expr_alloc` 的初始化缺失问题，导致本地用户可以在其自己的命名空间（namespace）中设置 netfilter 表达式。由于涉及到命名空间（namespace），这与 Linux 容器的隔离机制有一定关联，因为命名空间是容器隔离的核心技术之一。
|
||||
|
||||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**
|
||||
虽然该漏洞允许本地用户在其自己的命名空间中触发问题，但描述中并未明确指出此漏洞能够突破命名空间的限制，从而影响其他容器或宿主机。因此，从现有信息来看，该漏洞似乎仅限于在用户自己的命名空间内造成拒绝服务（DoS），而不会直接影响其他容器或宿主机。
|
||||
|
||||
3. **结论**
|
||||
条件 1 满足（与命名空间相关），条件 2 不满足（不会影响其他容器或宿主机）。
|
||||
|
||||
cve: ./data/2021/46xxx/CVE-2021-46912.json
|
||||
In the Linux kernel, the following vulnerability has been resolved:
|
||||
|
||||
net: Make tcp_allowed_congestion_control readonly in non-init netns
|
||||
|
||||
Currently, tcp_allowed_congestion_control is global and writable;
|
||||
writing to it in any net namespace will leak into all other net
|
||||
namespaces.
|
||||
|
||||
tcp_available_congestion_control and tcp_allowed_congestion_control are
|
||||
the only sysctls in ipv4_net_table (the per-netns sysctl table) with a
|
||||
NULL data pointer; their handlers (proc_tcp_available_congestion_control
|
||||
and proc_allowed_congestion_control) have no other way of referencing a
|
||||
struct net. Thus, they operate globally.
|
||||
|
||||
Because ipv4_net_table does not use designated initializers, there is no
|
||||
easy way to fix up this one "bad" table entry. However, the data pointer
|
||||
updating logic shouldn't be applied to NULL pointers anyway, so we
|
||||
instead force these entries to be read-only.
|
||||
|
||||
These sysctls used to exist in ipv4_table (init-net only), but they were
|
||||
moved to the per-net ipv4_net_table, presumably without realizing that
|
||||
tcp_allowed_congestion_control was writable and thus introduced a leak.
|
||||
|
||||
Because the intent of that commit was only to know (i.e. read) "which
|
||||
congestion algorithms are available or allowed", this read-only solution
|
||||
should be sufficient.
|
||||
|
||||
The logic added in recent commit
|
||||
31c4d2f160eb: ("net: Ensure net namespace isolation of sysctls")
|
||||
does not and cannot check for NULL data pointers, because
|
||||
other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have
|
||||
.data=NULL but use other methods (.extra2) to access the struct net.
|
||||
analysis: 1. **分析是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||||
该 CVE 描述了 `tcp_allowed_congestion_control` 在非初始化网络命名空间（non-init netns）中是可写的，这会导致一个网络命名空间的更改泄露到其他网络命名空间。因此，此漏洞直接涉及 Linux 的网络命名空间（network namespace），这是容器隔离机制的一部分。容器技术（如 Docker）通常依赖于命名空间来实现资源隔离，因此该问题与容器隔离密切相关。
|
||||
|
||||
2. **分析是否会导致容器在运行时影响其他容器或宿主机**：
|
||||
由于 `tcp_allowed_congestion_control` 是全局可写的，更改在一个容器的网络命名空间中的值可能会泄露到其他容器或宿主机的网络命名空间。这种行为破坏了容器之间的隔离性，可能导致意外的行为或安全风险。因此，此漏洞会影响容器的隔离性，并可能间接影响其他容器或宿主机。
|
||||
|
||||
3. **结论**：
|
||||
条件 1 和条件 2 均满足，因此需要返回分析结果而不是 "N/A"。
|
||||
|
||||
**最终分析结果**：
|
||||
- 该 CVE 与网络命名空间相关，直接影响容器的隔离性。
|
||||
- 容器运行时的配置更改可能泄露到其他容器或宿主机，破坏隔离性。
|
||||
|
||||
cve: ./data/2021/46xxx/CVE-2021-46936.json
|
||||
In the Linux kernel, the following vulnerability has been resolved:
|
||||
|
||||
net: fix use-after-free in tw_timer_handler
|
||||
|
||||
A real world panic issue was found as follow in Linux 5.4.
|
||||
|
||||
BUG: unable to handle page fault for address: ffffde49a863de28
|
||||
PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
|
||||
RIP: 0010:tw_timer_handler+0x20/0x40
|
||||
Call Trace:
|
||||
<IRQ>
|
||||
call_timer_fn+0x2b/0x120
|
||||
run_timer_softirq+0x1ef/0x450
|
||||
__do_softirq+0x10d/0x2b8
|
||||
irq_exit+0xc7/0xd0
|
||||
smp_apic_timer_interrupt+0x68/0x120
|
||||
apic_timer_interrupt+0xf/0x20
|
||||
|
||||
This issue was also reported since 2017 in the thread [1],
|
||||
unfortunately, the issue was still can be reproduced after fixing
|
||||
DCCP.
|
||||
|
||||
The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net
|
||||
namespace is destroyed since tcp_sk_ops is registered befrore
|
||||
ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops
|
||||
in the list of pernet_list. There will be a use-after-free on
|
||||
net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net
|
||||
if there are some inflight time-wait timers.
|
||||
|
||||
This bug is not introduced by commit f2bf415cfed7 ("mib: add net to
|
||||
NET_ADD_STATS_BH") since the net_statistics is a global variable
|
||||
instead of dynamic allocation and freeing. Actually, commit
|
||||
61a7e26028b9 ("mib: put net statistics on struct net") introduces
|
||||
the bug since it put net statistics on struct net and free it when
|
||||
net namespace is destroyed.
|
||||
|
||||
Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug
|
||||
and replace pr_crit() with panic() since continuing is meaningless
|
||||
when init_ipv4_mibs() fails.
|
||||
|
||||
[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**
|
||||
是的，该漏洞涉及网络命名空间（net namespace）。问题出现在销毁网络命名空间时，`ipv4_mib_exit_net` 被调用在 `tcp_sk_exit_batch` 之前，导致了 `tw_timer_handler` 中的 use-after-free 问题。网络命名空间是 Linux 容器（如 Docker）实现网络隔离的核心机制之一，因此该漏洞与命名空间和隔离相关。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**
|
||||
是的，该漏洞可能导致容器在运行时影响宿主机或其他容器。由于网络命名空间是容器隔离的重要组成部分，如果一个容器的网络命名空间被销毁时触发了该漏洞，可能会导致宿主机内核崩溃（panic），从而影响整个系统以及运行在该宿主机上的所有容器。
|
||||
|
||||
3. **结论**
|
||||
根据以上分析，条件 1 和 2 均满足。
|
||||
|
||||
cve: ./data/2021/47xxx/CVE-2021-47010.json
|
||||
In the Linux kernel, the following vulnerability has been resolved:
|
||||
|
||||
net: Only allow init netns to set default tcp cong to a restricted algo
|
||||
|
||||
tcp_set_default_congestion_control() is netns-safe in that it writes
|
||||
to &net->ipv4.tcp_congestion_control, but it also sets
|
||||
ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced.
|
||||
This has the unintended side-effect of changing the global
|
||||
net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it
|
||||
is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control
|
||||
readonly in non-init netns")
|
||||
|
||||
Resolve this netns "leak" by only allowing the init netns to set the
|
||||
default algorithm to one that is restricted. This restriction could be
|
||||
removed if tcp_allowed_congestion_control were namespace-ified in the
|
||||
future.
|
||||
|
||||
This bug was uncovered with
|
||||
https://github.com/JonathonReinhart/linux-netns-sysctl-verify
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或容器、隔离相关**：
|
||||
是的，这个 CVE 信息与 namespace 相关。具体来说，它涉及网络命名空间（netns）的安全问题。`tcp_set_default_congestion_control()` 函数在设置默认 TCP 拥塞控制算法时，虽然针对特定命名空间进行了操作，但意外地修改了全局的 `net.ipv4.tcp_allowed_congestion_control` 系统参数。这表明该漏洞与 Linux 命名空间的隔离性有关。
|
||||
|
||||
2. **是否会导致容器（如 Docker）在运行时影响其他容器或宿主机**：
|
||||
是的，此漏洞可能会导致容器影响宿主机或其他容器。由于问题在于网络命名空间的隔离性被破坏，非初始化命名空间（non-init netns）可以间接修改全局的 TCP 拥塞控制设置，这可能会影响宿主机上的网络行为以及其他使用相同内核的容器。
|
||||
|
||||
3. **结论**：
|
||||
条件 1 和条件 2 都满足，因此需要返回分析结果，而不是 "N/A"。
|
||||
|
||||
cve: ./data/2021/47xxx/CVE-2021-47011.json
|
||||
In the Linux kernel, the following vulnerability has been resolved:
|
||||
|
||||
mm: memcontrol: slab: fix obtain a reference to a freeing memcg
|
||||
|
||||
Patch series "Use obj_cgroup APIs to charge kmem pages", v5.
|
||||
|
||||
Since Roman's series "The new cgroup slab memory controller" applied.
|
||||
All slab objects are charged with the new APIs of obj_cgroup. The new
|
||||
APIs introduce a struct obj_cgroup to charge slab objects. It prevents
|
||||
long-living objects from pinning the original memory cgroup in the
|
||||
memory. But there are still some corner objects (e.g. allocations
|
||||
larger than order-1 page on SLUB) which are not charged with the new
|
||||
APIs. Those objects (include the pages which are allocated from buddy
|
||||
allocator directly) are charged as kmem pages which still hold a
|
||||
reference to the memory cgroup.
|
||||
|
||||
E.g. We know that the kernel stack is charged as kmem pages because the
|
||||
size of the kernel stack can be greater than 2 pages (e.g. 16KB on
|
||||
x86_64 or arm64). If we create a thread (suppose the thread stack is
|
||||
charged to memory cgroup A) and then move it from memory cgroup A to
|
||||
memory cgroup B. Because the kernel stack of the thread hold a
|
||||
reference to the memory cgroup A. The thread can pin the memory cgroup
|
||||
A in the memory even if we remove the cgroup A. If we want to see this
|
||||
scenario by using the following script. We can see that the system has
|
||||
added 500 dying cgroups (This is not a real world issue, just a script
|
||||
to show that the large kmallocs are charged as kmem pages which can pin
|
||||
the memory cgroup in the memory).
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
cat /proc/cgroups | grep memory
|
||||
|
||||
cd /sys/fs/cgroup/memory
|
||||
echo 1 > memory.move_charge_at_immigrate
|
||||
|
||||
for i in range{1..500}
|
||||
do
|
||||
mkdir kmem_test
|
||||
echo $$ > kmem_test/cgroup.procs
|
||||
sleep 3600 &
|
||||
echo $$ > cgroup.procs
|
||||
echo `cat kmem_test/cgroup.procs` > cgroup.procs
|
||||
rmdir kmem_test
|
||||
done
|
||||
|
||||
cat /proc/cgroups | grep memory
|
||||
|
||||
This patchset aims to make those kmem pages to drop the reference to
|
||||
memory cgroup by using the APIs of obj_cgroup. Finally, we can see that
|
||||
the number of the dying cgroups will not increase if we run the above test
|
||||
script.
|
||||
|
||||
This patch (of 7):
|
||||
|
||||
The rcu_read_lock/unlock only can guarantee that the memcg will not be
|
||||
freed, but it cannot guarantee the success of css_get (which is in the
|
||||
refill_stock when cached memcg changed) to memcg.
|
||||
|
||||
rcu_read_lock()
|
||||
memcg = obj_cgroup_memcg(old)
|
||||
__memcg_kmem_uncharge(memcg)
|
||||
refill_stock(memcg)
|
||||
if (stock->cached != memcg)
|
||||
// css_get can change the ref counter from 0 back to 1.
|
||||
css_get(&memcg->css)
|
||||
rcu_read_unlock()
|
||||
|
||||
This fix is very like the commit:
|
||||
|
||||
eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge")
|
||||
|
||||
Fix this by holding a reference to the memcg which is passed to the
|
||||
__memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**：
|
||||
是的，这个 CVE 信息与 cgroup 相关。它涉及到 Linux 内核中的内存控制组 (memory cgroup) 和 slab 分配器的实现。具体来说，问题出现在对内存控制组的引用计数管理上，可能导致长期存在的对象（如内核栈）在内存控制组被移除后仍然持有对该控制组的引用，从而阻止其被正确释放。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||||
可能会。由于该漏洞涉及内存控制组的管理，而内存控制组是容器隔离机制的重要组成部分之一（用于限制和隔离容器的资源使用），因此如果一个容器的内存使用行为触发了此漏洞，可能会导致内存控制组的不正确释放或引用计数问题。这可能间接影响到其他容器或宿主机的资源管理，尤其是在多租户环境下，可能会导致资源泄漏或隔离性受损。
|
||||
|
||||
3. **结论**：
|
||||
条件 1 和条件 2 都满足，因此返回分析结果而不是 "N/A"。
|
||||
|
||||
cve: ./data/2021/47xxx/CVE-2021-47379.json
|
||||
In the Linux kernel, the following vulnerability has been resolved:
|
||||
|
||||
blk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pd
|
||||
|
||||
KASAN reports a use-after-free report when doing fuzz test:
|
||||
|
||||
[693354.104835] ==================================================================
|
||||
[693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160
|
||||
[693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338
|
||||
|
||||
[693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147
|
||||
[693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018
|
||||
[693354.105612] Call Trace:
|
||||
[693354.105621] dump_stack+0xf1/0x19b
|
||||
[693354.105626] ? show_regs_print_info+0x5/0x5
|
||||
[693354.105634] ? printk+0x9c/0xc3
|
||||
[693354.105638] ? cpumask_weight+0x1f/0x1f
|
||||
[693354.105648] print_address_description+0x70/0x360
|
||||
[693354.105654] kasan_report+0x1b2/0x330
|
||||
[693354.105659] ? bfq_io_set_weight_legacy+0xd3/0x160
|
||||
[693354.105665] ? bfq_io_set_weight_legacy+0xd3/0x160
|
||||
[693354.105670] bfq_io_set_weight_legacy+0xd3/0x160
|
||||
[693354.105675] ? bfq_cpd_init+0x20/0x20
|
||||
[693354.105683] cgroup_file_write+0x3aa/0x510
|
||||
[693354.105693] ? ___slab_alloc+0x507/0x540
|
||||
[693354.105698] ? cgroup_file_poll+0x60/0x60
|
||||
[693354.105702] ? 0xffffffff89600000
|
||||
[693354.105708] ? usercopy_abort+0x90/0x90
|
||||
[693354.105716] ? mutex_lock+0xef/0x180
|
||||
[693354.105726] kernfs_fop_write+0x1ab/0x280
|
||||
[693354.105732] ? cgroup_file_poll+0x60/0x60
|
||||
[693354.105738] vfs_write+0xe7/0x230
|
||||
[693354.105744] ksys_write+0xb0/0x140
|
||||
[693354.105749] ? __ia32_sys_read+0x50/0x50
|
||||
[693354.105760] do_syscall_64+0x112/0x370
|
||||
[693354.105766] ? syscall_return_slowpath+0x260/0x260
|
||||
[693354.105772] ? do_page_fault+0x9b/0x270
|
||||
[693354.105779] ? prepare_exit_to_usermode+0xf9/0x1a0
|
||||
[693354.105784] ? enter_from_user_mode+0x30/0x30
|
||||
[693354.105793] entry_SYSCALL_64_after_hwframe+0x65/0xca
|
||||
|
||||
[693354.105875] Allocated by task 1453337:
|
||||
[693354.106001] kasan_kmalloc+0xa0/0xd0
|
||||
[693354.106006] kmem_cache_alloc_node_trace+0x108/0x220
|
||||
[693354.106010] bfq_pd_alloc+0x96/0x120
|
||||
[693354.106015] blkcg_activate_policy+0x1b7/0x2b0
|
||||
[693354.106020] bfq_create_group_hierarchy+0x1e/0x80
|
||||
[693354.106026] bfq_init_queue+0x678/0x8c0
|
||||
[693354.106031] blk_mq_init_sched+0x1f8/0x460
|
||||
[693354.106037] elevator_switch_mq+0xe1/0x240
|
||||
[693354.106041] elevator_switch+0x25/0x40
|
||||
[693354.106045] elv_iosched_store+0x1a1/0x230
|
||||
[693354.106049] queue_attr_store+0x78/0xb0
|
||||
[693354.106053] kernfs_fop_write+0x1ab/0x280
|
||||
[693354.106056] vfs_write+0xe7/0x230
|
||||
[693354.106060] ksys_write+0xb0/0x140
|
||||
[693354.106064] do_syscall_64+0x112/0x370
|
||||
[693354.106069] entry_SYSCALL_64_after_hwframe+0x65/0xca
|
||||
|
||||
[693354.106114] Freed by task 1453336:
|
||||
[693354.106225] __kasan_slab_free+0x130/0x180
|
||||
[693354.106229] kfree+0x90/0x1b0
|
||||
[693354.106233] blkcg_deactivate_policy+0x12c/0x220
|
||||
[693354.106238] bfq_exit_queue+0xf5/0x110
|
||||
[693354.106241] blk_mq_exit_sched+0x104/0x130
|
||||
[693354.106245] __elevator_exit+0x45/0x60
|
||||
[693354.106249] elevator_switch_mq+0xd6/0x240
|
||||
[693354.106253] elevator_switch+0x25/0x40
|
||||
[693354.106257] elv_iosched_store+0x1a1/0x230
|
||||
[693354.106261] queue_attr_store+0x78/0xb0
|
||||
[693354.106264] kernfs_fop_write+0x1ab/0x280
|
||||
[693354.106268] vfs_write+0xe7/0x230
|
||||
[693354.106271] ksys_write+0xb0/0x140
|
||||
[693354.106275] do_syscall_64+0x112/0x370
|
||||
[693354.106280] entry_SYSCALL_64_after_hwframe+0x65/0xca
|
||||
|
||||
[693354.106329] The buggy address belongs to the object at ffff888be0a35580
|
||||
which belongs to the cache kmalloc-1k of size 1024
|
||||
[693354.106736] The buggy address is located 228 bytes inside of
|
||||
1024-byte region [ffff888be0a35580, ffff888be0a35980)
|
||||
[693354.107114] The buggy address belongs to the page:
|
||||
[693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0
|
||||
[693354.107606] flags: 0x17ffffc0008100(slab|head)
|
||||
[693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080
|
||||
[693354.108020] r
|
||||
---truncated---
|
||||
analysis: ### Analysis:
|
||||
|
||||
1. **Is this CVE information related to namespace, cgroup, container, or isolation?**
|
||||
- Yes, this CVE is related to `cgroup` (control groups). Specifically, the issue involves a Use-After-Free (UAF) vulnerability in the block I/O control group (`blk-cgroup`) subsystem of the Linux kernel. Control groups are a fundamental component of containerization technologies like Docker, as they are used to limit and isolate resource usage (CPU, memory, block I/O, etc.) for groups of processes.
|
||||
|
||||
2. **Does this CVE affect other containers or the host when running containers like Docker?**
|
||||
- Potentially yes. The `blk-cgroup` subsystem is responsible for managing and enforcing block I/O resource limits for processes within a cgroup. If an attacker can exploit this UAF vulnerability, it could lead to arbitrary code execution or a denial of service (DoS) condition. This could allow a malicious container to escape its resource restrictions, potentially affecting other containers or even the host system if the vulnerability is successfully exploited.
|
||||
|
||||
3. **Conclusion:**
|
||||
- Since both conditions 1 and 2 are satisfied, this CVE is relevant to container isolation and could impact the security of containerized environments.
|
||||
|
||||
**Final Answer:**
|
||||
- Related to namespace/cgroup/container/isolation: **Yes**.
|
||||
- Can affect other containers or the host: **Potentially yes**.
|
||||
|
||||
cve: ./data/2021/47xxx/CVE-2021-47579.json
|
||||
In the Linux kernel, the following vulnerability has been resolved:
|
||||
|
||||
ovl: fix warning in ovl_create_real()
|
||||
|
||||
Syzbot triggered the following warning in ovl_workdir_create() ->
|
||||
ovl_create_real():
|
||||
|
||||
if (!err && WARN_ON(!newdentry->d_inode)) {
|
||||
|
||||
The reason is that the cgroup2 filesystem returns from mkdir without
|
||||
instantiating the new dentry.
|
||||
|
||||
Weird filesystems such as this will be rejected by overlayfs at a later
|
||||
stage during setup, but to prevent such a warning, call ovl_mkdir_real()
|
||||
directly from ovl_workdir_create() and reject this case early.
|
||||
analysis: 1. **分析是否与 namespace、cgroup、container 或容器、隔离相关**
|
||||
该 CVE 涉及到 `cgroup2` 文件系统和 `overlayfs`，而 `cgroup2` 是 Linux 控制组（cgroup）的第二代实现，用于资源限制、优先级、会计等。此外，`overlayfs` 是一种常用于容器技术（如 Docker）的文件系统，用于提供分层文件系统支持。因此，这个 CVE 与 cgroup 和容器技术相关。
|
||||
|
||||
2. **分析是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**
|
||||
该漏洞涉及 `ovl_create_real()` 函数中的警告处理问题，当 `cgroup2` 文件系统返回未实例化的新 dentry 时，可能会触发警告。虽然此问题已被修复以避免警告，但它可能暴露了 `overlayfs` 在处理特殊文件系统时的潜在不稳定性。如果 `overlayfs` 的行为受到影响，理论上可能导致容器的文件系统操作异常，进而间接影响其他容器或宿主机的稳定性。然而，从描述来看，此漏洞并未直接导致安全边界突破（如逃逸到宿主机），而是更偏向于功能性或稳定性问题。
|
||||
|
||||
3. **结论**
|
||||
根据上述分析，该 CVE 与 cgroup 和容器技术相关，并可能对容器的稳定性产生一定影响，但没有明确证据表明它会导致容器逃逸或直接影响其他容器或宿主机的安全性。因此，满足条件 1 和部分条件 2。
|
||||
|
||||
cve: ./data/2021/47xxx/CVE-2021-47584.json
|
||||
In the Linux kernel, the following vulnerability has been resolved:
|
||||
|
||||
iocost: Fix divide-by-zero on donation from low hweight cgroup
|
||||
|
||||
The donation calculation logic assumes that the donor has non-zero
|
||||
after-donation hweight, so the lowest active hweight a donating cgroup can
|
||||
have is 2 so that it can donate 1 while keeping the other 1 for itself.
|
||||
Earlier, we only donated from cgroups with sizable surpluses so this
|
||||
condition was always true. However, with the precise donation algorithm
|
||||
implemented, f1de2439ec43 ("blk-iocost: revamp donation amount
|
||||
determination") made the donation amount calculation exact enabling even low
|
||||
hweight cgroups to donate.
|
||||
|
||||
This means that in rare occasions, a cgroup with active hweight of 1 can
|
||||
enter donation calculation triggering the following warning and then a
|
||||
divide-by-zero oops.
|
||||
|
||||
WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867]
|
||||
...
|
||||
RIP: 0010:transfer_surpluses.cold+0x0/0x53
|
||||
Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0
|
||||
4
|
||||
...
|
||||
Call Trace:
|
||||
<IRQ>
|
||||
ioc_timer_fn+0x1043/0x1390
|
||||
call_timer_fn+0xa1/0x2c0
|
||||
__run_timers.part.0+0x1ec/0x2e0
|
||||
run_timer_softirq+0x35/0x70
|
||||
...
|
||||
iocg: invalid donation weights in /a/b: active=1 donating=1 after=0
|
||||
|
||||
Fix it by excluding cgroups w/ active hweight < 2 from donating. Excluding
|
||||
these extreme low hweight donations shouldn't affect work conservation in
|
||||
any meaningful way.
|
||||
analysis: 1. **是否与namespace、cgroup、container或者容器、隔离相关**
|
||||
是的，该 CVE 信息与 cgroup 相关。具体来说，问题出现在 Linux 内核的 iocost 子系统中，涉及 cgroup 的捐赠逻辑（donation logic）。cgroup 是 Linux 中用于实现资源限制和隔离的重要机制，因此该问题与 cgroup 和隔离密切相关。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**
|
||||
从描述来看，这个问题主要是一个除以零错误（divide-by-zero），它可能导致内核崩溃（oops）。如果此漏洞被触发，可能会影响整个系统的稳定性，包括宿主机和其他运行在宿主机上的容器。因此，该漏洞可能会导致容器运行时影响其他容器或宿主机。
|
||||
|
||||
3. **结论**
|
||||
根据以上分析，条件 1 和 2 均满足，因此返回以下分析结果：
|
||||
- 与 cgroup 和隔离相关。
|
||||
- 可能会导致容器影响其他容器或宿主机。
|
||||
|
||||
cve: ./data/2021/4xxx/CVE-2021-4154.json
|
||||
A use-after-free flaw was found in cgroup1_parse_param in kernel/cgroup/cgroup-v1.c in the Linux kernel's cgroup v1 parser. A local attacker with a user privilege could cause a privilege escalation by exploiting the fsconfig syscall parameter leading to a container breakout and a denial of service on the system.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||||
是的，该 CVE 信息明确提到 `cgroup1_parse_param` 函数，这是 Linux 内核中 cgroup v1 的一部分。Cgroup（Control Group）是用于限制、控制和隔离进程组资源使用的重要机制，广泛应用于容器技术（如 Docker）中以实现资源隔离。
|
||||
|
||||
2. **是否会导致容器（如 Docker 等）在运行时影响其他容器或宿主机**：
|
||||
是的，该漏洞可能导致容器突破（container breakout）。具体来说，攻击者可以通过利用 `fsconfig` 系统调用参数中的 use-after-free 漏洞，提升权限并逃逸出容器环境，从而影响其他容器或宿主机的安全性。此外，漏洞还可能引发拒绝服务（Denial of Service, DoS），进一步威胁系统稳定性。
|
||||
|
||||
**结论**：该 CVE 信息满足条件 1 和 2。
|
||||
|
||||
cve: ./data/2021/4xxx/CVE-2021-4197.json
|
||||
An unprivileged write to the file handler flaw in the Linux kernel's control groups and namespaces subsystem was found in the way users have access to some less privileged process that are controlled by cgroups and have higher privileged parent process. It is actually both for cgroup2 and cgroup1 versions of control groups. A local user could use this flaw to crash the system or escalate their privileges on the system.
|
||||
analysis: 1. **是否与 namespace、cgroup、container 或者容器、隔离相关**：
|
||||
是的，该 CVE 明确提到 Linux 内核的 control groups (cgroups) 和 namespaces 子系统存在漏洞。cgroups 是容器技术（如 Docker）中用于资源限制和隔离的重要组成部分，因此该漏洞与 cgroups 和隔离机制直接相关。
|
||||
|
||||
2. **是否会导致容器（例如 Docker 等）在运行时影响其他容器或宿主机**：
|
||||
是的，该漏洞可能会影响容器的安全性。由于 cgroups 是容器资源隔离的核心机制之一，如果攻击者利用此漏洞，可能会突破容器的隔离边界，影响其他容器或宿主机。具体来说，漏洞允许本地用户通过未授权的写操作导致系统崩溃或权限提升，这可能被恶意容器利用来影响宿主机或其他容器的稳定性或安全性。
|
||||
|
||||
**结论**：满足条件 1 和 2。
|
||||
Reference in New Issue
Block a user