diff --git a/DoS_ai_analysis.py b/DoS_ai_analysis.py new file mode 100644 index 0000000..1348e38 --- /dev/null +++ b/DoS_ai_analysis.py @@ -0,0 +1,84 @@ +# 分析每个CVE源自哪个应用程序、什么原因、什么后果等信息 + +from os import truncate +import re +import json +from openai import OpenAI +from typing import Dict, List, Any + + +def process_result(data: Any) -> str: + # target_key = "choices.0.message.content" + parts = ["choices", "0", "message", "content"] + try: + for part in parts: + if isinstance(data, list): + data = data[int(part)] + else: + data = data.get(part, None) + if data is None: + break + return data + except (KeyError, IndexError, TypeError): + return "N/A" + return "N/A" + + +def analyze_with_ai(data: str) -> str: + prompt = """ + 你是一个计算机容器安全领域的专家，能够根据CVE描述分析出CVE产生于哪个程序、有何影响后果等信息。 + 下面我会发给你一段文本，第一行是CVE的编号与文件位置信息，后续是这个CVE的详细描述。 + 请分析我发送给你的CVE详细描述内容，并进行分析，我有如下要求： + 1. 分析这个CVE信息，判断这个CVE漏洞描述中是否提及会导致容器消耗更多宿主机的物理资源，例如CPU计算资源、内存资源或是硬盘空间资源，**注意**：不要自行推测，只分析这个描述中是否提及； + 2. 如果不满足条件1，你只需返回"N/A"即可，无需任何多余信息； + 3. 如果这个CVE满足条件1，那么你只需要直接返回一个json，这个json样例如下： + {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机CPU资源被大量占用]"，"CVE_Consequence":"[该CVE的后果，以及严重程度]"} + 请牢记，你必须只返回json内容，除了json不需要任何文本内容，并且尽量使用中文。 + """ + + client = OpenAI( + api_key="sk-5ec7751941974a9cb5855f746fe45a62", + base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", + ) + try: + completion = client.chat.completions.create( + # 模型列表：https://help.aliyun.com/zh/model-studio/getting-started/models + model="qwen-plus", + messages=[ + {"role": "system", "content": prompt}, + {"role": "user", "content": data}, + ], + # Qwen3模型通过enable_thinking参数控制思考过程（开源版默认True，商业版默认False） + # 使用Qwen3开源版模型时，若未启用流式输出，请将下行取消注释，否则会报错 + # extra_body={"enable_thinking": False}, + ) + return process_result(json.loads(completion.model_dump_json())) + except Exception as e: + print(f"调用大模型失败: {str(e)}") + return "N/A" + return "N/A" + + +if __name__ == "__main__": + pattern = r"\./data/.*x/CVE.*?\.json" + regex = re.compile(pattern) + + with open("keyword_filter_11-25.log", "r", encoding="utf-8") as file: + text = file.read() + matches = list(regex.finditer(text)) + + log = open("./DoS_result/pure_from_description_11-25.log", "w", encoding="utf-8") + + # 如果没有找到任何匹配项 + if not matches: + print("No match found.") + else: + for i in range(len(matches)): + start = matches[i].start() + # 如果不是最后一个匹配项，则end是下一个匹配项的起始位置；否则为文本末尾 + end = matches[i + 1].start() if i + 1 < len(matches) else len(text) + block = text[start:end].strip() + ans = analyze_with_ai(block) + if ans == "N/A": + continue + log.write(f"cve: {block}\n\nanalysis: {ans}\n\n") diff --git a/DoS_result/analysis_result_11-20.log b/DoS_result/analysis_result_11-20.log new file mode 100644 index 0000000..b312798 --- /dev/null +++ b/DoS_result/analysis_result_11-20.log @@ -0,0 +1,180 @@ +cve: ./data/2011/1xxx/CVE-2011-1022.json +The cgre_receive_netlink_msg function in daemon/cgrulesengd.c in cgrulesengd in the Control Group Configuration Library (aka libcgroup or libcg) before 0.37.1 does not verify that netlink messages originated in the kernel, which allows local users to bypass intended resource restrictions via a crafted message. + +analysis: {"Conatiner":"[使用libcgroup或libcg的容器镜像]","CVE_Reason"："[容器内的用户可以通过构造的消息绕过资源限制，导致宿主机CPU、内存等资源被大量占用]","CVE_Consequence":"[该CVE允许本地用户绕过预期的资源限制，可能导致宿主机资源耗尽，严重程度为高]"} + +cve: ./data/2011/2xxx/CVE-2011-2189.json +net/core/net_namespace.c in the Linux kernel 2.6.32 and earlier does not properly handle a high rate of creation and cleanup of network namespaces, which makes it easier for remote attackers to cause a denial of service (memory consumption) via requests to a daemon that requires a separate namespace per connection, as demonstrated by vsftpd. + +analysis: {"Container":"[使用Linux内核2.6.32及更早版本的容器镜像]","CVE_Reason":"[容器中的网络命名空间创建和清理速率过高，导致宿主机内存资源被大量消耗]","CVE_Consequence":"[该CVE可能导致宿主机内存耗尽，引发拒绝服务攻击，严重程度较高]"} + +cve: ./data/2012/1xxx/CVE-2012-1146.json +The mem_cgroup_usage_unregister_event function in mm/memcontrol.c in the Linux kernel before 3.2.10 does not properly handle multiple events that are attached to the same eventfd, which allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact by registering memory threshold events. + +analysis: {"Conatiner":"[使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的进程可能通过注册内存阈值事件，导致宿主机CPU资源被大量占用以处理无效事件]","CVE_Consequence":"[该CVE可能导致宿主机系统崩溃或服务中断，严重程度为高]"} + +cve: ./data/2012/2xxx/CVE-2012-2127.json +fs/proc/root.c in the procfs implementation in the Linux kernel before 3.2 does not properly interact with CLONE_NEWPID clone system calls, which allows remote attackers to cause a denial of service (reference leak and memory consumption) by making many connections to a daemon that uses PID namespaces to isolate clients, as demonstrated by vsftpd. + +analysis: {"Conatiner":"[使用PID命名空间隔离客户端的容器镜像，例如包含vsftpd的服务容器]","CVE_Reason"："[容器内的进程可以通过不当的PID命名空间交互导致宿主机内存资源被大量消耗]"，“CVE_Consequence”：“[该CVE会导致内存泄漏，严重程度较高，可能引发宿主机内存耗尽，进而导致系统不稳定或崩溃]”} + +cve: ./data/2013/4xxx/CVE-2013-4205.json +Memory leak in the unshare_userns function in kernel/user_namespace.c in the Linux kernel before 3.10.6 allows local users to cause a denial of service (memory consumption) via an invalid CLONE_NEWUSER unshare call. + +analysis: {"Conatiner":"[使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的进程可以通过无效的CLONE_NEWUSER调用导致宿主机内存资源泄漏被大量占用]"，"CVE_Consequence":"[该CVE会导致宿主机内存耗尽，造成拒绝服务，严重程度为高]"} + +cve: ./data/2014/1xxx/CVE-2014-1425.json +cmanager 0.32 does not properly enforce nesting when modifying cgroup properties, which allows local users to set cgroup values for all cgroups via unspecified vectors. + +analysis: {"Conatiner":"cmanager 0.32","CVE_Reason":"容器的运行可能导致宿主机CPU或内存资源被大量占用，因为cgroup属性未正确强制执行嵌套规则，允许本地用户设置所有cgroup的值。","CVE_Consequence":"该CVE可能允许攻击者通过操纵cgroup配置，绕过资源限制，导致宿主机资源耗尽，严重程度较高。"} + +cve: ./data/2014/5xxx/CVE-2014-5207.json +fs/namespace.c in the Linux kernel through 3.16.1 does not properly restrict clearing MNT_NODEV, MNT_NOSUID, and MNT_NOEXEC and changing MNT_ATIME_MASK during a remount of a bind mount, which allows local users to gain privileges, interfere with backups and auditing on systems that had atime enabled, or cause a denial of service (excessive filesystem updating) on systems that had atime disabled via a "mount -o remount" command within a user namespace. + +analysis: {"Conatiner":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的用户可以通过特定的挂载操作，导致宿主机文件系统频繁更新，从而消耗大量CPU和硬盘资源]","CVE_Consequence":"[该CVE可能导致宿主机文件系统过度更新，引发性能下降或拒绝服务，严重程度较高]"} + +cve: ./data/2014/7xxx/CVE-2014-7970.json +The pivot_root implementation in fs/namespace.c in the Linux kernel through 3.17 does not properly interact with certain locations of a chroot directory, which allows local users to cause a denial of service (mount-tree loop) via . (dot) values in both arguments to the pivot_root system call. + +analysis: {"Conatiner":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的恶意进程可能通过pivot_root系统调用创建挂载循环，导致宿主机CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致宿主机陷入无限递归的挂载操作，最终耗尽CPU资源，造成拒绝服务，严重程度高]"} + +cve: ./data/2014/8xxx/CVE-2014-8171.json +The memory resource controller (aka memcg) in the Linux kernel allows local users to cause a denial of service (deadlock) by spawning new processes within a memory-constrained cgroup. + +analysis: {"Conatiner":"[任何使用受影响Linux内核的容器]","CVE_Reason"："[容器内的进程可以在内存受限的cgroup中不断创建新进程，导致宿主机内存资源被大量消耗并最终死锁]","CVE_Consequence":"[该CVE可能导致宿主机内存资源耗尽，引发系统死锁，严重程度高]"} + +cve: ./data/2015/3xxx/CVE-2015-3629.json +Libcontainer 1.6.0, as used in Docker Engine, allows local users to escape containerization ("mount namespace breakout") and write to arbitrary file on the host system via a symlink attack in an image when respawning a container. + +analysis: {"Container":"Docker Engine（使用Libcontainer 1.6.0）","CVE_Reason":"容器内的用户可通过符号链接攻击逃逸到宿主机，并写入宿主机任意文件，可能间接导致资源消耗增加","CVE_Consequence":"该CVE允许本地用户通过容器逃逸漏洞破坏宿主机文件系统，可能导致严重安全问题，包括宿主机资源耗尽"} + +cve: ./data/2015/3xxx/CVE-2015-3631.json +Docker Engine before 1.6.1 allows local users to set arbitrary Linux Security Modules (LSM) and docker_t policies via an image that allows volumes to override files in /proc. + +analysis: {"Conatiner":"Docker Engine","CVE_Reason":"容器内的用户可以通过覆盖 /proc 中的文件设置任意 Linux 安全模块（LSM）和 docker_t 策略，可能导致对宿主机资源的非预期控制或滥用，例如消耗大量 CPU 或内存资源","CVE_Consequence":"此 CVE 可能导致本地用户绕过安全限制，滥用宿主机资源，严重程度较高"} + +cve: ./data/2016/6xxx/CVE-2016-6213.json +fs/namespace.c in the Linux kernel before 4.9 does not restrict how many mounts may exist in a mount namespace, which allows local users to cause a denial of service (memory consumption and deadlock) via MS_BIND mount system calls, as demonstrated by a loop that triggers exponential growth in the number of mounts. + +analysis: {"Container":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason":"[容器内的应用程序通过MS_BIND挂载调用，可能导致宿主机内存资源被大量消耗]","CVE_Consequence":"[该CVE会导致内存消耗过快，可能引发系统死锁，严重程度高]"} + +cve: ./data/2016/8xxx/CVE-2016-8579.json +docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain. + +analysis: {"Conatiner":"docker2aci","CVE_Reason":"容器的运行会导致宿主机CPU资源被大量占用","CVE_Consequence":"由于存在无限循环，该CVE可能会导致宿主机CPU资源耗尽，严重程度较高"} + +cve: ./data/2016/9xxx/CVE-2016-9191.json +The cgroup offline implementation in the Linux kernel through 4.8.11 mishandles certain drain operations, which allows local users to cause a denial of service (system hang) by leveraging access to a container environment for executing a crafted application, as demonstrated by trinity. + +analysis: {"Conatiner":"[任何使用cgroup的容器镜像]","CVE_Reason"："[容器的运行会触发cgroup offline实现中的漏洞，导致宿主机系统挂起，可能消耗大量CPU资源或阻塞核心进程调度]"，"CVE_Consequence":"[该CVE可能导致宿主机完全不可用，严重程度为高]"} + +cve: ./data/2017/1000xxx/CVE-2017-1000111.json +Linux kernel: heap out-of-bounds in AF_PACKET sockets. This new issue is analogous to previously disclosed CVE-2016-8655. In both cases, a socket option that changes socket state may race with safety checks in packet_set_ring. Previously with PACKET_VERSION. This time with PACKET_RESERVE. The solution is similar: lock the socket for the update. This issue may be exploitable, we did not investigate further. As this issue affects PF_PACKET sockets, it requires CAP_NET_RAW in the process namespace. But note that with user namespaces enabled, any process can create a namespace in which it has CAP_NET_RAW. + +analysis: {"Conatiner":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的进程可能通过触发AF_PACKET sockets的堆越界问题，导致宿主机CPU资源被大量占用以处理错误状态和竞争条件]"，"CVE_Consequence":"[该CVE可能导致宿主机系统崩溃或性能显著下降，严重程度较高]"} + +cve: ./data/2017/11xxx/CVE-2017-11468.json +Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint. + +analysis: {"Container":"Docker Registry","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致远程攻击者通过manifest endpoint发送大量数据，造成宿主机内存耗尽，从而引发拒绝服务攻击，严重程度较高"} + +cve: ./data/2017/14xxx/CVE-2017-14179.json +Apport before 2.13 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion, possibly gain root privileges, or escape from containers. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason":"[容器的运行会导致宿主机CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致资源耗尽、拒绝服务攻击，严重程度为高]"} + +cve: ./data/2017/14xxx/CVE-2017-14180.json +Apport 2.13 through 2.20.7 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion or possibly gain root privileges, a different vulnerability than CVE-2017-14179. + +analysis: {"Container":"[使用Apport 2.13至2.20.7版本的容器镜像]","CVE_Reason":"[容器内的进程可以通过PID命名空间滥用导致宿主机资源耗尽]","CVE_Consequence":"[该CVE可能导致宿主机资源（如CPU或内存）被大量占用，引发拒绝服务攻击，严重程度高]"} + +cve: ./data/2017/14xxx/CVE-2017-14992.json +Lack of content verification in Docker-CE (Also known as Moby) versions 1.12.6-0, 1.10.3, 17.03.0, 17.03.1, 17.03.2, 17.06.0, 17.06.1, 17.06.2, 17.09.0, and earlier allows a remote attacker to cause a Denial of Service via a crafted image layer payload, aka gzip bombing. + +analysis: {"Conatiner":"Docker-CE (Moby)","CVE_Reason":"容器镜像层的解压过程中会消耗大量宿主机内存资源","CVE_Consequence":"该CVE可能导致宿主机内存资源耗尽，引发拒绝服务攻击，严重程度较高"} + +cve: ./data/2018/10xxx/CVE-2018-10205.json +hyperstart 1.0.0 in HyperHQ Hyper has memory leaks in the container_setup_modules and hyper_rescan_scsi functions in container.c, related to runV 1.0.0 for Docker. + +analysis: {"Container":"hyperhq/hyper","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE会导致内存泄漏，随着容器运行时间增加，宿主机可用内存逐渐减少，可能引发宿主机性能下降或系统不稳定，严重程度为高"} + +cve: ./data/2018/14xxx/CVE-2018-14646.json +The Linux kernel before 4.15-rc8 was found to be vulnerable to a NULL pointer dereference bug in the __netlink_ns_capable() function in the net/netlink/af_netlink.c file. A local attacker could exploit this when a net namespace with a netnsid is assigned to cause a kernel panic and a denial of service. + +analysis: {"Conatiner":"[使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的攻击者可以利用此漏洞触发内核崩溃，导致宿主机完全不可用，可能需要重启宿主机恢复]","CVE_Consequence":"[该CVE会导致宿主机内核崩溃，严重程度为高]"} + +cve: ./data/2018/16xxx/CVE-2018-16884.json +A flaw was found in the Linux kernel's NFS41+ subsystem. NFS41+ shares mounted in different network namespaces at the same time can make bc_svc_process() use wrong back-channel IDs and cause a use-after-free vulnerability. Thus a malicious container user can cause a host kernel memory corruption and a system panic. Due to the nature of the flaw, privilege escalation cannot be fully ruled out. + +analysis: {"Container":"[任何使用NFS41+挂载的容器镜像]","CVE_Reason":"[容器内的恶意用户可以触发宿主机内核内存腐蚀，进而导致系统崩溃或潜在的权限提升]","CVE_Consequence":"[该CVE可能导致宿主机内核内存损坏、系统宕机，甚至可能的权限提升，严重程度高]"} + +cve: ./data/2018/1xxx/CVE-2018-1277.json +Cloud Foundry Garden-runC, versions prior to 1.13.0, does not correctly enforce disc quotas for Docker image layers. A remote authenticated user may push an app with a malicious Docker image that will consume more space on a Diego cell than allocated in their quota, potentially causing a DoS against the cell. + +analysis: {"Conatiner":"Cloud Foundry Garden-runC","CVE_Reason":"容器的运行会导致宿主机硬盘空间资源被大量占用","CVE_Consequence":"恶意Docker镜像会消耗超出配额的磁盘空间，可能导致Diego cell拒绝服务，严重程度较高"} + +cve: ./data/2018/20xxx/CVE-2018-20699.json +Docker Engine before 18.09 allows attackers to cause a denial of service (dockerd memory consumption) via a large integer in a --cpuset-mems or --cpuset-cpus value, related to daemon/daemon_unix.go, pkg/parsers/parsers.go, and pkg/sysinfo/sysinfo.go. + +analysis: {"Conatiner":"Docker Engine","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能使攻击者通过在 --cpuset-mems 或 --cpuset-cpus 参数中指定大整数值，导致 dockerd 进程内存消耗过大，最终造成拒绝服务。严重程度为高。"} + +cve: ./data/2018/6xxx/CVE-2018-6552.json +Apport does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion, possibly gain root privileges, or escape from containers. The is_same_ns() function returns True when /proc// does not exist in order to indicate that the crash should be handled in the global namespace rather than inside of a container. However, the portion of the data/apport code that decides whether or not to forward a crash to a container does not always replace sys.argv[1] with the value stored in the host_pid variable when /proc// does not exist which results in the container pid being used in the global namespace. This flaw affects versions 2.20.8-0ubuntu4 through 2.20.9-0ubuntu7, 2.20.7-0ubuntu3.7, 2.20.7-0ubuntu3.8, 2.20.1-0ubuntu2.15 through 2.20.1-0ubuntu2.17, and 2.14.1-0ubuntu3.28. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason":"[容器的运行会导致宿主机CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致资源耗尽，引发拒绝服务攻击，严重程度高]"} + +cve: ./data/2018/7xxx/CVE-2018-7480.json +The blkcg_init_queue function in block/blk-cgroup.c in the Linux kernel before 4.11 allows local users to cause a denial of service (double free) or possibly have unspecified other impact by triggering a creation failure. + +analysis: {"Conatiner":"[任何使用受影响Linux内核版本的容器]","CVE_Reason"："[容器内的进程可能触发blkcg_init_queue函数中的双重释放漏洞，导致宿主机内核崩溃或不稳定，进而可能消耗更多CPU资源来处理错误状态或重启服务]","CVE_Consequence":"[该CVE可能导致宿主机拒绝服务，严重程度较高]"} + +cve: ./data/2019/10xxx/CVE-2019-10147.json +rkt through version 1.30.0 does not isolate processes in containers that are run with `rkt enter`. Processes run with `rkt enter` are not limited by cgroups during stage 2 (the actual environment in which the applications run). Compromised containers could exploit this flaw to access host resources. + +analysis: {"Container":"rkt","CVE_Reason":"容器中的进程在使用`rkt enter`运行时未受cgroups限制，可能导致宿主机资源被过度消耗，包括CPU和内存资源。","CVE_Consequence":"攻击者可以利用此漏洞访问宿主机资源，可能导致宿主机资源耗尽，影响宿主机及其他容器的稳定性，严重程度较高。"} + +cve: ./data/2019/12xxx/CVE-2019-12675.json +Multiple vulnerabilities in the multi-instance feature of Cisco Firepower Threat Defense (FTD) Software could allow an authenticated, local attacker to escape the container for their FTD instance and execute commands with root privileges in the host namespace. These vulnerabilities are due to insufficient protections on the underlying filesystem. An attacker could exploit these vulnerabilities by modifying critical files on the underlying filesystem. A successful exploit could allow the attacker to execute commands with root privileges within the host namespace. This could allow the attacker to impact other running FTD instances. + +analysis: {"Conatiner":"Cisco Firepower Threat Defense (FTD) Software","CVE_Reason":"容器逃逸后，攻击者可以在宿主机命名空间内执行命令，可能导致宿主机资源被滥用，例如占用大量CPU或内存资源","CVE_Consequence":"该CVE允许攻击者影响其他正在运行的FTD实例，可能完全控制宿主机，严重程度高"} + +cve: ./data/2019/16xxx/CVE-2019-16884.json +runc through 1.0.0-rc8, as used in Docker through 19.03.2-ce and other products, allows AppArmor restriction bypass because libcontainer/rootfs_linux.go incorrectly checks mount targets, and thus a malicious Docker image can mount over a /proc directory. + +analysis: {"Container":"[使用runc作为运行时的容器镜像]","CVE_Reason":"[容器内的恶意镜像可以绕过AppArmor限制，通过挂载覆盖宿主机的/proc目录，可能导致对宿主机资源的非授权访问和滥用，例如消耗大量CPU或内存资源]","CVE_Consequence":"[该CVE可能允许攻击者滥用宿主机资源，造成拒绝服务或其他安全风险，严重程度为高]"} + +cve: ./data/2019/20xxx/CVE-2019-20794.json +An issue was discovered in the Linux kernel 4.18 through 5.6.11 when unprivileged user namespaces are allowed. A user can create their own PID namespace, and mount a FUSE filesystem. Upon interaction with this FUSE filesystem, if the userspace component is terminated via a kill of the PID namespace's pid 1, it will result in a hung task, and resources being permanently locked up until system reboot. This can result in resource exhaustion. + +analysis: {"Conatiner":"[使用Linux内核4.18至5.6.11的容器环境]","CVE_Reason"："[容器内的用户可以通过创建PID命名空间和挂载FUSE文件系统，导致宿主机任务挂起和资源被永久锁定]","CVE_Consequence":"[该CVE可能导致宿主机资源耗尽，严重程度较高]"} + +cve: ./data/2019/3xxx/CVE-2019-3874.json +The SCTP socket buffer used by a userspace application is not accounted by the cgroups subsystem. An attacker can use this flaw to cause a denial of service attack. Kernel 3.10.x and 4.18.x branches are believed to be vulnerable. + +analysis: {"Conatiner":"[任何使用SCTP协议的容器镜像]","CVE_Reason"："[容器中的用户空间应用程序可以绕过cgroups限制，导致宿主机内存资源被大量占用]","CVE_Consequence":"[该CVE可能导致攻击者通过SCTP套接字缓冲区消耗大量宿主机内存资源，最终引发拒绝服务（严重）]"} + +cve: ./data/2020/14xxx/CVE-2020-14298.json +The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the fix for CVE-2019-5736, which was previously fixed via RHSA-2019:0304. This issue could allow a malicious or compromised container to compromise the container host and other containers running on the same host. This issue only affects docker version 1.13.1-108.git4ef4b30.el7, shipped in Red Hat Enterprise Linux 7 Extras. Both earlier and later versions are not affected. + +analysis: {"Conatiner":"[受影响的容器镜像，例如使用docker 1.13.1-108.git4ef4b30.el7的容器]","CVE_Reason"："[恶意容器可能利用该漏洞逃逸并直接访问宿主机资源，进而导致宿主机CPU、内存或硬盘资源被大量占用]","CVE_Consequence":"[攻击者可以完全控制宿主机系统，影响其上运行的所有容器，严重程度为高危]"} + +cve: ./data/2020/24xxx/CVE-2020-24263.json +Portainer 1.24.1 and earlier is affected by an insecure permissions vulnerability that may lead to remote arbitrary code execution. A non-admin user is allowed to spawn new containers with critical capabilities such as SYS_MODULE, which can be used to take over the Docker host. + +analysis: {"Conatiner":"Portainer","CVE_Reason":"非管理员用户可以创建具有关键权限的新容器（如SYS_MODULE），这些权限可能导致宿主机资源被大量消耗，例如CPU和内存资源","CVE_Consequence":"该CVE允许攻击者通过非管理员权限执行任意代码并控制Docker宿主机，严重程度为高"} + +cve: ./data/2020/24xxx/CVE-2020-24264.json +Portainer 1.24.1 and earlier is affected by incorrect access control that may lead to remote arbitrary code execution. The restriction checks for bind mounts are applied only on the client-side and not the server-side, which can lead to spawning a container with bind mount. Once such a container is spawned, it can be leveraged to break out of the container leading to complete Docker host machine takeover. + +analysis: {"Container":"Portainer","CVE_Reason":"容器的运行可能导致宿主机的文件系统被绑定挂载，攻击者可利用此漏洞突破容器限制，进而完全控制Docker宿主机，可能消耗大量CPU和内存资源","CVE_Consequence":"该CVE可能导致容器逃逸，从而使攻击者完全控制宿主机，严重程度为高危"} + +cve: ./data/2020/25xxx/CVE-2020-25220.json +The Linux kernel 4.9.x before 4.9.233, 4.14.x before 4.14.194, and 4.19.x before 4.19.140 has a use-after-free because skcd->no_refcnt was not considered during a backport of a CVE-2020-14356 patch. This is related to the cgroups feature. + +analysis: {"Conatiner":"[使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[由于use-after-free漏洞，攻击者可能触发异常情况，导致容器过度消耗宿主机CPU资源]","CVE_Consequence":"[该CVE可能导致宿主机系统性能下降甚至拒绝服务，严重程度为高]"} + +cve: ./data/2020/36xxx/CVE-2020-36694.json +An issue was discovered in netfilter in the Linux kernel before 5.10. There can be a use-after-free in the packet processing context, because the per-CPU sequence count is mishandled during concurrent iptables rules replacement. This could be exploited with the CAP_NET_ADMIN capability in an unprivileged namespace. NOTE: cc00bca was reverted in 5.12. + +analysis: {"Container":"[使用Linux内核5.10以下版本的容器镜像]","CVE_Reason":"[容器中的进程可能利用此漏洞触发use-after-free问题，进而导致CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致宿主机的CPU资源耗尽，严重程度为高]"} + diff --git a/DoS_result/analysis_result_21-25.log b/DoS_result/analysis_result_21-25.log new file mode 100644 index 0000000..6f8ca23 --- /dev/null +++ b/DoS_result/analysis_result_21-25.log @@ -0,0 +1,1593 @@ +cve: ./data/2021/39xxx/CVE-2021-39939.json +An uncontrolled resource consumption vulnerability in GitLab Runner affecting all versions starting from 13.7 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, allows an attacker triggering a job with a specially crafted docker image to exhaust resources on runner manager + +analysis: {"Container":"GitLab Runner使用的容器镜像","CVE_Reason":"攻击者可以通过触发一个带有特殊构造的docker镜像的任务，导致容器运行时无限制地消耗宿主机资源，例如CPU或内存资源。","CVE_Consequence":"该CVE可能导致宿主机资源被耗尽，影响其他正常任务的运行，严重程度较高。"} + +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: ```json +{"Container":"runc","CVE_Reason":"恶意字节数组属性可能导致整数溢出，从而使容器配置解析为netlink消息，攻击者可借此禁用所有命名空间限制，进而导致容器消耗更多宿主机的物理资源，例如内存和CPU资源","CVE_Consequence":"该CVE允许攻击者绕过容器的命名空间限制，可能导致宿主机资源被滥用，严重程度高"} +``` + +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: {"Container":"[任何使用受影响Linux内核版本的容器]","CVE_Reason":"[容器中的内存分配操作可能导致对宿主机内存资源的异常引用和占用，进而影响内存资源回收]","CVE_Consequence":"[该CVE可能导致宿主机上的内存资源无法有效释放，长期运行可能造成内存泄漏，严重程度为高]"} + +cve: ./data/2021/47xxx/CVE-2021-47119.json +In the Linux kernel, the following vulnerability has been resolved: + +ext4: fix memory leak in ext4_fill_super + +Buffer head references must be released before calling kill_bdev(); +otherwise the buffer head (and its page referenced by b_data) will not +be freed by kill_bdev, and subsequently that bh will be leaked. + +If blocksizes differ, sb_set_blocksize() will kill current buffers and +page cache by using kill_bdev(). And then super block will be reread +again but using correct blocksize this time. sb_set_blocksize() didn't +fully free superblock page and buffer head, and being busy, they were +not freed and instead leaked. + +This can easily be reproduced by calling an infinite loop of: + + systemctl start .mount, and + systemctl stop .mount + +... since systemd creates a cgroup for each slice which it mounts, and +the bh leak get amplified by a dying memory cgroup that also never +gets freed, and memory consumption is much more easily noticed. + +analysis: {"Container":"[使用ext4文件系统的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源泄漏，持续消耗更多物理内存]","CVE_Consequence":"[该CVE会导致内存泄漏，随着容器频繁挂载和卸载ext4文件系统，宿主机的内存消耗会不断增加，最终可能导致宿主机内存耗尽，严重程度为高]"} + +cve: ./data/2021/47xxx/CVE-2021-47408.json +In the Linux kernel, the following vulnerability has been resolved: + +netfilter: conntrack: serialize hash resizes and cleanups + +Syzbot was able to trigger the following warning [1] + +No repro found by syzbot yet but I was able to trigger similar issue +by having 2 scripts running in parallel, changing conntrack hash sizes, +and: + +for j in `seq 1 1000` ; do unshare -n /bin/true >/dev/null ; done + +It would take more than 5 minutes for net_namespace structures +to be cleaned up. + +This is because nf_ct_iterate_cleanup() has to restart everytime +a resize happened. + +By adding a mutex, we can serialize hash resizes and cleanups +and also make get_next_corpse() faster by skipping over empty +buckets. + +Even without resizes in the picture, this patch considerably +speeds up network namespace dismantles. + +[1] +INFO: task syz-executor.0:8312 can't die for more than 144 seconds. +task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006 +Call Trace: + context_switch kernel/sched/core.c:4955 [inline] + __schedule+0x940/0x26f0 kernel/sched/core.c:6236 + preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408 + preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35 + __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390 + local_bh_enable include/linux/bottom_half.h:32 [inline] + get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline] + nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275 + nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469 + ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171 + setup_net+0x639/0xa30 net/core/net_namespace.c:349 + copy_net_ns+0x319/0x760 net/core/net_namespace.c:470 + create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 + unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226 + ksys_unshare+0x445/0x920 kernel/fork.c:3128 + __do_sys_unshare kernel/fork.c:3202 [inline] + __se_sys_unshare kernel/fork.c:3200 [inline] + __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200 + do_syscall_x64 arch/x86/entry/common.c:50 [inline] + do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x44/0xae +RIP: 0033:0x7f63da68e739 +RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 +RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739 +RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000 +RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80 +R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000 + +Showing all locks held in the system: +1 lock held by khungtaskd/27: + #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446 +2 locks held by kworker/u4:2/153: + #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline] + #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline] + #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline] + #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline] + #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline] + #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268 + #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272 +1 lock held by systemd-udevd/2970: +1 lock held by in:imklog/6258: + #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990 +3 locks held by kworker/1:6/8158: +1 lock held by syz-executor.0/8312: +2 locks held by kworker/u4:13/9320: +1 lock held by +---truncated--- + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[容器内的网络连接跟踪操作可能导致宿主机CPU资源被大量占用，因为net_namespace结构清理时间过长]","CVE_Consequence":"[该CVE可能导致宿主机CPU资源耗尽，严重程度较高]"} + +cve: ./data/2021/47xxx/CVE-2021-47492.json +In the Linux kernel, the following vulnerability has been resolved: + +mm, thp: bail out early in collapse_file for writeback page + +Currently collapse_file does not explicitly check PG_writeback, instead, +page_has_private and try_to_release_page are used to filter writeback +pages. This does not work for xfs with blocksize equal to or larger +than pagesize, because in such case xfs has no page->private. + +This makes collapse_file bail out early for writeback page. Otherwise, +xfs end_page_writeback will panic as follows. + + page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:ffff0003f88c86a8 index:0x0 pfn:0x84ef32 + aops:xfs_address_space_operations [xfs] ino:30000b7 dentry name:"libtest.so" + flags: 0x57fffe0000008027(locked|referenced|uptodate|active|writeback) + raw: 57fffe0000008027 ffff80001b48bc28 ffff80001b48bc28 ffff0003f88c86a8 + raw: 0000000000000000 0000000000000000 00000000ffffffff ffff0000c3e9a000 + page dumped because: VM_BUG_ON_PAGE(((unsigned int) page_ref_count(page) + 127u <= 127u)) + page->mem_cgroup:ffff0000c3e9a000 + ------------[ cut here ]------------ + kernel BUG at include/linux/mm.h:1212! + Internal error: Oops - BUG: 0 [#1] SMP + Modules linked in: + BUG: Bad page state in process khugepaged pfn:84ef32 + xfs(E) + page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:0 index:0x0 pfn:0x84ef32 + libcrc32c(E) rfkill(E) aes_ce_blk(E) crypto_simd(E) ... + CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Tainted: ... + pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) + Call trace: + end_page_writeback+0x1c0/0x214 + iomap_finish_page_writeback+0x13c/0x204 + iomap_finish_ioend+0xe8/0x19c + iomap_writepage_end_bio+0x38/0x50 + bio_endio+0x168/0x1ec + blk_update_request+0x278/0x3f0 + blk_mq_end_request+0x34/0x15c + virtblk_request_done+0x38/0x74 [virtio_blk] + blk_done_softirq+0xc4/0x110 + __do_softirq+0x128/0x38c + __irq_exit_rcu+0x118/0x150 + irq_exit+0x1c/0x30 + __handle_domain_irq+0x8c/0xf0 + gic_handle_irq+0x84/0x108 + el1_irq+0xcc/0x180 + arch_cpu_idle+0x18/0x40 + default_idle_call+0x4c/0x1a0 + cpuidle_idle_call+0x168/0x1e0 + do_idle+0xb4/0x104 + cpu_startup_entry+0x30/0x9c + secondary_start_kernel+0x104/0x180 + Code: d4210000 b0006161 910c8021 94013f4d (d4210000) + ---[ end trace 4a88c6a074082f8c ]--- + Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt + +analysis: {"Container":"使用Linux内核的容器（例如基于Ubuntu、CentOS等的容器）","CVE_Reason":"容器中的应用程序在特定条件下可能会触发内存管理漏洞，导致宿主机CPU资源被大量占用","CVE_Consequence":"该CVE可能导致宿主机上的CPU资源被过度消耗，影响系统稳定性，严重时可能引发内核崩溃，需及时更新内核以修复此问题"} + +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: {"Container":"[任何使用Linux内核控制组和命名空间子系统的容器]","CVE_Reason"："[容器中的低特权进程可能通过cgroups影响高特权父进程，导致宿主机资源被异常消耗，例如CPU或内存资源]","CVE_Consequence":"[该CVE可能导致系统崩溃或权限提升，严重程度较高]"} + +cve: ./data/2022/0xxx/CVE-2022-0532.json +An incorrect sysctls validation vulnerability was found in CRI-O 1.18 and earlier. The sysctls from the list of "safe" sysctls specified for the cluster will be applied to the host if an attacker is able to create a pod with a hostIPC and hostNetwork kernel namespace. + +analysis: {"Container":"CRI-O 1.18及更早版本","CVE_Reason":"攻击者可以通过创建具有hostIPC和hostNetwork内核命名空间的Pod，将'safe' sysctls列表中指定的sysctls应用到主机，从而可能导致宿主机资源被过度消耗，例如CPU、内存或硬盘空间资源。","CVE_Consequence":"该CVE可能允许攻击者滥用容器权限影响宿主机系统，导致资源耗尽，严重程度较高。"} + +cve: ./data/2022/24xxx/CVE-2022-24122.json +kernel/ucount.c in the Linux kernel 5.14 through 5.16.4, when unprivileged user namespaces are enabled, allows a use-after-free and privilege escalation because a ucounts object can outlive its namespace. + +analysis: {"Container":"[使用受影响内核版本的任何容器]","CVE_Reason":"[容器内的进程可能利用此漏洞触发use-after-free，导致CPU资源被大量占用以维持攻击或提权过程]","CVE_Consequence":"[该CVE可能导致特权 escalation，攻击者可在宿主机上执行任意代码，严重程度：高]"} + +cve: ./data/2022/27xxx/CVE-2022-27652.json +A flaw was found in cri-o, where containers were incorrectly started with non-empty default permissions. A vulnerability was found in Moby (Docker Engine) where containers started incorrectly with non-empty inheritable Linux process capabilities. This flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs. + +analysis: {"Container":"cri-o、Moby (Docker Engine)","CVE_Reason":"容器以不正确的非空默认权限启动，可能导致攻击者利用继承的Linux进程能力提升权限，从而执行消耗大量CPU或内存资源的操作","CVE_Consequence":"攻击者可以提升权限，可能进一步导致宿主机资源被恶意消耗，严重程度较高"} + +cve: ./data/2022/28xxx/CVE-2022-28204.json +A denial-of-service issue was discovered in MediaWiki 1.37.x before 1.37.2. Rendering of w/index.php?title=Special%3AWhatLinksHere&target=Property%3AP31&namespace=1&invert=1 can take more than thirty seconds. There is a DDoS risk. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机CPU资源被大量占用]"，"CVE_Consequence":"[该CVE可能导致渲染特定页面时CPU使用率升高，严重程度为中等，可能被用于DDoS攻击]"} + +cve: ./data/2022/39xxx/CVE-2022-39206.json +Onedev is an open source, self-hosted Git Server with CI/CD and Kanban. When using Docker-based job executors, the Docker socket (e.g. /var/run/docker.sock on Linux) is mounted into each Docker step. Users that can define and trigger CI/CD jobs on a project could use this to control the Docker daemon on the host machine. This is a known dangerous pattern, as it can be used to break out of Docker containers and, in most cases, gain root privileges on the host system. This issue allows regular (non-admin) users to potentially take over the build infrastructure of a OneDev instance. Attackers need to have an account (or be able to register one) and need permission to create a project. Since code.onedev.io has the right preconditions for this to be exploited by remote attackers, it could have been used to hijack builds of OneDev itself, e.g. by injecting malware into the docker images that are built and pushed to Docker Hub. The impact is increased by this as described before. Users are advised to upgrade to 7.3.0 or higher. There are no known workarounds for this issue. + +analysis: {"Container":"OneDev","CVE_Reason":"容器的运行会导致宿主机的Docker守护进程被恶意控制，可能引发大量资源消耗，例如创建大量容器占用CPU、内存或硬盘空间资源","CVE_Consequence":"该CVE允许普通用户接管OneDev构建基础设施，可能导致宿主机资源被完全控制，严重程度为高"} + +cve: ./data/2022/48xxx/CVE-2022-48671.json +In the Linux kernel, the following vulnerability has been resolved: + +cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all() + +syzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at +cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix +threadgroup_rwsem <-> cpus_read_lock() deadlock") missed that +cpuset_attach() is also called from cgroup_attach_task_all(). +Add cpus_read_lock() like what cgroup_procs_write_start() does. + +analysis: {"Container":"[使用cgroup的容器镜像]","CVE_Reason"："[由于缺少cpus_read_lock()，可能导致CPU资源分配异常，从而引发宿主机CPU资源被大量占用]"，"CVE_Consequence":"[该CVE可能导致容器任务附加过程中出现死锁或资源竞争问题，影响宿主机CPU资源分配稳定性，严重程度为中高]"} + +cve: ./data/2022/48xxx/CVE-2022-48799.json +In the Linux kernel, the following vulnerability has been resolved: + +perf: Fix list corruption in perf_cgroup_switch() + +There's list corruption on cgrp_cpuctx_list. This happens on the +following path: + + perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) + cpu_ctx_sched_in + ctx_sched_in + ctx_pinned_sched_in + merge_sched_in + perf_cgroup_event_disable: remove the event from the list + +Use list_for_each_entry_safe() to allow removing an entry during +iteration. + +analysis: {"Container":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[由于perf_cgroup_switch函数中的列表 corruption 问题，可能导致资源管理异常，从而使容器消耗过多的CPU资源]","CVE_Consequence":"[该CVE可能允许攻击者通过恶意操作引发CPU资源耗尽，影响宿主机和其他容器的稳定性，严重程度为高]"} + +cve: ./data/2022/48xxx/CVE-2022-48944.json +In the Linux kernel, the following vulnerability has been resolved: + +sched: Fix yet more sched_fork() races + +Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an +invalid sched_task_group") fixed a fork race vs cgroup, it opened up a +race vs syscalls by not placing the task on the runqueue before it +gets exposed through the pidhash. + +Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is +trying to fix a single instance of this, instead fix the whole class +of issues, effectively reverting this commit. + +analysis: {"Container":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器中的进程fork操作可能引发调度竞争条件，导致大量进程被创建并占用CPU资源]","CVE_Consequence":"[该CVE可能导致宿主机CPU资源被大量消耗，严重时可能引发宿主机性能下降或拒绝服务，严重程度较高]"} + +cve: ./data/2022/48xxx/CVE-2022-48988.json +In the Linux kernel, the following vulnerability has been resolved: + +memcg: fix possible use-after-free in memcg_write_event_control() + +memcg_write_event_control() accesses the dentry->d_name of the specified +control fd to route the write call. As a cgroup interface file can't be +renamed, it's safe to access d_name as long as the specified file is a +regular cgroup file. Also, as these cgroup interface files can't be +removed before the directory, it's safe to access the parent too. + +Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a +call to __file_cft() which verified that the specified file is a regular +cgroupfs file before further accesses. The cftype pointer returned from +__file_cft() was no longer necessary and the commit inadvertently dropped +the file type check with it allowing any file to slip through. With the +invarients broken, the d_name and parent accesses can now race against +renames and removals of arbitrary files and cause use-after-free's. + +Fix the bug by resurrecting the file type check in __file_cft(). Now that +cgroupfs is implemented through kernfs, checking the file operations needs +to go through a layer of indirection. Instead, let's check the superblock +and dentry type. + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[容器内的漏洞利用可能导致宿主机内存资源被异常消耗，因为use-after-free问题可能引发内存泄漏或无节制的内存分配]"，“CVE_Consequence”：“[该CVE可能导致宿主机内存资源耗尽，严重程度为高，因为它可以被恶意利用来影响整个系统的稳定性]”} + +cve: ./data/2022/49xxx/CVE-2022-49394.json +In the Linux kernel, the following vulnerability has been resolved: + +blk-iolatency: Fix inflight count imbalances and IO hangs on offline + +iolatency needs to track the number of inflight IOs per cgroup. As this +tracking can be expensive, it is disabled when no cgroup has iolatency +configured for the device. To ensure that the inflight counters stay +balanced, iolatency_set_limit() freezes the request_queue while manipulating +the enabled counter, which ensures that no IO is in flight and thus all +counters are zero. + +Unfortunately, iolatency_set_limit() isn't the only place where the enabled +counter is manipulated. iolatency_pd_offline() can also dec the counter and +trigger disabling. As this disabling happens without freezing the q, this +can easily happen while some IOs are in flight and thus leak the counts. + +This can be easily demonstrated by turning on iolatency on an one empty +cgroup while IOs are in flight in other cgroups and then removing the +cgroup. Note that iolatency shouldn't have been enabled elsewhere in the +system to ensure that removing the cgroup disables iolatency for the whole +device. + +The following keeps flipping on and off iolatency on sda: + + echo +io > /sys/fs/cgroup/cgroup.subtree_control + while true; do + mkdir -p /sys/fs/cgroup/test + echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency + sleep 1 + rmdir /sys/fs/cgroup/test + sleep 1 + done + +and there's concurrent fio generating direct rand reads: + + fio --name test --filename=/dev/sda --direct=1 --rw=randread \ + --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k + +while monitoring with the following drgn script: + + while True: + for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): + for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): + blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') + pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] + if pd.value_() == 0: + continue + iolat = container_of(pd, 'struct iolatency_grp', 'pd') + inflight = iolat.rq_wait.inflight.counter.value_() + if inflight: + print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' + f'{cgroup_path(css.cgroup).decode("utf-8")}') + time.sleep(1) + +The monitoring output looks like the following: + + inflight=1 sda /user.slice + inflight=1 sda /user.slice + ... + inflight=14 sda /user.slice + inflight=13 sda /user.slice + inflight=17 sda /user.slice + inflight=15 sda /user.slice + inflight=18 sda /user.slice + inflight=17 sda /user.slice + inflight=20 sda /user.slice + inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 + inflight=19 sda /user.slice + inflight=19 sda /user.slice + +If a cgroup with stuck inflight ends up getting throttled, the throttled IOs +will never get issued as there's no completion event to wake it up leading +to an indefinite hang. + +This patch fixes the bug by unifying enable handling into a work item which +is automatically kicked off from iolatency_set_min_lat_nsec() which is +called from both iolatency_set_limit() and iolatency_pd_offline() paths. +Punting to a work item is necessary as iolatency_pd_offline() is called +under spinlocks while freezing a request_queue requires a sleepable context. + +This also simplifies the code reducing LOC sans the comments and avoids the +unnecessary freezes which were happening whenever a cgroup's latency target +is newly set or cleared. + +analysis: {"Container":"[使用受影响Linux内核版本的任何容器镜像]","CVE_Reason"："[由于inflight计数不平衡，可能导致大量I/O操作被挂起或阻塞，从而间接导致CPU资源被持续占用以尝试处理这些未完成的I/O请求]","CVE_Consequence":"[该CVE可能导致宿主机上的I/O操作出现无限期挂起，影响容器及宿主机性能，严重程度为高]"} + +cve: ./data/2022/49xxx/CVE-2022-49411.json +In the Linux kernel, the following vulnerability has been resolved: + +bfq: Make sure bfqg for which we are queueing requests is online + +Bios queued into BFQ IO scheduler can be associated with a cgroup that +was already offlined. This may then cause insertion of this bfq_group +into a service tree. But this bfq_group will get freed as soon as last +bio associated with it is completed leading to use after free issues for +service tree users. Fix the problem by making sure we always operate on +online bfq_group. If the bfq_group associated with the bio is not +online, we pick the first online parent. + +analysis: {"Container":"[使用BFQ IO调度器的容器]","CVE_Reason":"[容器的运行可能导致与已离线的cgroup关联的BFQ调度组被插入到服务树中，从而引发资源管理问题，可能间接导致宿主机资源消耗异常]","CVE_Consequence":"[该CVE可能导致资源分配错误，严重时可能引发宿主机的IO资源争用或不稳定，严重程度为高]"} + +cve: ./data/2022/49xxx/CVE-2022-49647.json +In the Linux kernel, the following vulnerability has been resolved: + +cgroup: Use separate src/dst nodes when preloading css_sets for migration + +Each cset (css_set) is pinned by its tasks. When we're moving tasks around +across csets for a migration, we need to hold the source and destination +csets to ensure that they don't go away while we're moving tasks about. This +is done by linking cset->mg_preload_node on either the +mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the +same cset->mg_preload_node for both the src and dst lists was deemed okay as +a cset can't be both the source and destination at the same time. + +Unfortunately, this overloading becomes problematic when multiple tasks are +involved in a migration and some of them are identity noop migrations while +others are actually moving across cgroups. For example, this can happen with +the following sequence on cgroup1: + + #1> mkdir -p /sys/fs/cgroup/misc/a/b + #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs + #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & + #4> PID=$! + #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks + #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs + +the process including the group leader back into a. In this final migration, +non-leader threads would be doing identity migration while the group leader +is doing an actual one. + +After #3, let's say the whole process was in cset A, and that after #4, the +leader moves to cset B. Then, during #6, the following happens: + + 1. cgroup_migrate_add_src() is called on B for the leader. + + 2. cgroup_migrate_add_src() is called on A for the other threads. + + 3. cgroup_migrate_prepare_dst() is called. It scans the src list. + + 4. It notices that B wants to migrate to A, so it tries to A to the dst + list but realizes that its ->mg_preload_node is already busy. + + 5. and then it notices A wants to migrate to A as it's an identity + migration, it culls it by list_del_init()'ing its ->mg_preload_node and + putting references accordingly. + + 6. The rest of migration takes place with B on the src list but nothing on + the dst list. + +This means that A isn't held while migration is in progress. If all tasks +leave A before the migration finishes and the incoming task pins it, the +cset will be destroyed leading to use-after-free. + +This is caused by overloading cset->mg_preload_node for both src and dst +preload lists. We wanted to exclude the cset from the src list but ended up +inadvertently excluding it from the dst list too. + +This patch fixes the issue by separating out cset->mg_preload_node into +->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst +preloadings don't interfere with each other. + +analysis: {"Container":"[任何使用cgroup的容器镜像]","CVE_Reason"："[由于cgroup迁移逻辑中的漏洞，可能导致在任务迁移过程中资源管理错误，从而引发宿主机CPU资源被大量占用以处理错误的迁移逻辑和防止use-after-free问题]"，“CVE_Consequence”：“[该CVE可能导致宿主机上的资源管理混乱，严重时可能造成宿主机系统不稳定或崩溃，严重程度为高]”} + +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: {"Container":"Docker容器","CVE_Reason":"低权限攻击者可以将恶意文件复制到现有Docker容器中，导致容器运行时消耗大量宿主机资源，例如CPU或内存","CVE_Consequence":"攻击者可通过执行恶意文件获取root权限，进一步消耗宿主机资源，可能导致系统性能下降或拒绝服务，严重程度高"} + +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: {"Container":"Apptainer","CVE_Reason":"容器的运行可能会利用ext4 use-after-free漏洞，导致宿主机内核受到攻击，可能引发拒绝服务或特权提升，从而消耗更多CPU资源。","CVE_Consequence":"该CVE可能导致宿主机资源被大量占用，严重程度较高，可能引发拒绝服务或特权提升。"} + +cve: ./data/2023/30xxx/CVE-2023-30999.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 an attacker to cause a denial of service due to uncontrolled resource consumption. IBM X-Force ID: 254651. + +analysis: {"Container":"IBM Security Access Manager Container","CVE_Reason":"容器的运行可能会由于未控制的资源消耗导致宿主机CPU或内存资源被大量占用","CVE_Consequence":"该CVE会导致拒绝服务攻击，严重程度较高"} + +cve: ./data/2023/32xxx/CVE-2023-32327.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 an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information or consume memory resources. IBM X-Force ID: 254783. + +analysis: {"Container":"IBM Security Access Manager Container","CVE_Reason":"[容器在处理XML数据时，因XXE攻击可能导致宿主机内存资源被大量消耗]","CVE_Consequence":"[该CVE可能使远程攻击者利用XXE漏洞消耗大量内存资源，导致系统性能下降或服务中断，严重程度为高]"} + +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: {"Container":"Docker Machine","CVE_Reason":"[攻击者可以通过提供恶意版本数据导致 bastion 节点的资源耗尽，例如内存或CPU]","CVE_Consequence":"[该CVE可能导致拒绝服务攻击，严重程度中等]"} + +cve: ./data/2023/47xxx/CVE-2023-47633.json +Traefik is an open source HTTP reverse proxy and load balancer. The traefik docker container uses 100% CPU when it serves as its own backend, which is an automatically generated route resulting from the Docker integration in the default configuration. This issue has been addressed in versions 2.10.6 and 3.0.0-beta5. Users are advised to upgrade. There are no known workarounds for this vulnerability. + +analysis: {"Container":"traefik","CVE_Reason":"容器的运行会导致宿主机CPU资源被大量占用","CVE_Consequence":"该CVE会导致Traefik容器在默认配置下消耗100%的CPU资源，严重程度为高"} + +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: + + 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 + + + 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: {"Container":"[使用cgroup管理资源的容器]","CVE_Reason"："[容器内的线程在压力文件上轮询时，可能导致宿主机CPU资源被大量占用]"，"CVE_Consequence":"[该CVE可能引发use-after-free漏洞，导致系统不稳定或崩溃，严重程度较高]"} + +cve: ./data/2023/52xxx/CVE-2023-52848.json +In the Linux kernel, the following vulnerability has been resolved: + +f2fs: fix to drop meta_inode's page cache in f2fs_put_super() + +syzbot reports a kernel bug as below: + +F2FS-fs (loop1): detect filesystem reference count leak during umount, type: 10, count: 1 +kernel BUG at fs/f2fs/super.c:1639! +CPU: 0 PID: 15451 Comm: syz-executor.1 Not tainted 6.5.0-syzkaller-09338-ge0152e7481c6 #0 +RIP: 0010:f2fs_put_super+0xce1/0xed0 fs/f2fs/super.c:1639 +Call Trace: + generic_shutdown_super+0x161/0x3c0 fs/super.c:693 + kill_block_super+0x3b/0x70 fs/super.c:1646 + kill_f2fs_super+0x2b7/0x3d0 fs/f2fs/super.c:4879 + deactivate_locked_super+0x9a/0x170 fs/super.c:481 + deactivate_super+0xde/0x100 fs/super.c:514 + cleanup_mnt+0x222/0x3d0 fs/namespace.c:1254 + task_work_run+0x14d/0x240 kernel/task_work.c:179 + resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] + exit_to_user_mode_loop kernel/entry/common.c:171 [inline] + exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204 + __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] + syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296 + do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +In f2fs_put_super(), it tries to do sanity check on dirty and IO +reference count of f2fs, once there is any reference count leak, +it will trigger panic. + +The root case is, during f2fs_put_super(), if there is any IO error +in f2fs_wait_on_all_pages(), we missed to truncate meta_inode's page +cache later, result in panic, fix this case. + +analysis: {"Container":"[使用F2FS文件系统的容器镜像]","CVE_Reason"："[容器的运行可能导致宿主机在卸载F2FS文件系统时因引用计数泄漏而触发内核崩溃，同时可能消耗大量CPU资源进行错误处理和日志记录]"，"CVE_Consequence":"[该CVE可能导致宿主机内核崩溃，严重程度高]"} + +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: {"Container":"[任何使用受影响Linux内核版本的容器]","CVE_Reason":"[容器的运行可能会导致宿主机CPU资源分配错误，从而使某些任务无法获得CPU资源]","CVE_Consequence":"[该CVE可能导致宿主机系统崩溃或不可用，严重程度较高]"} + +cve: ./data/2024/0xxx/CVE-2024-0443.json +A flaw was found in the blkgs destruction path in block/blk-cgroup.c in the Linux kernel, leading to a cgroup blkio memory leakage problem. When a cgroup is being destroyed, cgroup_rstat_flush() is only called at css_release_work_fn(), which is called when the blkcg reference count reaches 0. This circular dependency will prevent blkcg and some blkgs from being freed after they are made offline. This issue may allow an attacker with a local access to cause system instability, such as an out of memory error. + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源泄漏，无法正确释放已离线的blkcg和blkgs实例]"，“CVE_Consequence”：“[该CVE可能导致系统内存耗尽，引发宿主机不稳定或崩溃，严重程度高]”} + +cve: ./data/2024/10xxx/CVE-2024-10846.json +The compose-go library component in versions v2.10-v2.4.0 allows an authorized user who sends malicious YAML payloads to cause the compose-go to consume excessive amount of Memory and CPU cycles while parsing YAML, such as used by Docker Compose from versions v2.27.0 to v2.29.7 included + +analysis: {"Container":"Docker Compose","CVE_Reason":"容器的运行会导致宿主机CPU资源和内存资源被大量占用","CVE_Consequence":"该CVE可能导致恶意YAML文件在解析时耗尽宿主机的内存和CPU资源，严重程度为高"} + +cve: ./data/2024/23xxx/CVE-2024-23824.json +mailcow is a dockerized email package, with multiple containers linked in one bridged network. The application is vulnerable to pixel flood attack, once the payload has been successfully uploaded in the logo the application goes slow and doesn't respond in the admin page. It is tested on the versions 2023-12a and prior and patched in version 2024-01. + +analysis: {"Container":"mailcow","CVE_Reason":"容器中的应用程序受到像素洪水攻击影响，导致CPU资源被大量占用","CVE_Consequence":"该CVE会导致宿主机CPU资源耗尽，应用响应缓慢甚至无响应，严重程度为高"} + +cve: ./data/2024/31xxx/CVE-2024-31994.json +Mealie is a self hosted recipe manager and meal planner. Prior to 1.4.0, an attacker can point the image request to an arbitrarily large file. Mealie will attempt to retrieve this file in whole. If it can be retrieved, it may be stored on the file system in whole (leading to possible disk consumption), however the more likely scenario given resource limitations is that the container will OOM during file retrieval if the target file size is greater than the allocated memory of the container. At best this can be used to force the container to infinitely restart due to OOM (if so configured in `docker-compose.yml), or at worst this can be used to force the Mealie container to crash and remain offline. In the event that the file can be retrieved, the lack of rate limiting on this endpoint also permits an attacker to generate ongoing requests to any target of their choice, potentially contributing to an external-facing DoS attack. This vulnerability is fixed in 1.4.0. + +analysis: {"Container":"Mealie","CVE_Reason":"容器的运行可能会导致宿主机的内存资源被大量占用，甚至可能引发硬盘空间资源的消耗","CVE_Consequence":"该CVE可能导致容器因内存不足而崩溃或无限重启，严重程度较高"} + +cve: ./data/2024/35xxx/CVE-2024-35894.json +In the Linux kernel, the following vulnerability has been resolved: + +mptcp: prevent BPF accessing lowat from a subflow socket. + +Alexei reported the following splat: + + WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0 + Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)] + CPU: 32 PID: 3276 Comm: test_progs Tainted: GO 6.8.0-12873-g2c43c33bfd23 + Call Trace: + + mptcp_set_rcvlowat+0x79/0x1d0 + sk_setsockopt+0x6c0/0x1540 + __bpf_setsockopt+0x6f/0x90 + bpf_sock_ops_setsockopt+0x3c/0x90 + bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b + bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132 + bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86 + __cgroup_bpf_run_filter_sock_ops+0xbc/0x250 + tcp_connect+0x879/0x1160 + tcp_v6_connect+0x50c/0x870 + mptcp_connect+0x129/0x280 + __inet_stream_connect+0xce/0x370 + inet_stream_connect+0x36/0x50 + bpf_trampoline_6442491565+0x49/0xef + inet_stream_connect+0x5/0x50 + __sys_connect+0x63/0x90 + __x64_sys_connect+0x14/0x20 + +The root cause of the issue is that bpf allows accessing mptcp-level +proto_ops from a tcp subflow scope. + +Fix the issue detecting the problematic call and preventing any action. + +analysis: {"Container":"[使用Linux内核中mptcp功能的容器镜像]","CVE_Reason"："[容器中的BPF程序可能通过子流socket访问mptcp级别的proto_ops，导致CPU资源被大量占用]"，"CVE_Consequence":"[该CVE可能导致宿主机CPU资源耗尽，严重程度为高]"} + +cve: ./data/2024/35xxx/CVE-2024-35896.json +In the Linux kernel, the following vulnerability has been resolved: + +netfilter: validate user input for expected length + +I got multiple syzbot reports showing old bugs exposed +by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc +in cgroup/{s,g}etsockopt") + +setsockopt() @optlen argument should be taken into account +before copying data. + + BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] + BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] + BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] + BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 +Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238 + +CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 +Call Trace: + + __dump_stack lib/dump_stack.c:88 [inline] + dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 + print_address_description mm/kasan/report.c:377 [inline] + print_report+0x169/0x550 mm/kasan/report.c:488 + kasan_report+0x143/0x180 mm/kasan/report.c:601 + kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 + __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 + copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] + copy_from_sockptr include/linux/sockptr.h:55 [inline] + do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] + do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 + nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 + do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 + __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 + __do_sys_setsockopt net/socket.c:2343 [inline] + __se_sys_setsockopt net/socket.c:2340 [inline] + __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 + do_syscall_64+0xfb/0x240 + entry_SYSCALL_64_after_hwframe+0x72/0x7a +RIP: 0033:0x7fd22067dde9 +Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 +RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 +RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 +RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 +RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 +R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 +R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 + + +Allocated by task 7238: + kasan_save_stack mm/kasan/common.c:47 [inline] + kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 + poison_kmalloc_redzone mm/kasan/common.c:370 [inline] + __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 + kasan_kmalloc include/linux/kasan.h:211 [inline] + __do_kmalloc_node mm/slub.c:4069 [inline] + __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 + kmalloc_noprof include/linux/slab.h:664 [inline] + __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 + do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 + __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 + __do_sys_setsockopt net/socket.c:2343 [inline] + __se_sys_setsockopt net/socket.c:2340 [inline] + __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 + do_syscall_64+0xfb/0x240 + entry_SYSCALL_64_after_hwframe+0x72/0x7a + +The buggy address belongs to the object at ffff88802cd73da0 + which belongs to the cache kmalloc-8 of size 8 +The buggy address is located 0 bytes inside of + allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1) + +The buggy address belongs to the physical page: +page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 +flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) +page_type: 0xffffefff(slab) +raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 +raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 +---truncated--- + +analysis: {"Container":"[使用netfilter功能的容器]","CVE_Reason"："[由于用户输入验证不足，可能导致攻击者通过特定的setsockopt调用消耗大量CPU资源]","CVE_Consequence":"[该漏洞可能允许攻击者触发CPU密集型操作，从而导致宿主机CPU资源耗尽，严重程度为高]"} + +cve: ./data/2024/35xxx/CVE-2024-35974.json +In the Linux kernel, the following vulnerability has been resolved: + +block: fix q->blkg_list corruption during disk rebind + +Multiple gendisk instances can allocated/added for single request queue +in case of disk rebind. blkg may still stay in q->blkg_list when calling +blkcg_init_disk() for rebind, then q->blkg_list becomes corrupted. + +Fix the list corruption issue by: + +- add blkg_init_queue() to initialize q->blkg_list & q->blkcg_mutex only +- move calling blkg_init_queue() into blk_alloc_queue() + +The list corruption should be started since commit f1c006f1c685 ("blk-cgroup: +synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") +which delays removing blkg from q->blkg_list into blkg_free_workfn(). + +analysis: {"Container":"[使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器的运行可能导致宿主机磁盘调度队列管理异常，进而引发CPU资源被大量占用以处理错误的队列状态]"，“CVE_Consequence”：“[该CVE可能导致宿主机的磁盘I/O子系统性能下降，严重时可能引发宿主机整体性能瓶颈或资源耗尽，风险等级为高]”} + +cve: ./data/2024/35xxx/CVE-2024-35976.json +In the Linux kernel, the following vulnerability has been resolved: + +xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING + +syzbot reported an illegal copy in xsk_setsockopt() [1] + +Make sure to validate setsockopt() @optlen parameter. + +[1] + + BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] + BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] + BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 +Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549 + +CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 +Call Trace: + + __dump_stack lib/dump_stack.c:88 [inline] + dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 + print_address_description mm/kasan/report.c:377 [inline] + print_report+0x169/0x550 mm/kasan/report.c:488 + kasan_report+0x143/0x180 mm/kasan/report.c:601 + copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] + copy_from_sockptr include/linux/sockptr.h:55 [inline] + xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 + do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 + __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 + __do_sys_setsockopt net/socket.c:2343 [inline] + __se_sys_setsockopt net/socket.c:2340 [inline] + __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 + do_syscall_64+0xfb/0x240 + entry_SYSCALL_64_after_hwframe+0x6d/0x75 +RIP: 0033:0x7fb40587de69 +Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 +RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 +RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 +RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 +RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 +R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 +R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 + + +Allocated by task 7549: + kasan_save_stack mm/kasan/common.c:47 [inline] + kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 + poison_kmalloc_redzone mm/kasan/common.c:370 [inline] + __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 + kasan_kmalloc include/linux/kasan.h:211 [inline] + __do_kmalloc_node mm/slub.c:3966 [inline] + __kmalloc+0x233/0x4a0 mm/slub.c:3979 + kmalloc include/linux/slab.h:632 [inline] + __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 + do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 + __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 + __do_sys_setsockopt net/socket.c:2343 [inline] + __se_sys_setsockopt net/socket.c:2340 [inline] + __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 + do_syscall_64+0xfb/0x240 + entry_SYSCALL_64_after_hwframe+0x6d/0x75 + +The buggy address belongs to the object at ffff888028c6cde0 + which belongs to the cache kmalloc-8 of size 8 +The buggy address is located 1 bytes to the right of + allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2) + +The buggy address belongs to the physical page: +page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c +anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) +page_type: 0xffffffff() +raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 +raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 +page dumped because: kasan: bad access detected +page_owner tracks the page as allocated +page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 + set_page_owner include/linux/page_owner.h:31 [inline] + post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 + prep_new_page mm/page_alloc.c: +---truncated--- + +analysis: {"Container":"[任何使用Linux内核XDP功能的容器]","CVE_Reason"："[由于未正确验证用户输入，攻击者可能利用此漏洞触发无限循环或大量分配内存，导致CPU资源被大量占用或内存耗尽]","CVE_Consequence":"[该CVE可能导致宿主机CPU和内存资源耗尽，严重程度为高]"} + +cve: ./data/2024/38xxx/CVE-2024-38384.json +In the Linux kernel, the following vulnerability has been resolved: + +blk-cgroup: fix list corruption from reorder of WRITE ->lqueued + +__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start +is being executed. + +If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in +the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one +stat instance being added in blk_cgroup_bio_start(), then the local +list in __blkcg_rstat_flush() could be corrupted. + +Fix the issue by adding one barrier. + +analysis: {"Container":"[使用受影响Linux内核的任何容器]","CVE_Reason"："[容器的运行可能因块设备控制组（blk-cgroup）统计刷新逻辑中的竞态条件，导致宿主机CPU资源被大量占用以处理错误的列表遍历和修复操作]"，"CVE_Consequence":"[该CVE可能导致宿主机上的CPU使用率异常升高，严重程度为中高，具体影响取决于块设备控制组的使用频率]"} + +cve: ./data/2024/38xxx/CVE-2024-38564.json +In the Linux kernel, the following vulnerability has been resolved: + +bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE + +bpf_prog_attach uses attach_type_to_prog_type to enforce proper +attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses +bpf_prog_get and relies on bpf_prog_attach_check_attach_type +to properly verify prog_type <> attach_type association. + +Add missing attach_type enforcement for the link_create case. +Otherwise, it's currently possible to attach cgroup_skb prog +types to other cgroup hooks. + +analysis: {"Container":"[任何使用BPF_PROG_TYPE_CGROUP_SKB的容器镜像]","CVE_Reason":"[容器中的BPF程序可能被错误地附加到其他cgroup钩子，导致CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致恶意或错误配置的容器消耗宿主机过多的CPU资源，严重程度为高]"} + +cve: ./data/2024/38xxx/CVE-2024-38663.json +In the Linux kernel, the following vulnerability has been resolved: + +blk-cgroup: fix list corruption from resetting io stat + +Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), +each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() +can't reset the stat instance by memset(), otherwise the llist may be +corrupted. + +Fix the issue by only resetting the counter part. + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器]","CVE_Reason"："[容器的运行可能会导致宿主机块设备控制组（blk-cgroup）统计信息重置异常，从而间接影响CPU资源调度效率]","CVE_Consequence":"[该CVE可能导致宿主机块设备统计信息列表损坏，进而影响I/O性能和资源分配效率，严重程度为中等]"} + +cve: ./data/2024/3xxx/CVE-2024-3056.json +A flaw was found in Podman. This issue may allow an attacker to create a specially crafted container that, when configured to share the same IPC with at least one other container, can create a large number of IPC resources in /dev/shm. The malicious container will continue to exhaust resources until it is out-of-memory (OOM) killed. While the malicious container's cgroup will be removed, the IPC resources it created are not. Those resources are tied to the IPC namespace that will not be removed until all containers using it are stopped, and one non-malicious container is holding the namespace open. The malicious container is restarted, either automatically or by attacker control, repeating the process and increasing the amount of memory consumed. With a container configured to restart always, such as `podman run --restart=always`, this can result in a memory-based denial of service of the system. + +analysis: ```json +{"Container":"Podman","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"恶意容器通过创建大量IPC资源导致内存消耗不断增加，最终可能引发宿主机的内存耗尽型拒绝服务攻击（DoS），严重程度较高"} +``` + +cve: ./data/2024/40xxx/CVE-2024-40949.json +In the Linux kernel, the following vulnerability has been resolved: + +mm: shmem: fix getting incorrect lruvec when replacing a shmem folio + +When testing shmem swapin, I encountered the warning below on my machine. +The reason is that replacing an old shmem folio with a new one causes +mem_cgroup_migrate() to clear the old folio's memcg data. As a result, +the old folio cannot get the correct memcg's lruvec needed to remove +itself from the LRU list when it is being freed. This could lead to +possible serious problems, such as LRU list crashes due to holding the +wrong LRU lock, and incorrect LRU statistics. + +To fix this issue, we can fallback to use the mem_cgroup_replace_folio() +to replace the old shmem folio. + +[ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960 +[ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 +[ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff) +[ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000 +[ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 +[ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000 +[ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 +[ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000 +[ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000 +[ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) +[ 5241.100338] ------------[ cut here ]------------ +[ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150 +[...] +[ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150 +[ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150 +[ 5241.100376] sp : ffff80008b38b930 +[...] +[ 5241.100398] Call trace: +[ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150 +[ 5241.100401] __page_cache_release+0x90/0x300 +[ 5241.100404] __folio_put+0x50/0x108 +[ 5241.100406] shmem_replace_folio+0x1b4/0x240 +[ 5241.100409] shmem_swapin_folio+0x314/0x528 +[ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930 +[ 5241.100412] shmem_fault+0x74/0x160 +[ 5241.100414] __do_fault+0x40/0x218 +[ 5241.100417] do_shared_fault+0x34/0x1b0 +[ 5241.100419] do_fault+0x40/0x168 +[ 5241.100420] handle_pte_fault+0x80/0x228 +[ 5241.100422] __handle_mm_fault+0x1c4/0x440 +[ 5241.100424] handle_mm_fault+0x60/0x1f0 +[ 5241.100426] do_page_fault+0x120/0x488 +[ 5241.100429] do_translation_fault+0x4c/0x68 +[ 5241.100431] do_mem_abort+0x48/0xa0 +[ 5241.100434] el0_da+0x38/0xc0 +[ 5241.100436] el0t_64_sync_handler+0x68/0xc0 +[ 5241.100437] el0t_64_sync+0x14c/0x150 +[ 5241.100439] ---[ end trace 0000000000000000 ]--- + +[baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew] + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[容器内的内存管理操作可能导致宿主机LRU列表崩溃，进而引发内存资源管理混乱]","CVE_Consequence":"[该CVE可能会导致宿主机内存资源分配错误，严重时可能使宿主机内存资源耗尽，高危]"} + +cve: ./data/2024/42xxx/CVE-2024-42297.json +In the Linux kernel, the following vulnerability has been resolved: + +f2fs: fix to don't dirty inode for readonly filesystem + +syzbot reports f2fs bug as below: + +kernel BUG at fs/f2fs/inode.c:933! +RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 +Call Trace: + evict+0x2a4/0x620 fs/inode.c:664 + dispose_list fs/inode.c:697 [inline] + evict_inodes+0x5f8/0x690 fs/inode.c:747 + generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 + kill_block_super+0x44/0x90 fs/super.c:1667 + kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 + deactivate_locked_super+0xc1/0x130 fs/super.c:484 + cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 + task_work_run+0x24a/0x300 kernel/task_work.c:180 + ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 + ptrace_report_syscall include/linux/ptrace.h:411 [inline] + ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] + syscall_exit_work kernel/entry/common.c:251 [inline] + syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] + __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] + syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 + do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 + entry_SYSCALL_64_after_hwframe+0x63/0x6b + +The root cause is: +- do_sys_open + - f2fs_lookup + - __f2fs_find_entry + - f2fs_i_depth_write + - f2fs_mark_inode_dirty_sync + - f2fs_dirty_inode + - set_inode_flag(inode, FI_DIRTY_INODE) + +- umount + - kill_f2fs_super + - kill_block_super + - generic_shutdown_super + - sync_filesystem + : sb is readonly, skip sync_filesystem() + - evict_inodes + - iput + - f2fs_evict_inode + - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) + : trigger kernel panic + +When we try to repair i_current_depth in readonly filesystem, let's +skip dirty inode to avoid panic in later f2fs_evict_inode(). + +analysis: {"Container":"[使用F2FS文件系统的容器镜像]","CVE_Reason"："[容器在只读F2FS文件系统上运行时，由于内核漏洞可能导致大量inode标记为脏数据，进而引发频繁的同步操作，消耗宿主机CPU资源]","CVE_Consequence":"[该CVE可能引发内核崩溃或系统不稳定，严重程度较高]"} + +cve: ./data/2024/43xxx/CVE-2024-43853.json +In the Linux kernel, the following vulnerability has been resolved: + +cgroup/cpuset: Prevent UAF in proc_cpuset_show() + +An UAF can happen when /proc/cpuset is read as reported in [1]. + +This can be reproduced by the following methods: +1.add an mdelay(1000) before acquiring the cgroup_lock In the + cgroup_path_ns function. +2.$cat /proc//cpuset repeatly. +3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ +$umount /sys/fs/cgroup/cpuset/ repeatly. + +The race that cause this bug can be shown as below: + +(umount) | (cat /proc//cpuset) +css_release | proc_cpuset_show +css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); +css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); +cgroup_destroy_root | mutex_lock(&cgroup_mutex); +rebind_subsystems | +cgroup_free_root | + | // cgrp was freed, UAF + | cgroup_path_ns_locked(cgrp,..); + +When the cpuset is initialized, the root node top_cpuset.css.cgrp +will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will +allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated +&cgroup_root.cgrp. When the umount operation is executed, +top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp. + +The problem is that when rebinding to cgrp_dfl_root, there are cases +where the cgroup_root allocated by setting up the root for cgroup v1 +is cached. This could lead to a Use-After-Free (UAF) if it is +subsequently freed. The descendant cgroups of cgroup v1 can only be +freed after the css is released. However, the css of the root will never +be released, yet the cgroup_root should be freed when it is unmounted. +This means that obtaining a reference to the css of the root does +not guarantee that css.cgrp->root will not be freed. + +Fix this problem by using rcu_read_lock in proc_cpuset_show(). +As cgroup_root is kfree_rcu after commit d23b5c577715 +("cgroup: Make operations on the cgroup root_list RCU safe"), +css->cgroup won't be freed during the critical section. +To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to +replace task_get_css with task_css. + +[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd + +analysis: {"Container":"[使用cpuset控制组的Linux容器]","CVE_Reason"："[容器的运行可能导致宿主机CPU资源被大量占用，因为Use-After-Free漏洞可能引发竞争条件，导致系统不稳定并消耗额外计算资源]"，"CVE_Consequence":"[该CVE可能导致宿主机上的容器管理功能异常，严重时可导致系统崩溃或需要重启。严重程度：高]"} + +cve: ./data/2024/43xxx/CVE-2024-43892.json +In the Linux kernel, the following vulnerability has been resolved: + +memcg: protect concurrent access to mem_cgroup_idr + +Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after +many small jobs") decoupled the memcg IDs from the CSS ID space to fix the +cgroup creation failures. It introduced IDR to maintain the memcg ID +space. The IDR depends on external synchronization mechanisms for +modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() +happen within css callback and thus are protected through cgroup_mutex +from concurrent modifications. However idr_remove() for mem_cgroup_idr +was not protected against concurrency and can be run concurrently for +different memcgs when they hit their refcnt to zero. Fix that. + +We have been seeing list_lru based kernel crashes at a low frequency in +our fleet for a long time. These crashes were in different part of +list_lru code including list_lru_add(), list_lru_del() and reparenting +code. Upon further inspection, it looked like for a given object (dentry +and inode), the super_block's list_lru didn't have list_lru_one for the +memcg of that object. The initial suspicions were either the object is +not allocated through kmem_cache_alloc_lru() or somehow +memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but +returned success. No evidence were found for these cases. + +Looking more deeply, we started seeing situations where valid memcg's id +is not present in mem_cgroup_idr and in some cases multiple valid memcgs +have same id and mem_cgroup_idr is pointing to one of them. So, the most +reasonable explanation is that these situations can happen due to race +between multiple idr_remove() calls or race between +idr_alloc()/idr_replace() and idr_remove(). These races are causing +multiple memcgs to acquire the same ID and then offlining of one of them +would cleanup list_lrus on the system for all of them. Later access from +other memcgs to the list_lru cause crashes due to missing list_lru_one. + +analysis: {"Container":"[使用受影响Linux内核的任何容器镜像]","CVE_Reason":"[容器中的并发访问问题可能导致内存资源分配错误，进而引发系统不稳定和资源消耗异常]","CVE_Consequence":"[该CVE可能导致宿主机上的容器内存管理出现竞争条件，从而引发内核崩溃或资源清理错误。严重程度为高，因为可能影响整个宿主机的稳定性]"} + +cve: ./data/2024/49xxx/CVE-2024-49974.json +In the Linux kernel, the following vulnerability has been resolved: + +NFSD: Limit the number of concurrent async COPY operations + +Nothing appears to limit the number of concurrent async COPY +operations that clients can start. In addition, AFAICT each async +COPY can copy an unlimited number of 4MB chunks, so can run for a +long time. Thus IMO async COPY can become a DoS vector. + +Add a restriction mechanism that bounds the number of concurrent +background COPY operations. Start simple and try to be fair -- this +patch implements a per-namespace limit. + +An async COPY request that occurs while this limit is exceeded gets +NFS4ERR_DELAY. The requesting client can choose to send the request +again after a delay or fall back to a traditional read/write style +copy. + +If there is need to make the mechanism more sophisticated, we can +visit that in future patches. + +analysis: {"Container":"[使用Linux内核NFS服务的容器镜像]","CVE_Reason"："[容器中的NFS客户端可以通过大量并发异步COPY操作，导致宿主机CPU和内存资源被过度消耗]","CVE_Consequence":"[该CVE可能导致拒绝服务攻击，严重程度为高]"} + +cve: ./data/2024/50xxx/CVE-2024-50130.json +In the Linux kernel, the following vulnerability has been resolved: + +netfilter: bpf: must hold reference on net namespace + +BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0 +Read of size 8 at addr ffff8880106fe400 by task repro/72= +bpf_nf_link_release+0xda/0x1e0 +bpf_link_free+0x139/0x2d0 +bpf_link_release+0x68/0x80 +__fput+0x414/0xb60 + +Eric says: + It seems that bpf was able to defer the __nf_unregister_net_hook() + after exit()/close() time. + Perhaps a netns reference is missing, because the netns has been + dismantled/freed already. + bpf_nf_link_attach() does : + link->net = net; + But I do not see a reference being taken on net. + +Add such a reference and release it after hook unreg. +Note that I was unable to get syzbot reproducer to work, so I +do not know if this resolves this splat. + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[由于netfilter的BPF程序未正确持有网络命名空间的引用，可能导致use-after-free问题，从而引发宿主机内核不稳定或崩溃，同时可能间接导致资源消耗异常]"，"CVE_Consequence":"[该CVE可能导致内核内存损坏，进而造成系统崩溃或性能下降，严重程度较高]"} + +cve: ./data/2024/53xxx/CVE-2024-53168.json +In the Linux kernel, the following vulnerability has been resolved: + +sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket + +BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0 +Read of size 1 at addr ffff888111f322cd by task swapper/0/0 + +CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 +Call Trace: + + dump_stack_lvl+0x68/0xa0 + print_address_description.constprop.0+0x2c/0x3d0 + print_report+0xb4/0x270 + kasan_report+0xbd/0xf0 + tcp_write_timer_handler+0x156/0x3e0 + tcp_write_timer+0x66/0x170 + call_timer_fn+0xfb/0x1d0 + __run_timers+0x3f8/0x480 + run_timer_softirq+0x9b/0x100 + handle_softirqs+0x153/0x390 + __irq_exit_rcu+0x103/0x120 + irq_exit_rcu+0xe/0x20 + sysvec_apic_timer_interrupt+0x76/0x90 + + + asm_sysvec_apic_timer_interrupt+0x1a/0x20 +RIP: 0010:default_idle+0xf/0x20 +Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 + 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc + cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 +RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 +RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 +RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f +RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d +R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 +R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 + default_idle_call+0x6b/0xa0 + cpuidle_idle_call+0x1af/0x1f0 + do_idle+0xbc/0x130 + cpu_startup_entry+0x33/0x40 + rest_init+0x11f/0x210 + start_kernel+0x39a/0x420 + x86_64_start_reservations+0x18/0x30 + x86_64_start_kernel+0x97/0xa0 + common_startup_64+0x13e/0x141 + + +Allocated by task 595: + kasan_save_stack+0x24/0x50 + kasan_save_track+0x14/0x30 + __kasan_slab_alloc+0x87/0x90 + kmem_cache_alloc_noprof+0x12b/0x3f0 + copy_net_ns+0x94/0x380 + create_new_namespaces+0x24c/0x500 + unshare_nsproxy_namespaces+0x75/0xf0 + ksys_unshare+0x24e/0x4f0 + __x64_sys_unshare+0x1f/0x30 + do_syscall_64+0x70/0x180 + entry_SYSCALL_64_after_hwframe+0x76/0x7e + +Freed by task 100: + kasan_save_stack+0x24/0x50 + kasan_save_track+0x14/0x30 + kasan_save_free_info+0x3b/0x60 + __kasan_slab_free+0x54/0x70 + kmem_cache_free+0x156/0x5d0 + cleanup_net+0x5d3/0x670 + process_one_work+0x776/0xa90 + worker_thread+0x2e2/0x560 + kthread+0x1a8/0x1f0 + ret_from_fork+0x34/0x60 + ret_from_fork_asm+0x1a/0x30 + +Reproduction script: + +mkdir -p /mnt/nfsshare +mkdir -p /mnt/nfs/netns_1 +mkfs.ext4 /dev/sdb +mount /dev/sdb /mnt/nfsshare +systemctl restart nfs-server +chmod 777 /mnt/nfsshare +exportfs -i -o rw,no_root_squash *:/mnt/nfsshare + +ip netns add netns_1 +ip link add name veth_1_peer type veth peer veth_1 +ifconfig veth_1_peer 11.11.0.254 up +ip link set veth_1 netns netns_1 +ip netns exec netns_1 ifconfig veth_1 11.11.0.1 + +ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ + --tcp-flags FIN FIN -j DROP + +(note: In my environment, a DESTROY_CLIENTID operation is always sent + immediately, breaking the nfs tcp connection.) +ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ + 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1 + +ip netns del netns_1 + +The reason here is that the tcp socket in netns_1 (nfs side) has been +shutdown and closed (done in xs_destroy), but the FIN message (with ack) +is discarded, and the nfsd side keeps sending retransmission messages. +As a result, when the tcp sock in netns_1 processes the received message, +it sends the message (FIN message) in the sending queue, and the tcp timer +is re-established. When the network namespace is deleted, the net structure +accessed by tcp's timer handler function causes problems. + +To fix this problem, let's hold netns refcnt for the tcp kernel socket as +done in other modules. This is an ugly hack which can easily be backported +to earlier kernels. A proper fix which cleans up the interfaces will +follow, but may not be so easy to backport. + +analysis: {"Container":"[使用NFS挂载的容器]","CVE_Reason":"[容器内的NFS客户端操作可能导致宿主机TCP资源泄漏，进而导致CPU资源被大量占用]","CVE_Consequence":"[该CVE可能造成宿主机网络命名空间删除时出现资源访问问题，导致CPU使用率异常升高，严重程度为高]"} + +cve: ./data/2024/53xxx/CVE-2024-53175.json +In the Linux kernel, the following vulnerability has been resolved: + +ipc: fix memleak if msg_init_ns failed in create_ipc_ns + +Percpu memory allocation may failed during create_ipc_ns however this +fail is not handled properly since ipc sysctls and mq sysctls is not +released properly. Fix this by release these two resource when failure. + +Here is the kmemleak stack when percpu failed: + +unreferenced object 0xffff88819de2a600 (size 512): + comm "shmem_2nstest", pid 120711, jiffies 4300542254 + hex dump (first 32 bytes): + 60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff `.........H..... + 04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff ........ .V..... + backtrace (crc be7cba35): + [] __kmalloc_node_track_caller_noprof+0x333/0x420 + [] kmemdup_noprof+0x26/0x50 + [] setup_mq_sysctls+0x57/0x1d0 + [] copy_ipcs+0x29c/0x3b0 + [] create_new_namespaces+0x1d0/0x920 + [] copy_namespaces+0x2e9/0x3e0 + [] copy_process+0x29f3/0x7ff0 + [] kernel_clone+0xc0/0x650 + [] __do_sys_clone+0xa1/0xe0 + [] do_syscall_64+0xbf/0x1c0 + [] entry_SYSCALL_64_after_hwframe+0x4b/0x53 + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[由于ipc命名空间创建时的内存泄漏问题，可能导致容器运行时消耗过多内存资源]","CVE_Consequence":"[该CVE可能会导致宿主机内存资源被逐渐耗尽，严重程度为高]"} + +cve: ./data/2024/56xxx/CVE-2024-56644.json +In the Linux kernel, the following vulnerability has been resolved: + +net/ipv6: release expired exception dst cached in socket + +Dst objects get leaked in ip6_negative_advice() when this function is +executed for an expired IPv6 route located in the exception table. There +are several conditions that must be fulfilled for the leak to occur: +* an ICMPv6 packet indicating a change of the MTU for the path is received, + resulting in an exception dst being created +* a TCP connection that uses the exception dst for routing packets must + start timing out so that TCP begins retransmissions +* after the exception dst expires, the FIB6 garbage collector must not run + before TCP executes ip6_negative_advice() for the expired exception dst + +When TCP executes ip6_negative_advice() for an exception dst that has +expired and if no other socket holds a reference to the exception dst, the +refcount of the exception dst is 2, which corresponds to the increment +made by dst_init() and the increment made by the TCP socket for which the +connection is timing out. The refcount made by the socket is never +released. The refcount of the dst is decremented in sk_dst_reset() but +that decrement is counteracted by a dst_hold() intentionally placed just +before the sk_dst_reset() in ip6_negative_advice(). After +ip6_negative_advice() has finished, there is no other object tied to the +dst. The socket lost its reference stored in sk_dst_cache and the dst is +no longer in the exception table. The exception dst becomes a leaked +object. + +As a result of this dst leak, an unbalanced refcount is reported for the +loopback device of a net namespace being destroyed under kernels that do +not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"): +unregister_netdevice: waiting for lo to become free. Usage count = 2 + +Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The +patch that introduced the dst_hold() in ip6_negative_advice() was +92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22 +merely refactored the code with regards to the dst refcount so the issue +was present even before 92f1655aa2b22. The bug was introduced in +54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually +expired.") where the expired cached route is deleted and the sk_dst_cache +member of the socket is set to NULL by calling dst_negative_advice() but +the refcount belonging to the socket is left unbalanced. + +The IPv4 version - ipv4_negative_advice() - is not affected by this bug. +When the TCP connection times out ipv4_negative_advice() merely resets the +sk_dst_cache of the socket while decrementing the refcount of the +exception dst. + +analysis: {"Container":"[任何使用受影响Linux内核版本的容器镜像]","CVE_Reason":"[容器中的IPv6路由异常处理会导致宿主机内存资源泄漏，因为dst对象引用计数未正确释放]","CVE_Consequence":"[该CVE会导致宿主机内存资源逐渐耗尽，严重程度为高]"} + +cve: ./data/2024/57xxx/CVE-2024-57977.json +In the Linux kernel, the following vulnerability has been resolved: + +memcg: fix soft lockup in the OOM process + +A soft lockup issue was found in the product with about 56,000 tasks were +in the OOM cgroup, it was traversing them when the soft lockup was +triggered. + +watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] +CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G +Hardware name: Huawei Cloud OpenStack Nova, BIOS +RIP: 0010:console_unlock+0x343/0x540 +RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 +RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff +RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 +RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 +R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 +R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + vprintk_emit+0x193/0x280 + printk+0x52/0x6e + dump_task+0x114/0x130 + mem_cgroup_scan_tasks+0x76/0x100 + dump_header+0x1fe/0x210 + oom_kill_process+0xd1/0x100 + out_of_memory+0x125/0x570 + mem_cgroup_out_of_memory+0xb5/0xd0 + try_charge+0x720/0x770 + mem_cgroup_try_charge+0x86/0x180 + mem_cgroup_try_charge_delay+0x1c/0x40 + do_anonymous_page+0xb5/0x390 + handle_mm_fault+0xc4/0x1f0 + +This is because thousands of processes are in the OOM cgroup, it takes a +long time to traverse all of them. As a result, this lead to soft lockup +in the OOM process. + +To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' +function per 1000 iterations. For global OOM, call +'touch_softlockup_watchdog' per 1000 iterations to avoid this issue. + +analysis: {"Container":"[任何使用Linux内核并启用memcg的容器镜像]","CVE_Reason"："[容器中的大量进程处于OOM cgroup时，扫描这些进程可能导致CPU软锁定，从而大量消耗CPU资源]","CVE_Consequence":"[该CVE可能导致宿主机CPU资源被长时间占用，严重情况下影响宿主机上其他任务的正常运行，严重程度为高]"} + +cve: ./data/2024/5xxx/CVE-2024-5652.json +In Docker Desktop on Windows before v4.31.0 allows a user in the docker-users group to cause a Windows Denial-of-Service through the exec-path Docker daemon config option in Windows containers mode. + +analysis: {"Container":"Docker Desktop Windows容器","CVE_Reason":"通过在Windows容器模式下使用exec-path Docker守护程序配置选项，攻击者可触发Windows服务拒绝（Denial-of-Service），可能导致宿主机资源耗尽","CVE_Consequence":"该CVE可能造成宿主机上的Docker服务不可用，同时大量消耗CPU或内存资源，严重程度较高"} + +cve: ./data/2024/7xxx/CVE-2024-7771.json +A vulnerability in the Dockerized version of mintplex-labs/anything-llm (latest, digest 1d9452da2b92) allows for a denial of service. Uploading an audio file with a very low sample rate causes the functionality responsible for transcribing it to crash the entire site instance. The issue arises from the localWhisper implementation, where resampling the audio file from 1 Hz to 16000 Hz quickly exceeds available memory, leading to the Docker instance being killed by the instance manager. + +analysis: {"Container":"mintplex-labs/anything-llm","CVE_Reason":"容器在处理低采样率音频文件时，由于需要将其从1 Hz重采样到16000 Hz，导致内存资源被大量消耗，最终超过可用内存限制。","CVE_Consequence":"该CVE会导致容器因内存不足而被宿主机的实例管理器杀死，严重程度较高，可能引发服务中断。"} + +cve: ./data/2024/9xxx/CVE-2024-9407.json +A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files. + +analysis: {"Container":"[使用Dockerfile构建的容器镜像]","CVE_Reason"："[攻击者可以通过此漏洞将宿主机的敏感目录挂载到容器中，并可能修改这些文件，从而导致容器消耗更多宿主机的物理资源，例如硬盘空间资源]","CVE_Consequence":"[该CVE可能导致宿主机文件被非法访问和修改，严重程度为高]"} + +cve: ./data/2024/9xxx/CVE-2024-9676.json +A vulnerability was found in Podman, Buildah, and CRI-O. A symlink traversal vulnerability in the containers/storage library can cause Podman, Buildah, and CRI-O to hang and result in a denial of service via OOM kill when running a malicious image using an automatically assigned user namespace (`--userns=auto` in Podman and Buildah). The containers/storage library will read /etc/passwd inside the container, but does not properly validate if that file is a symlink, which can be used to cause the library to read an arbitrary file on the host. + +analysis: {"Container":"Podman, Buildah, CRI-O","CVE_Reason":"恶意容器镜像利用符号链接遍历漏洞，可能导致宿主机内存资源被大量消耗，最终触发OOM（Out of Memory）Kill。","CVE_Consequence":"该CVE会导致拒绝服务攻击，严重程度较高。"} + +cve: ./data/2025/21xxx/CVE-2025-21745.json +In the Linux kernel, the following vulnerability has been resolved: + +blk-cgroup: Fix class @block_class's subsystem refcount leakage + +blkcg_fill_root_iostats() iterates over @block_class's devices by +class_dev_iter_(init|next)(), but does not end iterating with +class_dev_iter_exit(), so causes the class's subsystem refcount leakage. + +Fix by ending the iterating with class_dev_iter_exit(). + +analysis: {"Container":"[使用受影响Linux内核的任何容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源泄漏，因为子系统引用计数没有正确释放]","CVE_Consequence":"[该CVE可能导致宿主机内存资源逐渐耗尽，严重程度为高]"} + +cve: ./data/2025/21xxx/CVE-2025-21860.json +In the Linux kernel, the following vulnerability has been resolved: + +mm/zswap: fix inconsistency when zswap_store_page() fails + +Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()") +skips charging any zswap entries when it failed to zswap the entire folio. + +However, when some base pages are zswapped but it failed to zswap the +entire folio, the zswap operation is rolled back. When freeing zswap +entries for those pages, zswap_entry_free() uncharges the zswap entries +that were not previously charged, causing zswap charging to become +inconsistent. + +This inconsistency triggers two warnings with following steps: + # On a machine with 64GiB of RAM and 36GiB of zswap + $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng + $ sudo reboot + + The two warnings are: + in mm/memcontrol.c:163, function obj_cgroup_release(): + WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); + + in mm/page_counter.c:60, function page_counter_cancel(): + if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", + new, nr_pages)) + +zswap_stored_pages also becomes inconsistent in the same way. + +As suggested by Kanchana, increment zswap_stored_pages and charge zswap +entries within zswap_store_page() when it succeeds. This way, +zswap_entry_free() will decrement the counter and uncharge the entries +when it failed to zswap the entire folio. + +While this could potentially be optimized by batching objcg charging and +incrementing the counter, let's focus on fixing the bug this time and +leave the optimization for later after some evaluation. + +After resolving the inconsistency, the warnings disappear. + +[42.hyeyoo@gmail.com: refactor zswap_store_page()] + +analysis: {"Container":"[任何使用Linux内核并启用zswap功能的容器]","CVE_Reason":"[容器中的应用程序如果触发大量内存交换操作，可能导致zswap功能异常，进而引发宿主机内存资源计算不一致，可能间接导致更多内存资源被占用]","CVE_Consequence":"[该CVE可能导致宿主机内存资源管理出现错误，严重时可能引发内存资源过度消耗或系统不稳定，严重程度为中高]"} diff --git a/DoS_result/pure_from_description_11-25.log b/DoS_result/pure_from_description_11-25.log new file mode 100644 index 0000000..445e8e7 --- /dev/null +++ b/DoS_result/pure_from_description_11-25.log @@ -0,0 +1,75 @@ +cve: ./data/2011/2xxx/CVE-2011-2189.json +net/core/net_namespace.c in the Linux kernel 2.6.32 and earlier does not properly handle a high rate of creation and cleanup of network namespaces, which makes it easier for remote attackers to cause a denial of service (memory consumption) via requests to a daemon that requires a separate namespace per connection, as demonstrated by vsftpd. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用]"，"CVE_Consequence":"[该CVE可能导致拒绝服务攻击，严重程度较高]"} + +cve: ./data/2012/2xxx/CVE-2012-2127.json +fs/proc/root.c in the procfs implementation in the Linux kernel before 3.2 does not properly interact with CLONE_NEWPID clone system calls, which allows remote attackers to cause a denial of service (reference leak and memory consumption) by making many connections to a daemon that uses PID namespaces to isolate clients, as demonstrated by vsftpd. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用]"，"CVE_Consequence":"[该CVE可能导致内存消耗过大，进而引发拒绝服务攻击，严重程度较高]"} + +cve: ./data/2013/4xxx/CVE-2013-4205.json +Memory leak in the unshare_userns function in kernel/user_namespace.c in the Linux kernel before 3.10.6 allows local users to cause a denial of service (memory consumption) via an invalid CLONE_NEWUSER unshare call. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用]","CVE_Consequence":"[该CVE可能导致内存泄漏，进而造成拒绝服务攻击，严重程度较高]"} + +cve: ./data/2014/5xxx/CVE-2014-5207.json +fs/namespace.c in the Linux kernel through 3.16.1 does not properly restrict clearing MNT_NODEV, MNT_NOSUID, and MNT_NOEXEC and changing MNT_ATIME_MASK during a remount of a bind mount, which allows local users to gain privileges, interfere with backups and auditing on systems that had atime enabled, or cause a denial of service (excessive filesystem updating) on systems that had atime disabled via a "mount -o remount" command within a user namespace. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行可能会导致宿主机文件系统更新操作过多，从而消耗大量CPU或硬盘资源]","CVE_Consequence":"[该CVE可能导致本地用户通过特定命令引发拒绝服务攻击，严重程度较高]"} + +cve: ./data/2014/8xxx/CVE-2014-8171.json +The memory resource controller (aka memcg) in the Linux kernel allows local users to cause a denial of service (deadlock) by spawning new processes within a memory-constrained cgroup. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致拒绝服务（死锁），严重程度较高"} + +cve: ./data/2016/6xxx/CVE-2016-6213.json +fs/namespace.c in the Linux kernel before 4.9 does not restrict how many mounts may exist in a mount namespace, which allows local users to cause a denial of service (memory consumption and deadlock) via MS_BIND mount system calls, as demonstrated by a loop that triggers exponential growth in the number of mounts. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用，并可能引发死锁]"，"CVE_Consequence":"[该CVE可能导致宿主机内存耗尽及系统死锁，严重程度高]"} + +cve: ./data/2016/8xxx/CVE-2016-8579.json +docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain. + +analysis: {"Container":"docker2aci","CVE_Reason":"容器的运行会导致宿主机CPU资源被大量占用","CVE_Consequence":"该CVE可能导致系统性能下降，严重程度为高"} + +cve: ./data/2016/9xxx/CVE-2016-9191.json +The cgroup offline implementation in the Linux kernel through 4.8.11 mishandles certain drain operations, which allows local users to cause a denial of service (system hang) by leveraging access to a container environment for executing a crafted application, as demonstrated by trinity. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机系统挂起，可能是由于CPU或其它资源被大量占用]","CVE_Consequence":"[该CVE可能导致系统拒绝服务（系统挂起），严重程度较高]"} + +cve: ./data/2017/11xxx/CVE-2017-11468.json +Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint. + +analysis: {"Container":"Docker Registry","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致远程攻击者通过manifest endpoint造成拒绝服务，严重程度较高"} + +cve: ./data/2017/14xxx/CVE-2017-14179.json +Apport before 2.13 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion, possibly gain root privileges, or escape from containers. + +analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机资源被大量占用，具体为资源耗尽问题]","CVE_Consequence":"[该CVE可能导致拒绝服务攻击，资源耗尽，甚至获得root权限或逃逸容器，严重程度较高]"} + +cve: ./data/2017/14xxx/CVE-2017-14180.json +Apport 2.13 through 2.20.7 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion or possibly gain root privileges, a different vulnerability than CVE-2017-14179. + +analysis: {"Container":"Apport","CVE_Reason":"容器的运行会导致宿主机内存资源或CPU资源被大量占用，造成资源耗尽问题","CVE_Consequence":"该CVE可能导致拒绝服务攻击，严重程度较高，还可能带来提权风险"} + +cve: ./data/2017/14xxx/CVE-2017-14992.json +Lack of content verification in Docker-CE (Also known as Moby) versions 1.12.6-0, 1.10.3, 17.03.0, 17.03.1, 17.03.2, 17.06.0, 17.06.1, 17.06.2, 17.09.0, and earlier allows a remote attacker to cause a Denial of Service via a crafted image layer payload, aka gzip bombing. + +analysis: {"Container":"Docker-CE (Moby)","CVE_Reason":"容器的运行会导致宿主机CPU资源和内存资源被大量占用","CVE_Consequence":"该CVE可能导致拒绝服务（DoS），严重程度较高"} + +cve: ./data/2018/10xxx/CVE-2018-10205.json +hyperstart 1.0.0 in HyperHQ Hyper has memory leaks in the container_setup_modules and hyper_rescan_scsi functions in container.c, related to runV 1.0.0 for Docker. + +analysis: {"Container":"hyperstart 1.0.0","CVE_Reason":"容器的运行会导致宿主机内存资源被泄漏","CVE_Consequence":"内存泄漏会逐渐消耗宿主机的内存资源，可能导致系统性能下降或崩溃，严重程度较高"} + +cve: ./data/2018/1xxx/CVE-2018-1277.json +Cloud Foundry Garden-runC, versions prior to 1.13.0, does not correctly enforce disc quotas for Docker image layers. A remote authenticated user may push an app with a malicious Docker image that will consume more space on a Diego cell than allocated in their quota, potentially causing a DoS against the cell. + +analysis: {"Container":"Cloud Foundry Garden-runC","CVE_Reason":"容器的运行会导致宿主机硬盘空间资源被大量占用","CVE_Consequence":"恶意Docker镜像会消耗超出配额的磁盘空间，可能导致Diego cell拒绝服务（DoS），严重程度较高"} + +cve: ./data/2018/20xxx/CVE-2018-20699.json +Docker Engine before 18.09 allows attackers to cause a denial of service (dockerd memory consumption) via a large integer in a --cpuset-mems or --cpuset-cpus value, related to daemon/daemon_unix.go, pkg/parsers/parsers.go, and pkg/sysinfo/sysinfo.go. + +analysis: {"Container":"Docker Engine","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致宿主机内存消耗过多，从而引发拒绝服务攻击，严重程度较高"} + diff --git a/Image_ai_analysis.py b/Image_ai_analysis.py new file mode 100644 index 0000000..dbbc90c --- /dev/null +++ b/Image_ai_analysis.py @@ -0,0 +1,84 @@ +# 分析每个CVE源自哪个应用程序、什么原因、什么后果等信息 + +from os import truncate +import re +import json +from openai import OpenAI +from typing import Dict, List, Any + + +def process_result(data: Any) -> str: + # target_key = "choices.0.message.content" + parts = ["choices", "0", "message", "content"] + try: + for part in parts: + if isinstance(data, list): + data = data[int(part)] + else: + data = data.get(part, None) + if data is None: + break + return data + except (KeyError, IndexError, TypeError): + return "N/A" + return "N/A" + + +def analyze_with_ai(data: str) -> str: + prompt = """ + 你是一个计算机容器安全领域的专家，能够根据CVE描述分析出CVE产生于哪个程序、有何影响后果等信息。 + 下面用户会发给你一段文本，第一行是CVE的编号与文件位置信息，后续是这个CVE的详细描述。 + 请分析用户发送给你的CVE详细描述内容，并进行分析，有如下要求： + 1. 分析这个CVE信息，判断这个CVE漏洞是否是容器镜像而引入的问题，而非Docker实现、Kernel实现中的问题。比如由于容器镜像创建中对文件或环境变量处理不当而引入的CVE就是用户感兴趣的； + 2. 如果不满足条件1，你只需返回"N/A"即可，无需任何任何多余信息； + 3. 如果这个CVE满足条件1，那么你只需要直接返回一个json，这个json样例如下： + {"Image":"[引入CVE的容器镜像名称]","Reason"："[容器的运行会导致宿主机CPU资源被大量占用]"，"Consequence":"[该CVE的后果，以及严重程度]"} + 请牢记，不要自行推测，只分析这个描述中是否提及。 + """ + + client = OpenAI( + api_key="sk-5ec7751941974a9cb5855f746fe45a62", + base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", + ) + try: + completion = client.chat.completions.create( + # 模型列表：https://help.aliyun.com/zh/model-studio/getting-started/models + model="qwen-plus", + messages=[ + {"role": "system", "content": prompt}, + {"role": "user", "content": data}, + ], + # Qwen3模型通过enable_thinking参数控制思考过程（开源版默认True，商业版默认False） + # 使用Qwen3开源版模型时，若未启用流式输出，请将下行取消注释，否则会报错 + # extra_body={"enable_thinking": False}, + ) + return process_result(json.loads(completion.model_dump_json())) + except Exception as e: + print(f"调用大模型失败: {str(e)}") + return "N/A" + return "N/A" + + +if __name__ == "__main__": + pattern = r"\./data/.*x/CVE.*?\.json" + regex = re.compile(pattern) + + with open("keyword_filter_11-25.log", "r", encoding="utf-8") as file: + text = file.read() + matches = list(regex.finditer(text)) + + log = open("./Image_result/result_11-25.log", "w", encoding="utf-8") + + # 如果没有找到任何匹配项 + if not matches: + print("No match found.") + else: + for i in range(len(matches)): + start = matches[i].start() + # 如果不是最后一个匹配项，则end是下一个匹配项的起始位置；否则为文本末尾 + end = matches[i + 1].start() if i + 1 < len(matches) else len(text) + block = text[start:end].strip() + ans = analyze_with_ai(block) + if ans == "N/A": + continue + log.write(f"cve: {block}\n\nanalysis: {ans}\n\n") diff --git a/Image_result/result_11-25.log b/Image_result/result_11-25.log new file mode 100644 index 0000000..147d31d --- /dev/null +++ b/Image_result/result_11-25.log @@ -0,0 +1,708 @@ +cve: ./data/2014/0xxx/CVE-2014-0048.json +An issue was found in Docker before 1.6.0. Some programs and scripts in Docker are downloaded via HTTP and then executed or used in unsafe ways. + +analysis: {"Image":"docker","Reason":"容器镜像通过HTTP下载并执行程序或脚本的方式存在安全隐患","Consequence":"攻击者可利用中间人攻击篡改下载内容，导致代码执行或安全机制失效，严重程度高"} + +cve: ./data/2014/5xxx/CVE-2014-5282.json +Docker before 1.3 does not properly validate image IDs, which allows remote attackers to redirect to another image through the loading of untrusted images via 'docker load'. + +analysis: {"Image":"Docker","Reason":"CVE is related to Docker's image ID validation issue when loading images","Consequence":"Remote attackers can redirect the loading process to another untrusted image, leading to potential security risks. Severity: Medium to High"} + +cve: ./data/2014/6xxx/CVE-2014-6407.json +Docker before 1.3.2 allows remote attackers to write to arbitrary files and execute arbitrary code via a (1) symlink or (2) hard link attack in an image archive in a (a) pull or (b) load operation. + +analysis: {"Image":"Docker","Reason":"漏洞是由于Docker在处理镜像归档文件时对符号链接或硬链接的不安全解压方式导致的","Consequence":"攻击者可以利用该漏洞在宿主机上写入任意文件并执行任意代码，严重影响容器环境的安全性"} + +cve: ./data/2014/8xxx/CVE-2014-8178.json +Docker Engine before 1.8.3 and CS Docker Engine before 1.6.2-CS7 do not use a globally unique identifier to store image layers, which makes it easier for attackers to poison the image cache via a crafted image in pull or push commands. + +analysis: {"Image":"Docker Engine","Reason":"The vulnerability arises from the image layer storage mechanism in the Docker Engine, which does not use a globally unique identifier, allowing attackers to manipulate the image cache.","Consequence":"Attackers can exploit this vulnerability to poison the image cache during pull or push operations, potentially leading to system compromise or distribution of malicious images. This issue poses a moderate to high risk depending on the environment and usage."} + +cve: ./data/2014/9xxx/CVE-2014-9356.json +Path traversal vulnerability in Docker before 1.3.3 allows remote attackers to write to arbitrary files and bypass a container protection mechanism via a full pathname in a symlink in an (1) image or (2) build in a Dockerfile. + +analysis: {"Image":"Docker image","Reason":"The CVE is introduced through the container image by including a malicious symlink with a full pathname in the Dockerfile or build process.","Consequence":"Remote attackers can exploit this vulnerability to write to arbitrary files on the host system, bypassing container protection mechanisms. This leads to potential system compromise and has a high severity impact."} + +cve: ./data/2014/9xxx/CVE-2014-9357.json +Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build in a Dockerfile in an LZMA (.xz) archive, related to the chroot for archive extraction. + +analysis: {"Image":"Docker","Reason":"CVE-2014-9357 是由于在 Docker 镜像或 Dockerfile 构建过程中对 LZMA (.xz) 压缩包的解压处理不当导致的问题，属于容器镜像处理环节引入的漏洞","Consequence":"远程攻击者可以通过构造恶意镜像或 Dockerfile 执行任意代码并以 root 权限运行，危害极大，可能导致宿主机被完全控制"} + +cve: ./data/2014/9xxx/CVE-2014-9358.json +Docker before 1.3.3 does not properly validate image IDs, which allows remote attackers to conduct path traversal attacks and spoof repositories via a crafted image in a (1) "docker load" operation or (2) "registry communications." + +analysis: {"Image":"Docker","Reason":"CVE描述指出该漏洞是由于Docker在镜像加载或仓库通信过程中未正确验证镜像ID，从而导致攻击者可以伪造镜像进行路径穿越攻击。这属于容器镜像处理引入的问题","Consequence":"远程攻击者可以通过构造恶意镜像执行路径穿越攻击并伪造仓库，可能导致敏感数据泄露或系统被进一步攻击，严重程度较高"} + +cve: ./data/2015/1xxx/CVE-2015-1318.json +The crash reporting feature in Apport 2.13 through 2.17.x before 2.17.1 allows local users to gain privileges via a crafted usr/share/apport/apport file in a namespace (container). + +analysis: {"Image":"Apport","Reason":"The vulnerability is introduced through a container with a crafted usr/share/apport/apport file.","Consequence":"Local users can gain privileges, leading to a high severity security issue."} + +cve: ./data/2015/3xxx/CVE-2015-3627.json +Libcontainer and Docker Engine before 1.6.1 opens the file-descriptor passed to the pid-1 process before performing the chroot, which allows local users to gain privileges via a symlink attack in an image. + +analysis: {"Image":"Docker Engine","Reason":"漏洞由于容器镜像创建过程中文件描述符和chroot处理不当导致，攻击者可通过恶意构造的镜像利用符号链接攻击提权","Consequence":"本地用户可获得更高权限，可能导致系统被完全控制，严重程度高"} + +cve: ./data/2015/3xxx/CVE-2015-3629.json +Libcontainer 1.6.0, as used in Docker Engine, allows local users to escape containerization ("mount namespace breakout") and write to arbitrary file on the host system via a symlink attack in an image when respawning a container. + +analysis: {"Image":"Libcontainer","Reason":"漏洞由于容器镜像中存在可被本地用户利用的符号链接攻击，导致可以逃离容器并写入宿主机任意文件","Consequence":"该CVE允许攻击者突破容器隔离环境，对宿主机系统造成影响，具有较高严重性"} + +cve: ./data/2015/3xxx/CVE-2015-3631.json +Docker Engine before 1.6.1 allows local users to set arbitrary Linux Security Modules (LSM) and docker_t policies via an image that allows volumes to override files in /proc. + +analysis: {"Image":"Docker Engine","Reason":"The vulnerability is introduced through the Docker image by allowing volumes to override files in /proc, which can lead to arbitrary Linux Security Modules (LSM) and docker_t policies being set.","Consequence":"Local users may escalate privileges or bypass security restrictions, leading to a high severity impact on system integrity and security."} + +cve: ./data/2016/0xxx/CVE-2016-0761.json +Cloud Foundry Garden-Linux versions prior to v0.333.0 and Elastic Runtime 1.6.x version prior to 1.6.17 contain a flaw in managing container files during Docker image preparation that could be used to delete, corrupt or overwrite host files and directories, including other container filesystems on the host. + +analysis: {"Image":"Cloud Foundry Garden-Linux","Reason":"容器镜像准备过程中对文件管理存在缺陷，可能导致宿主机上的文件被删除、破坏或覆盖","Consequence":"攻击者可以利用此漏洞影响宿主机和其他容器的文件系统，导致数据丢失或服务中断，严重程度高"} + +cve: ./data/2016/3xxx/CVE-2016-3697.json +libcontainer/user/user.go in runC before 0.1.0, as used in Docker before 1.11.2, improperly treats a numeric UID as a potential username, which allows local users to gain privileges via a numeric username in the password file in a container. + +analysis: {"Image":"runC","Reason":"容器镜像中密码文件内可能包含恶意构造的数值型UID作为用户名，导致提权漏洞","Consequence":"本地用户可通过构造特定的密码文件在容器中实现权限提升，进而威胁宿主机安全，严重程度高"} + +cve: ./data/2016/3xxx/CVE-2016-3708.json +Red Hat OpenShift Enterprise 3.2, when multi-tenant SDN is enabled and a build is run in a namespace that would normally be isolated from pods in other namespaces, allows remote authenticated users to access network resources on restricted pods via an s2i build with a builder image that (1) contains ONBUILD commands or (2) does not contain a tar binary. + +analysis: {"Image":"s2i builder image","Reason":"The CVE arises from the behavior of the s2i (Source-to-Image) builder image when it contains ONBUILD commands or lacks a tar binary, which can be exploited during build processes in a multi-tenant SDN environment","Consequence":"Remote authenticated users may bypass network isolation and access resources on restricted pods, leading to potential security breaches in containerized environments"} + +cve: ./data/2016/3xxx/CVE-2016-3711.json +HAproxy in Red Hat OpenShift Enterprise 3.2 and OpenShift Origin allows local users to obtain the internal IP address of a pod by reading the "OPENSHIFT_[namespace]_SERVERID" cookie. + +analysis: {"Image":"Red Hat OpenShift Enterprise haproxy","Reason":"The CVE is introduced by the haproxy component in the container image, which exposes internal pod IP addresses through cookies.","Consequence":"Information disclosure vulnerability leading to potential security risks for containerized applications."} + +cve: ./data/2016/3xxx/CVE-2016-3738.json +Red Hat OpenShift Enterprise 3.2 does not properly restrict access to STI builds, which allows remote authenticated users to access the Docker socket and gain privileges via vectors related to build-pod. + +analysis: {"Image":"Red Hat OpenShift Enterprise","Reason":"容器镜像未正确限制对STI构建的访问，导致远程认证用户可通过相关向量访问Docker套接字并提权","Consequence":"攻击者可获得更高权限，可能导致系统被完全控制，严重程度高"} + +cve: ./data/2016/5xxx/CVE-2016-5385.json +PHP through 7.0.8 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect an application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, as demonstrated by (1) an application that makes a getenv('HTTP_PROXY') call or (2) a CGI configuration of PHP, aka an "httpoxy" issue. + +analysis: {"Image":"php","Reason":"容器镜像中PHP未处理HTTP_PROXY环境变量的命名空间冲突问题","Consequence":"攻击者可通过构造恶意Proxy头重定向应用的HTTP出站流量，可能导致敏感信息泄露或中间人攻击"} + +cve: ./data/2016/5xxx/CVE-2016-5386.json +The net/http package in Go through 1.6 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect CGI applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect a CGI application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, aka an "httpoxy" issue. + +analysis: {"Image":"[CGI application container镜像]","Reason":"[容器镜像中使用了存在漏洞的Go net/http 包处理环境变量，未正确处理HTTP_PROXY环境变量导致]","Consequence":"[远程攻击者可以通过构造Proxy头将CGI应用的出站HTTP流量重定向到任意代理服务器，造成请求被劫持，严重程度较高]"} + +cve: ./data/2016/7xxx/CVE-2016-7569.json +Directory traversal vulnerability in docker2aci before 0.13.0 allows remote attackers to write to arbitrary files via a .. (dot dot) in the embedded layer data in an image. + +analysis: {"Image":"docker2aci","Reason":"Directory traversal vulnerability allows remote attackers to write to arbitrary files via embedded layer data in an image","Consequence":"This vulnerability can lead to unauthorized file modifications on the host system, posing a significant security risk."} + +cve: ./data/2016/8xxx/CVE-2016-8579.json +docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain. + +analysis: {"Image":"docker2aci","Reason":"容器镜像处理存在循环依赖链时会进入无限循环","Consequence":"可能导致资源耗尽，造成拒绝服务（DoS），严重程度中等至高"} + +cve: ./data/2016/8xxx/CVE-2016-8954.json +IBM dashDB Local uses hard-coded credentials that could allow a remote attacker to gain access to the Docker container or database. + +analysis: {"Image":"IBM dashDB Local","Reason":"使用硬编码凭证导致Docker容器可能被远程攻击者访问","Consequence":"攻击者可利用该漏洞获取对容器或数据库的未授权访问权限，可能导致敏感数据泄露或系统被控制，严重程度高"} + +cve: ./data/2017/0xxx/CVE-2017-0913.json +Ubiquiti UCRM versions 2.3.0 to 2.7.7 allow an authenticated user to read arbitrary files in the local file system. Note that by default, the local file system is isolated in a docker container. Successful exploitation requires valid credentials to an account with "Edit" access to "System Customization". + +analysis: {"Image":"Ubiquiti UCRM","Reason":"The vulnerability allows an authenticated user to read arbitrary files in the local file system, which is typically isolated in a Docker container by default.","Consequence":"An attacker with valid credentials and edit access to 'System Customization' can exploit this vulnerability to gain unauthorized access to sensitive files on the host system, leading to potential information disclosure and security compromise."} + +cve: ./data/2017/10xxx/CVE-2017-10940.json +This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Joyent Smart Data Center prior to agentsshar@1.0.0-release-20160901-20160901T051624Z-g3fd5adf (e469cf49-4de3-4658-8419-ab42837916ad). 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 docker API. The process does not properly validate user-supplied data which can allow for the upload of arbitrary files. An attacker can leverage this vulnerability to execute arbitrary code under the context of root. Was ZDI-CAN-3853. + +analysis: {"Image":"Joyent Smart Data Center","Reason":"漏洞存在于docker API中，由于未正确验证用户提供的数据，导致可上传任意文件","Consequence":"攻击者可在目标系统上以root权限执行任意代码，危害严重"} + +cve: ./data/2017/11xxx/CVE-2017-11468.json +Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint. + +analysis: {"Image":"Docker Registry","Reason":"CVE描述中未提及容器镜像相关问题，而是Docker实现中的问题","Consequence":"N/A"} + +cve: ./data/2017/7xxx/CVE-2017-7412.json +NixOS 17.03 before 17.03.887 has a world-writable Docker socket, which allows local users to gain privileges by executing docker commands. + +analysis: {"Image":"NixOS","Reason":"容器的运行会导致宿主机CPU资源被大量占用","Consequence":"该CVE可能导致本地用户通过执行docker命令获得特权，属于权限提升类漏洞，具有较高严重程度"} + +cve: ./data/2017/7xxx/CVE-2017-7669.json +In Apache Hadoop 2.8.0, 3.0.0-alpha1, and 3.0.0-alpha2, the LinuxContainerExecutor runs docker commands as root with insufficient input validation. When the docker feature is enabled, authenticated users can run commands as root. + +analysis: {"Image":"hadoop","Reason":"The LinuxContainerExecutor in Hadoop runs docker commands as root with insufficient input validation","Consequence":"Authenticated users can run arbitrary commands as root, leading to a critical privilege escalation vulnerability"} + +cve: ./data/2018/10xxx/CVE-2018-10205.json +hyperstart 1.0.0 in HyperHQ Hyper has memory leaks in the container_setup_modules and hyper_rescan_scsi functions in container.c, related to runV 1.0.0 for Docker. + +analysis: {"Image":"hyperstart","Reason":"容器镜像中存在内存泄漏问题，涉及container_setup_modules和hyper_rescan_scsi函数的实现","Consequence":"攻击者可能通过持续触发相关功能导致内存资源被耗尽，造成拒绝服务（DoS），严重程度中等至较高"} + +cve: ./data/2018/11xxx/CVE-2018-11756.json +In PHP Runtime for Apache OpenWhisk, a Docker action inheriting one of the Docker tags openwhisk/action-php-v7.2:1.0.0 or openwhisk/action-php-v7.1:1.0.1 (or earlier) may allow an attacker to replace the user function inside the container if the user code is vulnerable to code exploitation. + +analysis: {"Image":"openwhisk/action-php-v7.2:1.0.0 or openwhisk/action-php-v7.1:1.0.1","Reason":"The vulnerability arises from the container image's handling of user code, which may allow an attacker to replace the user function if the code is vulnerable to exploitation.","Consequence":"An attacker could potentially take control of the user function inside the container, leading to unauthorized code execution within the container environment."} + +cve: ./data/2018/11xxx/CVE-2018-11757.json +In Docker Skeleton Runtime for Apache OpenWhisk, a Docker action inheriting the Docker tag openwhisk/dockerskeleton:1.3.0 (or earlier) may allow an attacker to replace the user function inside the container if the user code is vulnerable to code exploitation. + +analysis: {"Image":"openwhisk/dockerskeleton","Reason":"该镜像中的用户代码若存在漏洞，可能导致容器内的用户函数被攻击者替换","Consequence":"攻击者可能在容器中执行恶意代码，危害容器及宿主机的安全，严重程度高"} + +cve: ./data/2018/16xxx/CVE-2018-16398.json +In Twistlock AuthZ Broker 0.1, regular expressions are mishandled, as demonstrated by containers/aa/pause?aaa=\/start to bypass a policy in which "docker start" is allowed but "docker pause" is not allowed. + +analysis: {"Image":"Twistlock AuthZ Broker","Reason":"正则表达式处理不当导致策略绕过","Consequence":"攻击者可以构造特定请求绕过预期的权限控制，从而执行被禁止的操作（如docker pause），可能导致容器环境的安全策略失效。"} + +cve: ./data/2018/1xxx/CVE-2018-1277.json +Cloud Foundry Garden-runC, versions prior to 1.13.0, does not correctly enforce disc quotas for Docker image layers. A remote authenticated user may push an app with a malicious Docker image that will consume more space on a Diego cell than allocated in their quota, potentially causing a DoS against the cell. + +analysis: {"Image":"Docker","Reason":"CVE描述中提到该漏洞是由于容器镜像层的磁盘配额未被正确强制执行，导致恶意镜像可能消耗超出配额的空间。","Consequence":"远程认证用户可以推送恶意镜像，占用Diego单元超出配额的存储空间，可能导致拒绝服务（DoS）攻击。"} + +cve: ./data/2018/20xxx/CVE-2018-20871.json +In Univa Grid Engine before 8.6.3, when configured for Docker jobs and execd spooling on root_squash, weak file permissions ("other" write access) occur in certain cases (GE-6890). + +analysis: {"Image":"Univa Grid Engine","Reason":"容器镜像配置不当导致弱文件权限（\"other\"写入权限）问题","Consequence":"可能允许非特权用户修改或覆盖关键文件，从而导致安全漏洞，严重程度中等至高，取决于具体环境配置"} + +cve: ./data/2018/3xxx/CVE-2018-3213.json +Vulnerability in the Oracle WebLogic Server component of Oracle Fusion Middleware (subcomponent: Docker Images). The supported version that is affected is prior to Docker 12.2.1.3.20180913. Easily exploitable vulnerability allows unauthenticated attacker with network access via T3 to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle WebLogic Server accessible data. CVSS 3.0 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). + +analysis: {"Image":"Oracle WebLogic Server","Reason":"该CVE是由于容器镜像中未正确修复的漏洞导致，影响Docker镜像版本12.2.1.3.20180913之前的版本","Consequence":"成功利用此漏洞可能导致未经授权访问关键数据或完全访问所有Oracle WebLogic Server可访问的数据，CVSS评分为7.5，属于高危漏洞"} + +cve: ./data/2018/6xxx/CVE-2018-6184.json +ZEIT Next.js 4 before 4.2.3 has Directory Traversal under the /_next request namespace. + +analysis: {"Image":"ZEIT Next.js","Reason":"Container镜像中未正确处理/_next请求命名空间中的目录遍历问题","Consequence":"攻击者可以利用该漏洞访问受限的文件或资源，可能导致敏感信息泄露，严重程度中等至较高"} + +cve: ./data/2018/9xxx/CVE-2018-9862.json +util.c in runV 1.0.0 for Docker mishandles a numeric username, which allows attackers to obtain root access by leveraging the presence of an initial numeric value on an /etc/passwd line, and then issuing a "docker exec" command with that value in the -u argument, a similar issue to CVE-2016-3697. + +analysis: {"Image":"runV","Reason":"The vulnerability is introduced through improper handling of a numeric username in the container image's configuration, which can be exploited during execution.","Consequence":"Attackers can obtain root access within the container environment, leading to potential system compromise; this issue is similar to CVE-2016-3697 and highlights a critical security risk."} + +cve: ./data/2019/0xxx/CVE-2019-0204.json +A specifically crafted Docker image running under the root user can overwrite the init helper binary of the container runtime and/or the command executor in Apache Mesos versions pre-1.4.x, 1.4.0 to 1.4.2, 1.5.0 to 1.5.2, 1.6.0 to 1.6.1, and 1.7.0 to 1.7.1. A malicious actor can therefore gain root-level code execution on the host. + +analysis: {"Image":"[引入CVE的容器镜像名称]","Reason":"[容器镜像在运行时可以覆盖容器运行时的init辅助程序或命令执行器]","Consequence":"[该CVE可能导致攻击者获得宿主机的root级别代码执行权限，严重程度高]"} + +cve: ./data/2019/10xxx/CVE-2019-10175.json +A flaw was found in the containerized-data-importer in virt-cdi-cloner, version 1.4, where the host-assisted cloning feature does not determine whether the requesting user has permission to access the Persistent Volume Claim (PVC) in the source namespace. This could allow users to clone any PVC in the cluster into their own namespace, effectively allowing access to other user's data. + +analysis: {"Image":"virt-cdi-cloner","Reason":"容器镜像中的 host-assisted cloning 功能未验证用户对源命名空间中 PVC 的访问权限","Consequence":"攻击者可以克隆集群中任意 PVC 到自己的命名空间，导致其他用户的数据被非法访问，严重程度高"} + +cve: ./data/2019/12xxx/CVE-2019-12670.json +A vulnerability in the filesystem of Cisco IOS XE Software could allow an authenticated, local attacker within the IOx Guest Shell to modify the namespace container protections on an affected device. The vulnerability is due to insufficient file permissions. An attacker could exploit this vulnerability by modifying files that they should not have access to. A successful exploit could allow the attacker to remove container protections and perform file actions outside the namespace of the container. + +analysis: {"Image":"Cisco IOS XE Software","Reason":"漏洞是由于文件系统中的文件权限设置不当导致的，攻击者可利用此漏洞修改容器命名空间保护机制","Consequence":"攻击者可以移除容器保护机制，并在容器之外执行文件操作，可能导致容器逃逸和宿主机资源被恶意访问"} + +cve: ./data/2019/12xxx/CVE-2019-12825.json +Unauthorized Access to the Container Registry of other groups was discovered in GitLab Enterprise 12.0.0-pre. In other words, authenticated remote attackers can read Docker registries of other groups. When a legitimate user changes the path of a group, Docker registries are not adapted, leaving them in the old namespace. They are not protected and are available to all other users with no previous access to the repo. + +analysis: {"Image":"GitLab Enterprise","Reason":"CVE源于容器镜像仓库的访问控制不当，导致其他用户可访问不属于自己的Docker镜像仓库","Consequence":"远程认证攻击者可以读取其他组的Docker镜像仓库内容，造成信息泄露，严重程度高"} + +cve: ./data/2019/13xxx/CVE-2019-13139.json +In Docker before 18.09.4, an attacker who is capable of supplying or manipulating the build path for the "docker build" command would be able to gain command execution. An issue exists in the way "docker build" processes remote git URLs, and results in command injection into the underlying "git clone" command, leading to code execution in the context of the user executing the "docker build" command. This occurs because git ref can be misinterpreted as a flag. + +analysis: {"Image":"docker","Reason":"漏洞是由于在容器镜像构建过程中对远程git URL的处理不当导致命令注入，而非Docker运行时或内核实现的问题","Consequence":"攻击者可以执行任意命令，危害构建环境的安全，严重程度高"} + +cve: ./data/2019/13xxx/CVE-2019-13509.json +In Docker CE and EE before 18.09.8 (as well as Docker EE before 17.06.2-ee-23 and 18.x before 18.03.1-ee-10), Docker Engine in debug mode may sometimes add secrets to the debug log. This applies to a scenario where docker stack deploy is run to redeploy a stack that includes (non external) secrets. It potentially applies to other API users of the stack API if they resend the secret. + +analysis: {"Image":"docker","Reason":"容器镜像创建或部署过程中可能将敏感信息写入调试日志","Consequence":"可能导致敏感信息泄露，如密钥或凭证信息，攻击者可利用这些信息进一步入侵系统，属于高危漏洞"} + +cve: ./data/2019/14xxx/CVE-2019-14806.json +Pallets Werkzeug before 0.15.3, when used with Docker, has insufficient debugger PIN randomness because Docker containers share the same machine id. + +analysis: {"Image":"Pallets Werkzeug","Reason":"when used with Docker, has insufficient debugger PIN randomness because Docker containers share the same machine id","Consequence":"This vulnerability could lead to an attacker guessing the debugger PIN and gaining unauthorized access to the application's debugging interface, which may result in sensitive information disclosure or remote code execution. The severity is medium to high depending on the context of usage."} + +cve: ./data/2019/14xxx/CVE-2019-14819.json +A flaw was found during the upgrade of an existing OpenShift Container Platform 3.x cluster. Using CRI-O, the dockergc service account is assigned to the current namespace of the user performing the upgrade. This flaw can allow an unprivileged user to escalate their privileges to those allowed by the privileged Security Context Constraints. + +analysis: {"Image":"OpenShift Container Platform","Reason":"During the upgrade process, the dockergc service account is assigned to the current namespace of the user performing the upgrade, which is a result of improper handling of service account permissions in the container environment.","Consequence":"An unprivileged user could escalate their privileges to those allowed by the privileged Security Context Constraints, leading to potential unauthorized access and control over the cluster."} + +cve: ./data/2019/15xxx/CVE-2019-15752.json +Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-credential-wincred.exe file in %PROGRAMDATA%\DockerDesktop\version-bin\ as a low-privilege user, and then waiting for an admin or service user to authenticate with Docker, restart Docker, or run 'docker login' to force the command. + +analysis: {"Image":"docker-credential-wincred","Reason":"容器镜像中存在提权漏洞，攻击者可通过放置恶意文件诱导高权限用户执行操作","Consequence":"本地低权限用户可利用此漏洞以高权限执行代码，导致权限提升和潜在系统控制，严重程度较高"} + +cve: ./data/2019/5xxx/CVE-2019-5021.json +Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the `root` user. This vulnerability appears to be the result of a regression introduced in December of 2015. Due to the nature of this issue, systems deployed using affected versions of the Alpine Linux container which utilize Linux PAM, or some other mechanism which uses the system shadow file as an authentication database, may accept a NULL password for the `root` user. + +analysis: {"Image":"Alpine Linux","Reason":"容器镜像中 `root` 用户的密码为空，可能导致身份验证机制失效","Consequence":"攻击者可以利用空密码以 root 身份登录系统，造成权限提升和系统被恶意控制，严重程度高"} + +cve: ./data/2019/5xxx/CVE-2019-5736.json +runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe. + +analysis: {"Image":"runc","Reason":"漏洞由于容器镜像中runc程序的文件描述符处理不当导致宿主机runc二进制文件被覆盖","Consequence":"攻击者可以获取宿主机root权限，导致严重的安全风险，属于高危漏洞"} + +cve: ./data/2020/10xxx/CVE-2020-10689.json +A flaw was found in the Eclipse Che up to version 7.8.x, where it did not properly restrict access to workspace pods. An authenticated user can exploit this flaw to bypass JWT proxy and gain access to the workspace pods of another user. Successful exploitation requires knowledge of the service name and namespace of the target pod. + +analysis: {"Image":"Eclipse Che","Reason":"Improper restriction of access to workspace pods allows an authenticated user to bypass JWT proxy","Consequence":"Unauthorized access to another user's workspace pods, leading to potential data exposure or manipulation with medium to high severity impact"} + +cve: ./data/2020/11xxx/CVE-2020-11878.json +The Jitsi Meet (aka docker-jitsi-meet) stack on Docker before stable-4384-1 uses default passwords (such as passw0rd) for system accounts. + +analysis: {"Image":"docker-jitsi-meet","Reason":"The container image uses default passwords for system accounts, which can be easily exploited","Consequence":"This vulnerability allows attackers to gain unauthorized access to system accounts, leading to potential compromise of the entire system. The severity is high due to the weak authentication mechanism."} + +cve: ./data/2020/13xxx/CVE-2020-13347.json +A command injection vulnerability was discovered in Gitlab runner versions prior to 13.2.4, 13.3.2 and 13.4.1. When the runner is configured on a Windows system with a docker executor, which allows the attacker to run arbitrary commands on Windows host, via DOCKER_AUTH_CONFIG build variable. + +analysis: {"Image":"Gitlab runner","Reason":"When the runner is configured on a Windows system with a docker executor, which allows the attacker to run arbitrary commands on Windows host, via DOCKER_AUTH_CONFIG build variable","Consequence":"Command injection vulnerability leading to unauthorized execution of arbitrary commands on the host"} + +cve: ./data/2020/14xxx/CVE-2020-14306.json +An incorrect access control flaw was found in the operator, openshift-service-mesh/istio-rhel8-operator all versions through 1.1.3. This flaw allows an attacker with a basic level of access to the cluster to deploy a custom gateway/pod to any namespace, potentially gaining access to privileged service account tokens. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability. + +analysis: {"Image":"openshift-service-mesh/istio-rhel8-operator","Reason":"该漏洞是由于容器镜像中的operator存在访问控制问题，允许低权限攻击者部署自定义网关/pod到任意命名空间","Consequence":"可能导致特权服务账户令牌泄露，对数据的机密性、完整性以及系统可用性造成严重威胁"} + +cve: ./data/2020/14xxx/CVE-2020-14313.json +An information disclosure vulnerability was found in Red Hat Quay in versions before 3.3.1. This flaw allows an attacker who can create a build trigger in a repository, to disclose the names of robot accounts and the existence of private repositories within any namespace. + +analysis: {"Image":"Red Hat Quay","Reason":"An information disclosure vulnerability exists in the container image due to improper handling of build triggers, which could allow an attacker to gather sensitive information.","Consequence":"Attackers can disclose names of robot accounts and determine the existence of private repositories within any namespace, leading to potential security breaches."} + +cve: ./data/2020/14xxx/CVE-2020-14370.json +An information disclosure vulnerability was found in containers/podman in versions before 2.0.5. When using the deprecated Varlink API or the Docker-compatible REST API, if multiple containers are created in a short duration, the environment variables from the first container will get leaked into subsequent containers. An attacker who has control over the subsequent containers could use this flaw to gain access to sensitive information stored in such variables. + +analysis: {"Image":"containers/podman","Reason":"使用已弃用的Varlink API或Docker兼容的REST API在短时间内创建多个容器时，第一个容器的环境变量会泄露到后续容器中","Consequence":"攻击者可以利用此漏洞获取存储在环境变量中的敏感信息，从而导致信息泄露，严重程度为中高风险"} + +cve: ./data/2020/15xxx/CVE-2020-15080.json +In PrestaShop from version 1.7.4.0 and before version 1.7.6.6, some files should not be in the release archive, and others should not be accessible. The problem is fixed in version 1.7.6.6 A possible workaround is to make sure `composer.json` and `docker-compose.yml` are not accessible on your server. + +analysis: {"Image":"prestashop","Reason":"The CVE indicates that certain files like `composer.json` and `docker-compose.yml` should not be accessible in the server, which suggests improper handling during container image creation or configuration.","Consequence":"Exposure of sensitive files may lead to information disclosure or further exploitation, posing a security risk."} + +cve: ./data/2020/15xxx/CVE-2020-15590.json +A vulnerability in the Private Internet Access (PIA) VPN Client for Linux 1.5 through 2.3+ allows remote attackers to bypass an intended VPN kill switch mechanism and read sensitive information via intercepting network traffic. Since 1.5, PIA has supported a “split tunnel” OpenVPN bypass option. The PIA killswitch & associated iptables firewall is designed to protect you while using the Internet. When the kill switch is configured to block all inbound and outbound network traffic, privileged applications can continue sending & receiving network traffic if net.ipv4.ip_forward has been enabled in the system kernel parameters. For example, a Docker container running on a host with the VPN turned off, and the kill switch turned on, can continue using the internet, leaking the host IP (CWE 200). In PIA 2.4.0+, policy-based routing is enabled by default and is used to direct all forwarded packets to the VPN interface automatically. + +analysis: {"Image":"Docker container","Reason":"The vulnerability arises when a Docker container runs on a host with the VPN turned off and the PIA kill switch turned on, while net.ipv4.ip_forward is enabled in the kernel parameters.","Consequence":"The Docker container can continue using the internet, leaking the host IP address, which allows remote attackers to bypass the intended VPN kill switch mechanism and read sensitive information via intercepted network traffic (CWE 200). This represents a significant privacy and security risk."} + +cve: ./data/2020/1xxx/CVE-2020-1731.json +A flaw was found in all versions of the Keycloak operator, before version 8.0.2,(community only) where the operator generates a random admin password when installing Keycloak, however the password remains the same when deployed to the same OpenShift namespace. + +analysis: {"Image":"Keycloak operator","Reason":"The CVE is related to the Keycloak operator generating a static admin password when deployed in the same OpenShift namespace, which is tied to how the container image is used in deployment.","Consequence":"This flaw leads to a security risk where the admin password remains predictable, potentially allowing unauthorized access. The severity is high as it impacts authentication and authorization mechanisms."} + +cve: ./data/2020/24xxx/CVE-2020-24263.json +Portainer 1.24.1 and earlier is affected by an insecure permissions vulnerability that may lead to remote arbitrary code execution. A non-admin user is allowed to spawn new containers with critical capabilities such as SYS_MODULE, which can be used to take over the Docker host. + +analysis: {"Image":"Portainer","Reason":"非管理员用户可以创建具有关键权限的容器，例如 SYS_MODULE，从而在Docker宿主机上执行任意代码","Consequence":"攻击者可能利用此漏洞完全控制Docker宿主机，属于高危漏洞"} + +cve: ./data/2020/24xxx/CVE-2020-24264.json +Portainer 1.24.1 and earlier is affected by incorrect access control that may lead to remote arbitrary code execution. The restriction checks for bind mounts are applied only on the client-side and not the server-side, which can lead to spawning a container with bind mount. Once such a container is spawned, it can be leveraged to break out of the container leading to complete Docker host machine takeover. + +analysis: {"Image":"Portainer","Reason":"The incorrect access control allows remote attackers to execute arbitrary code by spawning a container with bind mount, which is not properly restricted on the server-side.","Consequence":"Remote arbitrary code execution leading to complete Docker host machine takeover, which is highly severe."} + +cve: ./data/2020/26xxx/CVE-2020-26213.json +In teler before version 0.0.1, if you run teler inside a Docker container and encounter `errors.Exit` function, it will cause denial-of-service (`SIGSEGV`) because it doesn't get process ID and process group ID of teler properly to kills. The issue is patched in teler 0.0.1 and 0.0.1-dev5.1. + +analysis: {"Image":"teler","Reason":"运行在Docker容器中的teler在遇到`errors.Exit`函数时，由于无法正确获取进程ID和进程组ID来终止进程，导致拒绝服务（`SIGSEGV`）","Consequence":"该CVE会导致容器内程序出现段错误，引发拒绝服务，影响可用性；严重程度中等"} + +cve: ./data/2020/26xxx/CVE-2020-26278.json +Weave Net is open source software which creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. Weave Net before version 2.8.0 has a vulnerability in which can allow an attacker to take over any host in the cluster. Weave Net is supplied with a manifest that runs pods on every node in a Kubernetes cluster, which are responsible for managing network connections for all other pods in the cluster. This requires a lot of power over the host, and the manifest sets `privileged: true`, which gives it that power. It also set `hostPID: true`, which gave it the ability to access all other processes on the host, and write anywhere in the root filesystem of the host. This setting was not necessary, and is being removed. You are only vulnerable if you have an additional vulnerability (e.g. a bug in Kubernetes) or misconfiguration that allows an attacker to run code inside the Weave Net pod, No such bug is known at the time of release, and there are no known instances of this being exploited. Weave Net 2.8.0 removes the hostPID setting and moves CNI plugin install to an init container. Users who do not update to 2.8.0 can edit the hostPID line in their existing DaemonSet manifest to say false instead of true, arrange some other way to install CNI plugins (e.g. Ansible) and remove those mounts from the DaemonSet manifest. + +analysis: {"Image":"Weave Net","Reason":"The vulnerability arises from the Weave Net pod configuration in the Kubernetes DaemonSet manifest, which unnecessarily set `hostPID: true` and `privileged: true`, allowing potential attacker to gain extensive control over the host","Consequence":"An attacker could take over any host in the cluster if additional vulnerabilities or misconfigurations exist, although no such exploits are currently known"} + +cve: ./data/2020/27xxx/CVE-2020-27816.json +The elasticsearch-operator does not validate the namespace where kibana logging resource is created and due to that it is possible to replace the original openshift-logging console link (kibana console) to different one, created based on the new CR for the new kibana resource. This could lead to an arbitrary URL redirection or the openshift-logging console link damage. This flaw affects elasticsearch-operator-container versions before 4.7. + +analysis: {"Image":"elasticsearch-operator-container","Reason":"The vulnerability arises from improper validation of the namespace for Kibana logging resource creation in the container image, allowing manipulation of console links.","Consequence":"An attacker could perform arbitrary URL redirection or damage the openshift-logging console link, leading to potential phishing or service disruption."} + +cve: ./data/2020/29xxx/CVE-2020-29389.json +The official Crux Linux Docker images 3.0 through 3.4 contain a blank password for a root user. System using the Crux Linux Docker container deployed by affected versions of the Docker image may allow an attacker to achieve root access with a blank password. + +analysis: ```json +{"Image":"Crux Linux Docker image","Reason":"The container image sets a blank password for the root user, which is an insecure configuration introduced during image creation.","Consequence":"An attacker can gain unauthorized root access to the system by exploiting the empty root password, leading to full system compromise. This vulnerability has a high severity."} +``` + +cve: ./data/2020/29xxx/CVE-2020-29564.json +The official Consul Docker images 0.7.1 through 1.4.2 contain a blank password for a root user. System using the Consul Docker container deployed by affected versions of the Docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"Consul Docker image","Reason":"The container image contains a blank password for the root user, which is a result of improper configuration during image creation.","Consequence":"A remote attacker may achieve root access to the system using the affected container, leading to potential system compromise and data loss. This vulnerability has high severity."} + +cve: ./data/2020/29xxx/CVE-2020-29575.json +The official elixir Docker images before 1.8.0-alpine (Alpine specific) contain a blank password for a root user. Systems using the elixir Linux Docker container deployed by affected versions of the Docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"elixir","Reason":"容器镜像中root用户存在空密码","Consequence":"远程攻击者可利用该漏洞以root权限访问系统，导致严重的安全风险"} + +cve: ./data/2020/29xxx/CVE-2020-29576.json +The official eggdrop Docker images before 1.8.4rc2 contain a blank password for a root user. Systems using the Eggdrop Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password. + +analysis: {"Image":"eggdrop","Reason":"容器镜像中root用户存在空密码，导致攻击者可利用空密码获得远程根访问权限","Consequence":"远程攻击者可以以root身份登录系统，进而完全控制系统，属于高危漏洞"} + +cve: ./data/2020/29xxx/CVE-2020-29577.json +The official znc docker images before 1.7.1-slim contain a blank password for a root user. Systems using the znc docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password. + +analysis: {"Image":"znc","Reason":"容器镜像中root用户密码为空，导致远程攻击者可通过空密码获得root权限","Consequence":"远程攻击者可以利用此漏洞获得容器的root访问权限，进而可能危害宿主机系统安全，严重程度高"} + +cve: ./data/2020/29xxx/CVE-2020-29578.json +The official piwik Docker images before fpm-alpine (Alpine specific) contain a blank password for a root user. Systems using the Piwik Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access. + +analysis: {"Image":"piwik","Reason":"The Docker image contains a blank password for the root user, which can allow remote attackers to gain root access.","Consequence":"Remote attackers may achieve root access to the system using the affected Piwik Docker container, leading to a high severity security breach."} + +cve: ./data/2020/29xxx/CVE-2020-29579.json +The official Express Gateway Docker images before 1.14.0 contain a blank password for a root user. Systems using the Express Gateway Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access. + +analysis: {"Image":"Express Gateway","Reason":"容器镜像中为root用户设置了空密码","Consequence":"远程攻击者可能获得root访问权限，导致系统被完全控制，严重程度高"} + +cve: ./data/2020/29xxx/CVE-2020-29580.json +The official storm Docker images before 1.2.1 contain a blank password for a root user. Systems using the Storm Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password. + +analysis: {"Image":"storm","Reason":"容器镜像中root用户存在空密码，导致远程攻击者可通过空密码获得root权限","Consequence":"远程攻击者可以未经授权以root身份访问系统，造成严重安全风险"} + +cve: ./data/2020/29xxx/CVE-2020-29581.json +The official spiped docker images before 1.5-alpine contain a blank password for a root user. Systems using the spiped docker container deployed by affected versions of the docker image may allow an remote attacker to achieve root access with a blank password. + +analysis: {"Image":"spiped","Reason":"容器镜像中root用户存在空密码","Consequence":"远程攻击者可利用空密码以root权限访问系统，导致严重的安全风险"} + +cve: ./data/2020/29xxx/CVE-2020-29591.json +Versions of the Official registry Docker images through 2.7.0 contain a blank password for the root user. Systems deployed using affected versions of the registry container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"registry","Reason":"The CVE is introduced by the official registry Docker image where a blank password for the root user is present in container images through 2.7.0.","Consequence":"Remote attackers may achieve root access to the system using a blank password, leading to a critical security breach."} + +cve: ./data/2020/29xxx/CVE-2020-29601.json +The official notary docker images before signer-0.6.1-1 contain a blank password for a root user. System using the notary docker container deployed by affected versions of the docker image may allow an remote attacker to achieve root access with a blank password. + +analysis: {"Image":"notary docker image","Reason":"The container image contains a blank password for the root user, which can be exploited by an attacker to gain unauthorized access.","Consequence":"Remote attacker can achieve root access with a blank password. This poses a severe security risk as it allows full control over the affected system."} + +cve: ./data/2020/29xxx/CVE-2020-29602.json +The official irssi docker images before 1.1-alpine (Alpine specific) contain a blank password for a root user. System using the irssi docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password. + +analysis: {"Image":"irssi","Reason":"容器镜像中root用户密码为空，导致攻击者可利用空密码获得宿主机的root访问权限","Consequence":"远程攻击者可以无需认证即可获得系统的最高权限，可能导致系统被完全控制，数据泄露或破坏，严重程度高"} + +cve: ./data/2020/35xxx/CVE-2020-35184.json +The official composer docker images before 1.8.3 contain a blank password for a root user. System using the composer docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"composer","Reason":"容器镜像中 root 用户密码为空，导致攻击者可利用空密码获得宿主机的 root 访问权限","Consequence":"远程攻击者可以无验证直接获取系统最高权限，存在严重安全风险"} + +cve: ./data/2020/35xxx/CVE-2020-35185.json +The official ghost docker images before 2.16.1-alpine (Alpine specific) contain a blank password for a root user. System using the ghost docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"ghost","Reason":"容器镜像中root用户存在空密码，导致攻击者可利用此漏洞获得宿主机的root访问权限","Consequence":"远程攻击者可通过空密码以root身份登录系统，造成严重的安全泄露和系统被控风险"} + +cve: ./data/2020/35xxx/CVE-2020-35186.json +The official adminer docker images before 4.7.0-fastcgi contain a blank password for a root user. System using the adminer docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"adminer","Reason":"容器镜像中配置了root用户的空密码，导致攻击者可利用此漏洞获得系统root访问权限","Consequence":"远程攻击者可以使用空密码以root身份登录，从而完全控制系统，属于高危漏洞"} + +cve: ./data/2020/35xxx/CVE-2020-35187.json +The official telegraf docker images before 1.9.4-alpine (Alpine specific) contain a blank password for a root user. System using the telegraf docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"telegraf","Reason":"容器镜像中root用户密码为空，导致攻击者可能远程利用空密码获得root权限","Consequence":"远程攻击者可获得root访问权限，造成系统被完全控制，严重程度高"} + +cve: ./data/2020/35xxx/CVE-2020-35189.json +The official kong docker images before 1.0.2-alpine (Alpine specific) contain a blank password for a root user. System using the kong docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"kong docker image","Reason":"The container镜像中root用户密码为空，导致攻击者可以使用空密码获得root访问权限","Consequence":"远程攻击者可获得容器的root访问权限，可能导致系统被完全控制，严重程度高"} + +cve: ./data/2020/35xxx/CVE-2020-35190.json +The official plone Docker images before version of 4.3.18-alpine (Alpine specific) contain a blank password for a root user. System using the plone docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"plone","Reason":"容器镜像中root用户密码为空，导致攻击者可以使用空密码获得root权限","Consequence":"远程攻击者可利用此漏洞以root身份访问系统，造成严重安全风险"} + +cve: ./data/2020/35xxx/CVE-2020-35191.json +The official drupal docker images before 8.5.10-fpm-alpine (Alpine specific) contain a blank password for a root user. System using the drupal docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"drupal","Reason":"容器镜像中root用户密码为空，可能导致攻击者无需密码即可获得root权限","Consequence":"远程攻击者可利用此漏洞获得宿主机的完全控制权，存在极高安全风险"} + +cve: ./data/2020/35xxx/CVE-2020-35192.json +The official vault docker images before 0.11.6 contain a blank password for a root user. System using the vault docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"vault","Reason":"容器镜像中 root 用户的密码为空，导致攻击者可以使用空密码获得 root 权限","Consequence":"远程攻击者可利用此漏洞以 root 身份访问系统，造成严重安全威胁"} + +cve: ./data/2020/35xxx/CVE-2020-35193.json +The official sonarqube docker images before alpine (Alpine specific) contain a blank password for a root user. System using the sonarqube docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"sonarqube","Reason":"容器镜像中root用户的密码为空，导致攻击者可以使用空密码以root身份访问系统","Consequence":"远程攻击者可获得容器的完全控制权限，进而可能危害宿主机和其他容器，严重程度高"} + +cve: ./data/2020/35xxx/CVE-2020-35195.json +The official haproxy docker images before 1.8.18-alpine (Alpine specific) contain a blank password for a root user. System using the haproxy docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"haproxy","Reason":"The haproxy docker image deployed by affected versions may allow a remote attacker to achieve root access with a blank password.","Consequence":"Remote attacker can gain root access to the container, potentially leading to full system compromise. This is a critical severity vulnerability."} + +cve: ./data/2020/35xxx/CVE-2020-35196.json +The official rabbitmq docker images before 3.7.13-beta.1-management-alpine (Alpine specific) contain a blank password for a root user. System using the rabbitmq docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"rabbitmq","Reason":"容器镜像中root用户密码为空，可能导致攻击者利用空密码获得宿主机的根权限","Consequence":"远程攻击者可利用此漏洞以root权限访问系统，导致系统被完全控制，属于高危漏洞"} + +cve: ./data/2020/35xxx/CVE-2020-35197.json +The official memcached docker images before 1.5.11-alpine (Alpine specific) contain a blank password for a root user. System using the memcached docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"memcached","Reason":"容器镜像中root用户密码为空，可能导致攻击者通过空密码获得root访问权限","Consequence":"远程攻击者可以利用此漏洞以root身份访问系统，从而完全控制系统，严重程度高"} + +cve: ./data/2020/35xxx/CVE-2020-35462.json +Version 3.16.0 of the CoScale agent Docker image contains a blank password for the root user. Systems deployed using affected versions of the CoScale agent container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"CoScale agent","Reason":"容器镜像中root用户的密码为空，导致攻击者可以使用空密码获得root访问权限","Consequence":"远程攻击者可获得系统的完全控制权，存在严重的安全风险"} + +cve: ./data/2020/35xxx/CVE-2020-35463.json +Version 1.0.0 of the Instana Dynamic APM Docker image contains a blank password for the root user. Systems deployed using affected versions of the Instana Dynamic APM container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"Instana Dynamic APM","Reason":"容器镜像中 root 用户的密码为空，可能导致攻击者利用空密码获得 root 权限","Consequence":"远程攻击者可获得 root 访问权限，进而完全控制系统，属于高危漏洞"} + +cve: ./data/2020/35xxx/CVE-2020-35464.json +Version 1.3.0 of the Weave Cloud Agent Docker image contains a blank password for the root user. Systems deployed using affected versions of the Weave Cloud Agent container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"Weave Cloud Agent","Reason":"容器镜像中 root 用户的密码为空，可能导致攻击者利用空密码获得 root 权限","Consequence":"远程攻击者可利用此漏洞以 root 身份访问系统，造成严重安全风险"} + +cve: ./data/2020/35xxx/CVE-2020-35466.json +The Blackfire Docker image through 2020-12-14 contains a blank password for the root user. Systems deployed using affected versions of the Blackfire container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"Blackfire Docker image","Reason":"容器镜像中 root 用户的密码为空，导致攻击者可以使用空密码获得 root 权限","Consequence":"远程攻击者可利用此漏洞以 root 身份访问系统，造成严重的安全泄露和系统失控风险，属于高危漏洞"} + +cve: ./data/2020/35xxx/CVE-2020-35467.json +The Docker Docs Docker image through 2020-12-14 contains a blank password for the root user. Systems deployed using affected versions of the Docker Docs container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"Docker Docs","Reason":"容器镜像中root用户密码为空，可能导致攻击者利用空密码获得root访问权限","Consequence":"远程攻击者可以使用空密码以root身份登录，从而完全控制系统，属于高危漏洞"} + +cve: ./data/2020/35xxx/CVE-2020-35468.json +The Appbase streams Docker image 2.1.2 contains a blank password for the root user. Systems deployed using affected versions of the streams container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"Appbase streams Docker image","Reason":"The image contains a blank password for the root user, which can be exploited by a remote attacker to achieve root access without authentication.","Consequence":"Remote attackers can gain full control of the system, leading to potential data breaches, service disruption, or further lateral attacks. This is a critical severity vulnerability."} + +cve: ./data/2020/35xxx/CVE-2020-35469.json +The Software AG Terracotta Server OSS Docker image 5.4.1 contains a blank password for the root user. Systems deployed using affected versions of the Terracotta Server OSS container may allow a remote attacker to achieve root access with a blank password. + +analysis: {"Image":"Terracotta Server OSS Docker image 5.4.1","Reason":"The container image contains a blank password for the root user, which can be exploited by a remote attacker to gain root access.","Consequence":"Remote attackers can achieve root access without authentication, leading to a critical security breach with full system compromise."} + +cve: ./data/2020/5xxx/CVE-2020-5239.json +In Mailu before version 1.7, an authenticated user can exploit a vulnerability in Mailu fetchmail script and gain full access to a Mailu instance. Mailu servers that have open registration or untrusted users are most impacted. The master and 1.7 branches are patched on our git repository. All Docker images published on docker.io/mailu for tags 1.5, 1.6, 1.7 and master are patched. For detailed instructions about patching and securing the server afterwards, see https://github.com/Mailu/Mailu/issues/1354 + +analysis: {"Image":"mailu","Reason":"漏洞是由于Mailu容器镜像中的fetchmail脚本存在安全问题，允许经过身份验证的用户利用该漏洞获得对Mailu实例的完全访问权限。","Consequence":"攻击者可以借此获取对Mailu实例的完全控制，影响服务器安全性，严重程度高。"} + +cve: ./data/2020/7xxx/CVE-2020-7606.json +docker-compose-remote-api through 0.1.4 allows execution of arbitrary commands. Within 'index.js' of the package, the function 'exec(serviceName, cmd, fnStdout, fnStderr, fnExit)' uses the variable 'serviceName' which can be controlled by users without any sanitization. + +analysis: {"Image":"docker-compose-remote-api","Reason":"The vulnerability arises from unsanitized user input in the 'serviceName' variable within the 'exec' function, which can be exploited to execute arbitrary commands.","Consequence":"This CVE allows attackers to execute arbitrary commands on the host system, leading to potential system compromise and data loss. It is a critical severity vulnerability."} + +cve: ./data/2020/8xxx/CVE-2020-8553.json +The Kubernetes ingress-nginx component prior to version 0.28.0 allows a user with the ability to create namespaces and to read and create ingress objects to overwrite the password file of another ingress which uses nginx.ingress.kubernetes.io/auth-type: basic and which has a hyphenated namespace or secret name. + +analysis: {"Image":"ingress-nginx","Reason":"The vulnerability arises from the way the ingress-nginx component handles password files in namespaces with hyphenated names or secret names, which could be manipulated by a user with specific permissions.","Consequence":"An attacker could overwrite the password file of another ingress, leading to potential unauthorized access and compromise of security, with severity being high."} + +cve: ./data/2020/8xxx/CVE-2020-8907.json +A vulnerability in Google Cloud Platform's guest-oslogin versions between 20190304 and 20200507 allows a user that is only granted the role "roles/compute.osLogin" to escalate privileges to root. Using their membership to the "docker" group, an attacker with this role is able to run docker and mount the host OS. Within docker, it is possible to modify the host OS filesystem and modify /etc/groups to gain administrative privileges. All images created after 2020-May-07 (20200507) are fixed, and if you cannot update, we recommend you edit /etc/group/security.conf and remove the "docker" user from the OS Login entry. + +analysis: {"Image":"Google Cloud Platform's guest-oslogin","Reason":"该漏洞是由于容器镜像中用户被错误地赋予了docker组权限，导致可以运行docker并挂载宿主机文件系统","Consequence":"攻击者可借此将自身权限提升至root，对宿主机系统进行任意修改，后果严重"} + +cve: ./data/2020/8xxx/CVE-2020-8945.json +The proglottis Go wrapper before 0.1.1 for the GPGME library has a use-after-free, as demonstrated by use for container image pulls by Docker or CRI-O. This leads to a crash or potential code execution during GPG signature verification. + +analysis: {"Image":"container image","Reason":"The vulnerability exists in the proglottis Go wrapper used for GPGME library during container image pulls by Docker or CRI-O, which is related to the handling of operations in the container image context.","Consequence":"This leads to a crash or potential code execution during GPG signature verification."} + +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: {"Image":"Cisco DNA Spaces Connector","Reason":"漏洞是由于在执行受影响命令时未能正确对输入进行消毒，导致攻击者可以注入精心构造的输入","Consequence":"攻击者可能以root权限在Connector容器内执行任意命令，可能导致容器被完全控制，严重程度高"} + +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: {"Image":"Cisco DNA Spaces Connector","Reason":"The vulnerability is due to insufficient input sanitization when executing commands within the Docker container, allowing an attacker to inject crafted input during command execution.","Consequence":"A successful exploit could allow the attacker to execute arbitrary commands as root within the Connector docker container, leading to a complete compromise of the container environment with high severity."} + +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: {"Image":"openshift4/ose-docker-builder","Reason":"容器镜像在构建时使用chrooted环境而非runc，导致运行权限过高","Consequence":"攻击者可利用此漏洞访问底层节点的原始设备（如网络和存储设备），至少可提升权限至集群管理员级别，对数据机密性、完整性以及系统可用性造成严重威胁"} + +cve: ./data/2021/20xxx/CVE-2021-20439.json +IBM Security Access Manager 9.0 and IBM Security Verify Access Docker 10.0.0 stores user credentials in plain clear text which can be read by an unauthorized user. + +analysis: {"Image":"IBM Security Access Manager 9.0 and IBM Security Verify Access Docker 10.0.0","Reason":"Stores user credentials in plain clear text","Consequence":"User credentials can be read by unauthorized users, leading to potential security breaches."} + +cve: ./data/2021/20xxx/CVE-2021-20497.json +IBM Security Verify Access Docker 10.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 197969 + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"使用了比预期弱的加密算法","Consequence":"可能导致攻击者解密高度敏感信息，存在严重安全风险"} + +cve: ./data/2021/20xxx/CVE-2021-20498.json +IBM Security Verify Access Docker 10.0.0 reveals version information in HTTP requests that could be used in further attacks against the system. IBM X-Force ID: 197972. + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"The vulnerability is introduced in the container image where version information is exposed in HTTP requests, which could be exploited by attackers to gain insights for further attacks.","Consequence":"Exposure of internal version details can lead to targeted exploitation, potentially compromising system security. This issue poses a moderate to high risk depending on the deployment environment."} + +cve: ./data/2021/20xxx/CVE-2021-20499.json +IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 197973 + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像配置不当导致详细技术错误信息泄露","Consequence":"敏感信息泄露，可能被用于对系统的进一步攻击，严重程度中等到高"} + +cve: ./data/2021/20xxx/CVE-2021-20500.json +IBM Security Verify Access Docker 10.0.0 could reveal highly sensitive information to a local privileged user. IBM X-Force ID: 197980. + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中存在安全漏洞可能导致敏感信息泄露","Consequence":"本地特权用户可能获取高度敏感信息，造成信息泄露，严重程度高"} + +cve: ./data/2021/20xxx/CVE-2021-20510.json +IBM Security Verify Access Docker 10.0.0 stores user credentials in plain clear text which can be read by a local user. IBM X-Force ID: 198299 + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中以明文形式存储用户凭证，这些信息可被本地用户读取","Consequence":"攻击者可以获取敏感的用户凭证信息，进而可能导致进一步的安全威胁，例如身份冒充和数据泄露。CVSS评分为中高风险。"} + +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: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中对URL请求的'../'序列处理不当，导致攻击者可构造恶意请求访问任意文件","Consequence":"攻击者可以遍历目录并访问系统上的任意文件，可能导致敏感信息泄露，严重程度高"} + +cve: ./data/2021/20xxx/CVE-2021-20523.json +IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 198660 + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像在处理错误信息时返回了详细的敏感技术信息","Consequence":"攻击者可利用该信息发起进一步攻击，存在安全风险"} + +cve: ./data/2021/20xxx/CVE-2021-20524.json +IBM Security Verify Access Docker 10.0.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 198661. + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中的Web UI存在跨站脚本漏洞，允许攻击者嵌入恶意JavaScript代码","Consequence":"可能导致在可信会话中泄露用户凭证，存在安全风险"} + +cve: ./data/2021/20xxx/CVE-2021-20533.json +IBM Security Verify Access Docker 10.0.0 could allow a remote authenticated attacker to execute arbitrary commands on the system by sending a specially crafted request. IBM X-Force ID: 198813 + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"CVE描述中提到该漏洞存在于IBM Security Verify Access Docker 10.0.0版本中，表明是容器镜像引入的问题","Consequence":"远程认证攻击者可以通过发送特制请求在系统上执行任意命令，这可能导致完全的系统控制权丧失，严重程度高"} + +cve: ./data/2021/20xxx/CVE-2021-20534.json +IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to conduct phishing attacks, using an open redirect attack. By persuading a victim to visit a specially crafted Web site, a remote attacker could exploit this vulnerability to spoof the URL displayed to redirect a user to a malicious Web site that would appear to be trusted. This could allow the attacker to obtain highly sensitive information or conduct further attacks against the victim. IBM X-Force ID: 198814 + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中存在开放重定向漏洞，可被远程攻击者利用进行网络钓鱼攻击","Consequence":"攻击者可欺骗用户访问恶意网站，导致敏感信息泄露或进一步的攻击，严重程度高"} + +cve: ./data/2021/20xxx/CVE-2021-20537.json +IBM Security Verify Access Docker 10.0.0 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. IBM X-Force ID:198918 + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中包含硬编码凭证（如密码或加密密钥），这些凭证用于自身的入站认证、与外部组件的出站通信或内部数据加密","Consequence":"攻击者可能利用这些硬编码凭证获取未授权访问权限，进而导致敏感信息泄露或系统被恶意控制，严重程度高"} + +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: ```json +{ + "Image": "bitnami/laravel", + "Reason": "容器镜像构建时生成的 /tmp/app/.env 文件中固定了 APP_KEY 的值，未在容器运行时动态生成随机密钥。", + "Consequence": "攻击者若获取到固定的 APP_KEY，可以利用该密钥构造恶意 cookie 值，进而通过 PHP 对象序列化/反序列化漏洞执行任意类方法，导致严重的安全风险。此漏洞影响较大，可能造成远程代码执行或会话伪造等后果。" +} +``` + +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: {"Image":"docker-cli-js","Reason":"The CVE is introduced due to the Docker.command method allowing user-controlled input to execute arbitrary OS commands","Consequence":"Remote code execution on the host system, leading to a critical security risk"} + +cve: ./data/2021/27xxx/CVE-2021-27886.json +rakibtg Docker Dashboard before 2021-02-28 allows command injection in backend/utilities/terminal.js via shell metacharacters in the command parameter of an API request. NOTE: this is NOT a Docker, Inc. product. + +analysis: {"Image":"rakibtg Docker Dashboard","Reason":"该CVE是由于容器镜像中包含的程序在处理API请求时未正确过滤特殊字符，导致攻击者可以注入恶意命令。","Consequence":"远程攻击者可以通过构造特定请求以执行任意命令，可能导致系统被控制，严重程度较高。"} + +cve: ./data/2021/29xxx/CVE-2021-29251.json +BTCPay Server before 1.0.7.1 mishandles the policy setting in which users can register (in Server Settings > Policies). This affects Docker use cases in which a mail server is configured. + +analysis: {"Image":"BTCPay Server","Reason":"The vulnerability arises from misconfiguration in the container image's policy handling when a mail server is configured in Docker use cases","Consequence":"Unauthenticated users may be able to register, leading to potential unauthorized access and security breaches. This affects the application's integrity and confidentiality."} + +cve: ./data/2021/29xxx/CVE-2021-29475.json +HedgeDoc (formerly known as CodiMD) is an open-source collaborative markdown editor. An attacker is able to receive arbitrary files from the file system when exporting a note to PDF. Since the code injection has to take place as note content, there fore this exploit requires the attackers ability to modify a note. This will affect all instances, which have pdf export enabled. This issue has been fixed by https://github.com/hedgedoc/hedgedoc/commit/c1789474020a6d668d616464cb2da5e90e123f65 and is available in version 1.5.0. Starting the CodiMD/HedgeDoc instance with `CMD_ALLOW_PDF_EXPORT=false` or set `"allowPDFExport": false` in config.json can mitigate this issue for those who cannot upgrade. This exploit works because while PhantomJS doesn't actually render the `file:///` references to the PDF file itself, it still uses them internally, and exfiltration is possible, and easy through JavaScript rendering. The impact is pretty bad, as the attacker is able to read the CodiMD/HedgeDoc `config.json` file as well any other files on the filesystem. Even though the suggested Docker deploy option doesn't have many interesting files itself, the `config.json` still often contains sensitive information, database credentials, and maybe OAuth secrets among other things. + +analysis: {"Image":"CodiMD/HedgeDoc","Reason":"The CVE is introduced through the application's functionality to export notes to PDF using PhantomJS, which allows attackers to read arbitrary files from the file system when exploiting this vulnerability.","Consequence":"Attackers can exfiltrate sensitive files such as config.json, which may contain database credentials, OAuth secrets, and other critical information, leading to potential data breaches and unauthorized access."} + +cve: ./data/2021/29xxx/CVE-2021-29641.json +Directus 8 before 8.8.2 allows remote authenticated users to execute arbitrary code because file-upload permissions include the ability to upload a .php file to the main upload directory and/or upload a .php file and a .htaccess file to a subdirectory. Exploitation succeeds only for certain installations with the Apache HTTP Server and the local-storage driver (e.g., when the product was obtained from hub.docker.com). + +analysis: {"Image":"directus","Reason":"容器镜像中文件上传权限配置不当，允许上传恶意PHP文件","Consequence":"远程认证用户可上传恶意文件并执行任意代码，导致系统被控制，严重程度高"} + +cve: ./data/2021/29xxx/CVE-2021-29699.json +IBM Security Verify Access Docker 10.0.0 could allow a remote priviled user to upload arbitrary files with a dangerous file type that could be excuted by an user. IBM X-Force ID: 200600. + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像允许远程特权用户上传可由用户执行的危险文件类型","Consequence":"该CVE可能导致任意文件上传和执行，从而导致安全漏洞，严重程度高"} + +cve: ./data/2021/29xxx/CVE-2021-29742.json +IBM Security Verify Access Docker 10.0.0 could allow a user to impersonate another user on the system. IBM X-Force ID: 201483. + +analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中存在用户身份验证缺陷，可能导致用户身份被冒充","Consequence":"攻击者可以利用此漏洞伪装成其他用户，进而进行未授权访问或执行恶意操作，属于高危漏洞"} + +cve: ./data/2021/31xxx/CVE-2021-31821.json +When the Windows Tentacle docker image starts up it logs all the commands that it runs along with the arguments, which writes the Octopus Server API key in plaintext. This does not affect the Linux Docker image + +analysis: {"Image":"Windows Tentacle docker image","Reason":"The vulnerability is introduced due to logging of command-line arguments in plaintext at startup, which includes the Octopus Server API key","Consequence":"Exposure of sensitive API key information in logs, leading to potential unauthorized access; this affects only the Windows Docker image"} + +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: {"Image":"Synology Docker","Reason":"Path Traversal漏洞允许本地用户通过未指定的向量读取或写入任意文件","Consequence":"攻击者可以利用此漏洞绕过目录访问限制，可能导致敏感信息泄露或系统文件被篡改，严重程度较高"} + +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: {"Image":"Mintzo Docker-Tester","Reason":"该CVE是由于在容器镜像中对docker-compose.yml文件的'ports'条目处理不当，导致攻击者可以注入shell元字符执行任意命令","Consequence":"攻击者可以执行任意命令，从而可能导致系统被完全控制，严重程度高"} + +cve: ./data/2021/35xxx/CVE-2021-35497.json +The FTL Server (tibftlserver) and Docker images containing tibftlserver components of TIBCO Software Inc.'s TIBCO ActiveSpaces - Community Edition, TIBCO ActiveSpaces - Developer Edition, TIBCO ActiveSpaces - Enterprise Edition, TIBCO FTL - Community Edition, TIBCO FTL - Developer Edition, TIBCO FTL - Enterprise Edition, TIBCO eFTL - Community Edition, TIBCO eFTL - Developer Edition, and TIBCO eFTL - Enterprise Edition contain a vulnerability that theoretically allows a non-administrative, authenticated FTL user to trick the affected components into creating illegitimate certificates. These maliciously generated certificates can be used to enable man-in-the-middle attacks or to escalate privileges so that the malicious user has administrative privileges. Affected releases are TIBCO Software Inc.'s TIBCO ActiveSpaces - Community Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO ActiveSpaces - Developer Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO ActiveSpaces - Enterprise Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO FTL - Community Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO FTL - Developer Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO FTL - Enterprise Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO eFTL - Community Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO eFTL - Developer Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, and TIBCO eFTL - Enterprise Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0. + +analysis: {"Image":"tibftlserver","Reason":"The vulnerability exists in the FTL Server (tibftlserver) and Docker images containing tibftlserver components, where a non-administrative, authenticated FTL user can trick the affected components into generating illegitimate certificates.","Consequence":"These malicious certificates can enable man-in-the-middle attacks or privilege escalation, allowing the attacker to gain administrative privileges. This is a high-severity security issue."} + +cve: ./data/2021/37xxx/CVE-2021-37353.json +Nagios XI Docker Wizard before version 1.1.3 is vulnerable to SSRF due to improper sanitation in table_population.php. + +analysis: {"Image":"Nagios XI Docker Wizard","Reason":"Improper sanitation in table_population.php could lead to Server Side Request Forgery (SSRF)","Consequence":"An attacker could potentially exploit this vulnerability to perform unauthorized requests, leading to data exposure or further attacks. This poses a significant security risk."} + +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: {"Image":"BinderHub","Reason":"BinderHub的远程代码执行漏洞源于处理恶意输入时在BinderHub上下文中执行代码","Consequence":"攻击者可以窃取BinderHub部署中的凭证（如JupyterHub API令牌、Kubernetes服务账户和Docker注册表凭据），从而操控镜像和其他用户创建的Pod，严重程度高，可能进一步升级到主机"} + +cve: ./data/2021/39xxx/CVE-2021-39939.json +An uncontrolled resource consumption vulnerability in GitLab Runner affecting all versions starting from 13.7 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, allows an attacker triggering a job with a specially crafted docker image to exhaust resources on runner manager + +analysis: {"Image":"GitLab Runner","Reason":"触发一个经过特殊构建的docker镜像作业导致资源消耗","Consequence":"攻击者可耗尽runner manager上的系统资源（如CPU或内存），可能导致服务不可用，严重程度高。"} + +cve: ./data/2021/3xxx/CVE-2021-3193.json +Improper access and command validation in the Nagios Docker Config Wizard before 1.1.2, as used in Nagios XI through 5.7, allows an unauthenticated attacker to execute remote code as the apache user. + +analysis: {"Image":"Nagios Docker Config Wizard","Reason":"Improper access and command validation during container configuration allows unauthenticated attackers to exploit the vulnerability.","Consequence":"Remote code execution as the apache user, which can lead to full system compromise. This is a critical severity issue."} + +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: {"Image":"Buildah","Reason":"容器构建过程中通过chroot隔离运行时，子进程可以访问父进程和祖父进程的环境变量","Consequence":"可能导致敏感信息（如容器仓库凭证）泄露，严重程度中等至高危，尤其在CI/CD环境中"} + +cve: ./data/2021/41xxx/CVE-2021-41092.json +Docker CLI is the command line interface for the docker container runtime. A bug was found in the Docker CLI where running `docker login my-private-registry.example.com` with a misconfigured configuration file (typically `~/.docker/config.json`) listing a `credsStore` or `credHelpers` that could not be executed would result in any provided credentials being sent to `registry-1.docker.io` rather than the intended private registry. This bug has been fixed in Docker CLI 20.10.9. Users should update to this version as soon as possible. For users unable to update ensure that any configured credsStore or credHelpers entries in the configuration file reference an installed credential helper that is executable and on the PATH. + +analysis: {"Image":"docker-cli","Reason":"The CVE is introduced due to a misconfiguration in the Docker CLI's credential handling process when interacting with private registries, which could be triggered by a flawed configuration in the container image.","Consequence":"Credentials intended for a private registry may be mistakenly sent to `registry-1.docker.io`, leading to potential exposure of sensitive authentication information. This poses a serious security risk, especially in environments where private registry credentials are used frequently."} + +cve: ./data/2021/41xxx/CVE-2021-41130.json +Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management capabilities for JSON/REST or gRPC API services. ESPv1 can be configured to authenticate a JWT token. Its verified JWT claim is passed to the application by HTTP header "X-Endpoint-API-UserInfo", the application can use it to do authorization. But if there are two "X-Endpoint-API-UserInfo" headers from the client, ESPv1 only replaces the first one, the 2nd one will be passed to the application. An attacker can send two "X-Endpoint-API-UserInfo" headers, the second one with a fake JWT claim. Application may use the fake JWT claim to do the authorization. This impacts following ESPv1 usages: 1) Users have configured ESPv1 to do JWT authentication with Google ID Token as described in the referenced google endpoint document. 2) Users backend application is using the info in the "X-Endpoint-API-UserInfo" header to do the authorization. It has been fixed by v1.58.0. You need to patch it in the following ways: * If your docker image is using tag ":1", needs to re-start the container to pick up the new version. The tag ":1" will automatically point to the latest version. * If your docker image tag pings to a specific minor version, e.g. ":1.57". You need to update it to ":1.58" and re-start the container. There are no workaround for this issue. + +analysis: {"Image":"Extensible Service Proxy (ESPv1)","Reason":"The vulnerability arises when the ESPv1 proxy is configured in a Docker container and fails to properly handle duplicate 'X-Endpoint-API-UserInfo' headers, allowing a fake JWT claim to be passed to the application.","Consequence":"An attacker can bypass authorization by injecting a malicious 'X-Endpoint-API-UserInfo' header, leading to potential privilege escalation or unauthorized access. This issue affects containers using vulnerable ESPv1 versions and is only mitigated by upgrading to v1.58.0."} + +cve: ./data/2021/41xxx/CVE-2021-41254.json +kustomize-controller is a Kubernetes operator, specialized in running continuous delivery pipelines for infrastructure and workloads defined with Kubernetes manifests and assembled with Kustomize. Users that can create Kubernetes Secrets, Service Accounts and Flux Kustomization objects, could execute commands inside the kustomize-controller container by embedding a shell script in a Kubernetes Secret. This can be used to run `kubectl` commands under the Service Account of kustomize-controller, thus allowing an authenticated Kubernetes user to gain cluster admin privileges. In affected versions multitenant environments where non-admin users have permissions to create Flux Kustomization objects are affected by this issue. This vulnerability was fixed in kustomize-controller v0.15.0 (included in flux2 v0.18.0) released on 2021-10-08. Starting with v0.15, the kustomize-controller no longer executes shell commands on the container OS and the `kubectl` binary has been removed from the container image. To prevent the creation of Kubernetes Service Accounts with `secrets` in namespaces owned by tenants, a Kubernetes validation webhook such as Gatekeeper OPA or Kyverno can be used. + +analysis: {"Image":"kustomize-controller","Reason":"The vulnerability arises from the kustomize-controller container allowing execution of shell scripts via embedded Kubernetes Secrets, and executing `kubectl` commands under its Service Account.","Consequence":"An authenticated Kubernetes user could exploit this to gain cluster admin privileges, leading to a critical security breach in multitenant environments."} + +cve: ./data/2021/43xxx/CVE-2021-43842.json +Wiki.js is a wiki app built on Node.js. Wiki.js versions 2.5.257 and earlier are vulnerable to stored cross-site scripting through a SVG file upload. By creating a crafted SVG file, a malicious Wiki.js user may stage a stored cross-site scripting attack. This allows the attacker to execute malicious JavaScript when the SVG is viewed directly by other users. Scripts do not execute when loaded inside a page via normal `` tags. Commit 5d3e81496fba1f0fbd64eeb855f30f69a9040718 fixes this vulnerability by adding an optional (enabled by default) SVG sanitization step to all file uploads that match the SVG mime type. As a workaround, disable file upload for all non-trusted users. Wiki.js version 2.5.260 is the first production version to contain a patch. Version 2.5.258 is the first development build to contain a patch and is available only as a Docker image as requarks/wiki:canary-2.5.258. + +analysis: {"Image":"requarks/wiki","Reason":"The vulnerability arises from improper handling of SVG file uploads in the Wiki.js application, which could be exploited through a crafted SVG file uploaded by a malicious user.","Consequence":"Successful exploitation allows an attacker to perform stored cross-site scripting (XSS), leading to execution of malicious JavaScript when the SVG is viewed directly by other users. This can compromise user sessions or perform other malicious actions within the context of the affected application."} + +cve: ./data/2021/45xxx/CVE-2021-45414.json +A Remote Code Execution (RCE) vulnerability exists in DataRobot through 2021-10-28 because it allows submission of a Docker environment or Java driver. + +analysis: {"Image":"DataRobot","Reason":"容器镜像允许提交恶意Docker环境或Java驱动程序","Consequence":"攻击者可利用该漏洞执行远程代码，导致系统被控制，严重程度高"} + +cve: ./data/2022/20xxx/CVE-2022-20617.json +Jenkins Docker Commons Plugin 1.17 and earlier does not sanitize the name of an image or a tag, resulting in an OS command execution vulnerability exploitable by attackers with Item/Configure permission or able to control the contents of a previously configured job's SCM repository. + +analysis: {"Image":"Jenkins Docker Commons Plugin","Reason":"插件未对镜像或标签名称进行正确清理，可能导致恶意命令执行","Consequence":"攻击者可以执行任意操作系统命令，可能导致系统被完全控制，严重程度高"} + +cve: ./data/2022/22xxx/CVE-2022-22984.json +The package snyk before 1.1064.0; the package snyk-mvn-plugin before 2.31.3; the package snyk-gradle-plugin before 3.24.5; the package @snyk/snyk-cocoapods-plugin before 2.5.3; the package snyk-sbt-plugin before 2.16.2; the package snyk-python-plugin before 1.24.2; the package snyk-docker-plugin before 5.6.5; the package @snyk/snyk-hex-plugin before 1.1.6 are vulnerable to Command Injection due to an incomplete fix for [CVE-2022-40764](https://security.snyk.io/vuln/SNYK-JS-SNYK-3037342). A successful exploit allows attackers to run arbitrary commands on the host system where the Snyk CLI is installed by passing in crafted command line flags. In order to exploit this vulnerability, a user would have to execute the snyk test command on untrusted files. In most cases, an attacker positioned to control the command line arguments to the Snyk CLI would already be positioned to execute arbitrary commands. However, this could be abused in specific scenarios, such as continuous integration pipelines, where developers can control the arguments passed to the Snyk CLI to leverage this component as part of a wider attack against an integration/build pipeline. This issue has been addressed in the latest Snyk Docker images available at https://hub.docker.com/r/snyk/snyk as of 2022-11-29. Images downloaded and built prior to that date should be updated. The issue has also been addressed in the Snyk TeamCity CI/CD plugin as of version v20221130.093605. + +analysis: {"Image":"snyk/snyk","Reason":"该CVE是由于Snyk CLI在处理命令行参数时存在命令注入漏洞，而该CLI被包含在容器镜像中。攻击者可通过构造恶意参数执行任意命令","Consequence":"攻击者可以利用此漏洞在运行该容器并执行snyk test命令时，在宿主机上执行任意命令，从而对CI/CD流水线造成严重安全威胁，属于高危漏洞"} + +cve: ./data/2022/23xxx/CVE-2022-23126.json +TeslaMate before 1.25.1 (when using the default Docker configuration) allows attackers to open doors of Tesla vehicles, start Keyless Driving, and interfere with vehicle operation en route. This occurs because an attacker can leverage Grafana login access to obtain a token for Tesla API calls. + +analysis: {"Image":"TeslaMate","Reason":"The vulnerability exists in TeslaMate's default Docker configuration, where an attacker can exploit Grafana login access to obtain a token for Tesla API calls","Consequence":"Attackers can open Tesla vehicle doors, start Keyless Driving, and interfere with vehicle operation, leading to serious security and safety risks"} + +cve: ./data/2022/24xxx/CVE-2022-24799.json +wire-webapp is the web application interface for the wire messaging service. Insufficient escaping in markdown “code highlighting” in the wire-webapp resulted in the possibility of injecting and executing arbitrary HTML code and thus also JavaScript. If a user receives and views such a malicious message, arbitrary code is injected and executed in the context of the victim. This allows the attacker to fully control the user account. Wire-desktop clients that are connected to a vulnerable wire-webapp version are also vulnerable to this attack. The issue has been fixed in wire-webapp 2022-03-30-production.0 and is already deployed on all Wire managed services. On-premise instances of wire-webapp need to be updated to docker tag 2022-03-30-production.0-v0.29.2-0-d144552 or wire-server 2022-03-30 (chart/4.8.0), so that their applications are no longer affected. There are no known workarounds for this issue. ### Patches * The issue has been fixed in wire-webapp **2022-03-30-production.0** and is already deployed on all Wire managed services. * On-premise instances of wire-webapp need to be updated to docker tag **2022-03-30-production.0-v0.29.2-0-d144552** or wire-server **2022-03-30 (chart/4.8.0)**, so that their applications are no longer affected. ### Workarounds * No workarounds known ### For more information If you have any questions or comments about this advisory feel free to email us at [vulnerability-report@wire.com](mailto:vulnerability-report@wire.com) ### Credits We thank [Posix](https://twitter.com/po6ix) for reporting this vulnerability + +analysis: {"Image":"wire-webapp","Reason":"Insufficient escaping in markdown code highlighting allows injection and execution of arbitrary HTML/JavaScript code","Consequence":"Attackers can fully control the user account by injecting malicious code when a user views a crafted message; affects both web and desktop clients connected to vulnerable versions"} + +cve: ./data/2022/25xxx/CVE-2022-25365.json +Docker Desktop before 4.5.1 on Windows allows attackers to move arbitrary files. NOTE: this issue exists because of an incomplete fix for CVE-2022-23774. + +analysis: {"Image":"Docker Desktop","Reason":"容器镜像创建或处理文件时存在安全缺陷，攻击者可利用该缺陷移动任意文件","Consequence":"可能导致宿主机上的文件被非法操作，造成数据泄露或破坏，严重程度高"} + +cve: ./data/2022/25xxx/CVE-2022-25914.json +The package com.google.cloud.tools:jib-core before 0.22.0 are vulnerable to Remote Code Execution (RCE) via the isDockerInstalled function, due to attempting to execute input. + +analysis: {"Image":"[com.google.cloud.tools:jib-core]","Reason":"[The vulnerability arises when the container image uses jib-core package before version 0.22.0, which attempts to execute input in the isDockerInstalled function]","Consequence":"[This CVE allows Remote Code Execution (RCE), which can lead to unauthorized code execution within the container or host system. This is a critical severity vulnerability]"} + +cve: ./data/2022/27xxx/CVE-2022-27651.json +A flaw was found in buildah where containers were incorrectly started with non-empty default permissions. A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, enabling an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs. This has the potential to impact confidentiality and integrity. + +analysis: {"Image":"buildah","Reason":"容器可能被错误地启动了非空的默认权限，导致攻击者可以利用可继承的文件功能提升其能力","Consequence":"可能导致保密性和完整性的损害，存在安全风险"} + diff --git a/build_ai_analysis.py b/build_ai_analysis.py new file mode 100644 index 0000000..2541b21 --- /dev/null +++ b/build_ai_analysis.py @@ -0,0 +1,84 @@ +# 分析每个CVE源自哪个应用程序、什么原因、什么后果等信息 + +from os import truncate +import re +import json +from openai import OpenAI +from typing import Dict, List, Any + + +def process_result(data: Any) -> str: + # target_key = "choices.0.message.content" + parts = ["choices", "0", "message", "content"] + try: + for part in parts: + if isinstance(data, list): + data = data[int(part)] + else: + data = data.get(part, None) + if data is None: + break + return data + except (KeyError, IndexError, TypeError): + return "N/A" + return "N/A" + + +def analyze_with_ai(data: str) -> str: + prompt = """ + 你是一个计算机容器安全领域的专家，能够根据CVE描述分析出CVE产生于哪个程序、有何影响后果等信息。 + 下面我会发给你一段文本，第一行是CVE的编号与文件位置信息，后续是这个CVE的详细描述。 + 请分析我发送给你的CVE详细描述内容，并进行分析，我有如下要求： + 1. 分析这个CVE信息，判断这个CVE漏洞是否是由于在构建容器镜像过程中由Dockerfile或其他脚本引入的； + 2. 如果不满足条件1，你只需返回"N/A"即可，无需任何多余信息； + 3. 如果这个CVE满足条件1，那么你只需要直接返回一个json，这个json样例如下： + {"Conatiner":"[存在CVE的容器镜像]","CVE_Reason"："[容器泄漏或未妥善保护的文件、密钥等敏感信息类型]"，"CVE_Consequence":"[该CVE的后果，以及严重程度]"} + 请牢记，你必须只返回json内容，除了json不需要任何文本内容，并且尽量使用中文。 + """ + + client = OpenAI( + api_key="sk-5ec7751941974a9cb5855f746fe45a62", + base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", + ) + try: + completion = client.chat.completions.create( + # 模型列表：https://help.aliyun.com/zh/model-studio/getting-started/models + model="qwen-plus", + messages=[ + {"role": "system", "content": prompt}, + {"role": "user", "content": data}, + ], + # Qwen3模型通过enable_thinking参数控制思考过程（开源版默认True，商业版默认False） + # 使用Qwen3开源版模型时，若未启用流式输出，请将下行取消注释，否则会报错 + # extra_body={"enable_thinking": False}, + ) + return process_result(json.loads(completion.model_dump_json())) + except Exception as e: + print(f"调用大模型失败: {str(e)}") + return "N/A" + return "N/A" + + +if __name__ == "__main__": + pattern = r"\./data/.*x/CVE.*?\.json" + regex = re.compile(pattern) + + with open("keyword_filter_21-25.log", "r", encoding="utf-8") as file: + text = file.read() + matches = list(regex.finditer(text)) + + log = open("./build_result/analysis_result_21-25.log", "w", encoding="utf-8") + + # 如果没有找到任何匹配项 + if not matches: + print("No match found.") + else: + for i in range(len(matches)): + start = matches[i].start() + # 如果不是最后一个匹配项，则end是下一个匹配项的起始位置；否则为文本末尾 + end = matches[i + 1].start() if i + 1 < len(matches) else len(text) + block = text[start:end].strip() + ans = analyze_with_ai(block) + if ans == "N/A": + continue + log.write(f"cve: {block}\n\nanalysis: {ans}\n\n") diff --git a/build_result/analysis_result_21-25.log b/build_result/analysis_result_21-25.log new file mode 100644 index 0000000..d0be8bb --- /dev/null +++ b/build_result/analysis_result_21-25.log @@ -0,0 +1,305 @@ +cve: ./data/2021/20xxx/CVE-2021-20439.json +IBM Security Access Manager 9.0 and IBM Security Verify Access Docker 10.0.0 stores user credentials in plain clear text which can be read by an unauthorized user. + +analysis: {"Conatiner":"IBM Security Access Manager 9.0, IBM Security Verify Access Docker 10.0.0","CVE_Reason":"存储的用户凭据未加密，以明文形式保存","CVE_Consequence":"未经授权的用户可以读取这些凭据，可能导致账户被入侵或数据泄露，严重程度高"} + +cve: ./data/2021/20xxx/CVE-2021-20500.json +IBM Security Verify Access Docker 10.0.0 could reveal highly sensitive information to a local privileged user. IBM X-Force ID: 197980. + +analysis: {"Conatiner":"IBM Security Verify Access Docker 10.0.0","CVE_Reason":"高度敏感信息未妥善保护，可能被本地特权用户访问","CVE_Consequence":"可能导致敏感信息泄露，严重程度高"} + +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: {"Conatiner":"IBM Security Verify Access Docker 10.0.0","CVE_Reason":"目录遍历漏洞，未对用户输入的路径进行严格校验","CVE_Consequence":"攻击者可以通过构造特殊URL访问系统上的任意文件，严重程度：高"} + +cve: ./data/2021/20xxx/CVE-2021-20537.json +IBM Security Verify Access Docker 10.0.0 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. IBM X-Force ID:198918 + +analysis: {"Conatiner":"IBM Security Verify Access Docker 10.0.0","CVE_Reason":"硬编码的凭据，如密码或加密密钥","CVE_Consequence":"攻击者可能利用硬编码的凭据绕过安全机制，获取敏感信息或未经授权访问系统资源，严重程度高"} + +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/" 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: {"Conatiner":"Docker","CVE_Reason":"未正确处理--userns-remap选项导致容器内的root用户可以访问并修改宿主机文件系统下的敏感文件","CVE_Consequence":"攻击者可以通过此漏洞从容器内提升至宿主机的root权限，严重程度：高"} + +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: ```json +{"Conatiner":"bitnami/laravel","CVE_Reason":"容器构建过程中生成的/tmp/app/.env文件中，APP_KEY值在特定条件下固定，未随机生成","CVE_Consequence":"攻击者可能利用该密钥伪造cookie值，并通过PHP对象序列化/反序列化漏洞调用应用程序内的任意类方法，导致严重安全风险"} +``` + +cve: ./data/2021/31xxx/CVE-2021-31821.json +When the Windows Tentacle docker image starts up it logs all the commands that it runs along with the arguments, which writes the Octopus Server API key in plaintext. This does not affect the Linux Docker image + +analysis: {"Conatiner":"Windows Tentacle docker image","CVE_Reason":"容器启动时记录了所有运行的命令及其参数，导致Octopus Server API密钥以明文形式泄露","CVE_Consequence":"可能导致API密钥被未授权访问，严重程度：高"} + +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: {"Conatiner":"Docker Desktop Windows容器镜像","CVE_Reason":"错误的访问控制配置，导致低权限账户可访问容器服务器","CVE_Consequence":"可能导致容器完全被攻破，包括进程隔离和Hyper-V隔离模式，攻击者可读取、写入甚至执行容器内部代码，严重程度高"} + +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: {"Container":"Buildah","CVE_Reason":"容器构建过程中未妥善保护的环境变量","CVE_Consequence":"可能导致敏感信息（如容器镜像仓库凭据）泄露，严重程度较高"} + +cve: ./data/2021/41xxx/CVE-2021-41092.json +Docker CLI is the command line interface for the docker container runtime. A bug was found in the Docker CLI where running `docker login my-private-registry.example.com` with a misconfigured configuration file (typically `~/.docker/config.json`) listing a `credsStore` or `credHelpers` that could not be executed would result in any provided credentials being sent to `registry-1.docker.io` rather than the intended private registry. This bug has been fixed in Docker CLI 20.10.9. Users should update to this version as soon as possible. For users unable to update ensure that any configured credsStore or credHelpers entries in the configuration file reference an installed credential helper that is executable and on the PATH. + +analysis: {"Conatiner":"Docker CLI","CVE_Reason":"容器镜像构建过程中，由于Dockerfile或脚本未正确配置~/.docker/config.json文件，导致凭证存储或助手工具不可执行。","CVE_Consequence":"提供的凭据可能被错误发送到非目标的公共 registry（如 registry-1.docker.io），可能导致敏感信息泄露，严重程度为高。"} + +cve: ./data/2021/45xxx/CVE-2021-45449.json +Docker Desktop version 4.3.0 and 4.3.1 has a bug that may log sensitive information (access token or password) on the user's machine during login. This only affects users if they are on Docker Desktop 4.3.0, 4.3.1 and the user has logged in while on 4.3.0, 4.3.1. Gaining access to this data would require having access to the user’s local files. + +analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"登录过程中未妥善保护的访问令牌或密码","CVE_Consequence":"可能导致用户敏感信息泄露，严重程度为中等"} + +cve: ./data/2022/23xxx/CVE-2022-23774.json +Docker Desktop before 4.4.4 on Windows allows attackers to move arbitrary files. + +analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未对文件移动操作进行妥善限制","CVE_Consequence":"攻击者可以在Windows系统上任意移动文件，可能导致敏感信息泄露或系统破坏，严重程度高"} + +cve: ./data/2022/25xxx/CVE-2022-25365.json +Docker Desktop before 4.5.1 on Windows allows attackers to move arbitrary files. NOTE: this issue exists because of an incomplete fix for CVE-2022-23774. + +analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未妥善修复的文件移动漏洞，允许攻击者移动任意文件","CVE_Consequence":"可能导致敏感文件泄露或系统文件被篡改，严重程度较高"} + +cve: ./data/2022/26xxx/CVE-2022-26659.json +Docker Desktop installer on Windows in versions before 4.6.0 allows an attacker to overwrite any administrator writable files by creating a symlink in place of where the installer writes its log file. Starting from version 4.6.0, the Docker Desktop installer, when run elevated, will write its log files to a location not writable by non-administrator users. + +analysis: {"Conatiner":"Docker Desktop Windows 容器环境","CVE_Reason":"未正确处理日志文件写入路径，导致符号链接攻击漏洞","CVE_Consequence":"允许攻击者覆盖任何管理员可写的文件，可能导致系统文件破坏或恶意代码植入，严重程度高"} + +cve: ./data/2022/27xxx/CVE-2022-27651.json +A flaw was found in buildah where containers were incorrectly started with non-empty default permissions. A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, enabling an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs. This has the potential to impact confidentiality and integrity. + +analysis: {"Conatiner":"[Moby (Docker Engine)、Buildah构建的容器镜像]","CVE_Reason"："[容器启动时未正确设置默认权限及继承的Linux进程能力]","CVE_Consequence":"[可能导致攻击者提升权限，影响系统机密性和完整性，严重程度较高]"} + +cve: ./data/2022/29xxx/CVE-2022-29186.json +Rundeck is an open source automation service with a web console, command line tools and a WebAPI. Rundeck community and rundeck-enterprise docker images contained a pre-generated SSH keypair. If the id_rsa.pub public key of the keypair was copied to authorized_keys files on remote host, those hosts would allow access to anyone with the exposed private credentials. This misconfiguration only impacts Rundeck Docker instances of PagerDuty® Process Automation On Prem (formerly Rundeck) version 4.0 and earlier, not Debian, RPM or .WAR. Additionally, the id_rsa.pub file would have to be copied from the Docker image filesystem contents without overwriting it and used to configure SSH access on a host. A patch on Rundeck's `main` branch has removed the pre-generated SSH key pair, but it does not remove exposed keys that have been configured. To patch, users must run a script on hosts in their environment to search for exposed keys and rotate them. Two workarounds are available: Do not use any pre-existing public key file from the rundeck docker images to allow SSH access by adding it to authorized_keys files and, if you have copied the public key file included in the docker image, remove it from any authorized_keys files. + +analysis: {"Conatiner":"Rundeck社区版和Rundeck-Enterprise Docker镜像","CVE_Reason":"预生成的SSH密钥对未妥善保护","CVE_Consequence":"可能导致远程主机被未经授权的访问，严重程度为高"} + +cve: ./data/2022/31xxx/CVE-2022-31647.json +Docker Desktop before 4.6.0 on Windows allows attackers to delete any file through the hyperv/destroy dockerBackendV2 API via a symlink in the DataFolder parameter, a different vulnerability than CVE-2022-26659. + +analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未对DataFolder参数中的符号链接进行妥善处理，导致任意文件删除漏洞","CVE_Consequence":"攻击者可以通过该漏洞删除宿主系统上的任意文件，严重程度高"} + +cve: ./data/2022/34xxx/CVE-2022-34292.json +Docker Desktop for Windows before 4.6.0 allows attackers to overwrite any file through a symlink attack on the hyperv/create dockerBackendV2 API by controlling the DataFolder parameter for DockerDesktop.vhdx, a similar issue to CVE-2022-31647. + +analysis: {"Conatiner":"Docker Desktop for Windows","CVE_Reason":"未妥善保护的符号链接文件","CVE_Consequence":"攻击者可以利用此漏洞覆盖任意文件，可能导致数据丢失或系统被入侵，严重程度较高"} + +cve: ./data/2022/37xxx/CVE-2022-37326.json +Docker Desktop for Windows before 4.6.0 allows attackers to delete (or create) any file through the dockerBackendV2 windowscontainers/start API by controlling the pidfile field inside the DaemonJSON field in the WindowsContainerStartRequest class. This can indirectly lead to privilege escalation. + +analysis: {"Conatiner":"Docker Desktop for Windows","CVE_Reason":"未妥善验证API参数导致的任意文件删除或创建漏洞","CVE_Consequence":"可能导致特权提升，严重程度：高"} + +cve: ./data/2022/38xxx/CVE-2022-38730.json +Docker Desktop for Windows before 4.6 allows attackers to overwrite any file through the windowscontainers/start dockerBackendV2 API by controlling the data-root field inside the DaemonJSON field in the WindowsContainerStartRequest class. This allows exploiting a symlink vulnerability in ..\dataRoot\network\files\local-kv.db because of a TOCTOU race condition. + +analysis: {"Conatiner":"Docker Desktop for Windows","CVE_Reason":"未妥善保护的文件、目录或API参数（data-root字段）","CVE_Consequence":"攻击者可以利用此漏洞覆盖任意文件，导致系统文件被篡改，严重程度高"} + +cve: ./data/2022/39xxx/CVE-2022-39206.json +Onedev is an open source, self-hosted Git Server with CI/CD and Kanban. When using Docker-based job executors, the Docker socket (e.g. /var/run/docker.sock on Linux) is mounted into each Docker step. Users that can define and trigger CI/CD jobs on a project could use this to control the Docker daemon on the host machine. This is a known dangerous pattern, as it can be used to break out of Docker containers and, in most cases, gain root privileges on the host system. This issue allows regular (non-admin) users to potentially take over the build infrastructure of a OneDev instance. Attackers need to have an account (or be able to register one) and need permission to create a project. Since code.onedev.io has the right preconditions for this to be exploited by remote attackers, it could have been used to hijack builds of OneDev itself, e.g. by injecting malware into the docker images that are built and pushed to Docker Hub. The impact is increased by this as described before. Users are advised to upgrade to 7.3.0 or higher. There are no known workarounds for this issue. + +analysis: {"Conatiner":"OneDev使用的Docker容器","CVE_Reason":"未妥善保护的Docker.sock文件","CVE_Consequence":"允许普通用户控制主机Docker守护进程，可能导致容器逃逸并获取主机root权限，严重程度高"} + +cve: ./data/2022/43xxx/CVE-2022-43679.json +The Docker image of ownCloud Server through 10.11 contains a misconfiguration that renders the trusted_domains config useless. This could be abused to spoof the URL in password-reset e-mail messages. + +analysis: {"Conatiner":"ownCloud Server 10.11及以下版本的Docker镜像","CVE_Reason":"容器中存在配置错误，导致trusted_domains配置失效","CVE_Consequence":"攻击者可利用此漏洞伪造密码重置邮件中的URL，可能导致用户账户被接管，严重程度为高"} + +cve: ./data/2023/0xxx/CVE-2023-0633.json +In Docker Desktop on Windows before 4.12.0 an argument injection to installer may result in local privilege escalation (LPE).This issue affects Docker Desktop: before 4.12.0. + +analysis: {"Container":"Docker Desktop","CVE_Reason":"安装程序参数注入漏洞","CVE_Consequence":"可能导致本地权限提升（LPE），严重程度：高"} + +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: {"Conatiner":"Izanami官方Docker镜像","CVE_Reason":"硬编码的JWT签名密钥未妥善保护","CVE_Consequence":"攻击者可以绕过认证机制，获取未授权访问权限，严重程度高"} + +cve: ./data/2023/22xxx/CVE-2023-22746.json +CKAN is an open-source DMS (data management system) for powering data hubs and data portals. When creating a new container based on one of the Docker images listed below, the same secret key was being used by default. If the users didn't set a custom value via environment variables in the `.env` file, that key was shared across different CKAN instances, making it easy to forge authentication requests. Users overriding the default secret key in their own `.env` file are not affected by this issue. Note that the legacy images (ckan/ckan) located in the main CKAN repo are not affected by this issue. The affected images are ckan/ckan-docker, (ckan/ckan-base images), okfn/docker-ckan (openknowledge/ckan-base and openknowledge/ckan-dev images) +keitaroinc/docker-ckan (keitaro/ckan images). + +analysis: ```json +{"Conatiner":"ckan/ckan-docker, ckan/ckan-base, okfn/docker-ckan, openknowledge/ckan-base, openknowledge/ckan-dev, keitaroinc/docker-ckan, keitaro/ckan","CVE_Reason":"默认共享的密钥未被妥善替换","CVE_Consequence":"可能导致伪造认证请求，中等严重程度"} +``` + +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: {"Conatiner":"IBM Instana 数据存储容器镜像","CVE_Reason":"未设置身份验证的敏感数据存储","CVE_Consequence":"攻击者可获得数据存储的读写访问权限，可能导致数据泄露或篡改，严重程度高"} + +cve: ./data/2023/31xxx/CVE-2023-31001.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.6.1) temporarily stores sensitive information in files that could be accessed by a local user. IBM X-Force ID: 254653. + +analysis: {"Conatiner":"IBM Security Access Manager Container","CVE_Reason":"临时存储在文件中的敏感信息","CVE_Consequence":"本地用户可能访问敏感信息，中等严重程度"} + +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: {"Conatiner":"RKE创建的Kubernetes集群镜像","CVE_Reason":"未妥善保护的配置信息（full-cluster-state configmap）","CVE_Consequence":"非管理员用户可利用该信息提升权限至管理员，高严重程度"} + +cve: ./data/2023/32xxx/CVE-2023-32696.json +CKAN is an open-source data management system for powering data hubs and data portals. Prior to versions 2.9.9 and 2.10.1, the `ckan` user (equivalent to www-data) owned code and configuration files in the docker container and the `ckan` user had the permissions to use sudo. These issues allowed for code execution or privilege escalation if an arbitrary file write bug was available. Versions 2.9.9, 2.9.9-dev, 2.10.1, and 2.10.1-dev contain a patch. + +analysis: {"Conatiner":"CKAN Docker容器镜像","CVE_Reason":"容器内的ckan用户对代码和配置文件拥有过高权限，并可使用sudo","CVE_Consequence":"可能导致代码执行或权限提升，严重程度：高"} + +cve: ./data/2023/33xxx/CVE-2023-33979.json +gpt_academic provides a graphical interface for ChatGPT/GLM. A vulnerability was found in gpt_academic 3.37 and prior. This issue affects some unknown processing of the component Configuration File Handler. The manipulation of the argument file leads to information disclosure. Since no sensitive files are configured to be off-limits, sensitive information files in some working directories can be read through the `/file` route, leading to sensitive information leakage. This affects users that uses file configurations via `config.py`, `config_private.py`, `Dockerfile`. A patch is available at commit 1dcc2873d2168ad2d3d70afcb453ac1695fbdf02. As a workaround, one may use environment variables instead of `config*.py` files to configure this project, or use docker-compose installation to configure this project. + +analysis: {"Conatiner":"gpt_academic","CVE_Reason":"未妥善保护的配置文件，允许通过`/file`路由访问敏感信息文件","CVE_Consequence":"可能导致敏感信息泄漏，严重程度为中到高"} + +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: {"Conatiner":"Play With Docker","CVE_Reason":"容器以CAP_SYS_ADMIN权限运行，可能导致容器逃逸","CVE_Consequence":"攻击者可能利用该漏洞完全控制宿主系统，严重程度：高"} + +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: {"Conatiner":"Auto-GPT使用的Docker容器","CVE_Reason":"未受保护的docker-compose.yml文件被挂载进容器","CVE_Consequence":"恶意Python代码可覆盖docker-compose.yml，导致主机系统被控制，严重程度高"} + +cve: ./data/2023/38xxx/CVE-2023-38369.json +IBM Security Access Manager Container 10.0.0.0 through 10.0.6.1 does not require that docker images should have strong passwords by default, which makes it easier for attackers to compromise user accounts. IBM X-Force ID: 261196. + +analysis: {"Conatiner":"IBM Security Access Manager Container","CVE_Reason":"容器镜像默认未要求使用强密码","CVE_Consequence":"攻击者更容易入侵用户账户，严重程度较高"} + +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: {"Conatiner":"ownCloud相关的容器镜像","CVE_Reason":"未妥善保护的PHP环境配置信息（phpinfo）泄露，包含敏感数据如管理员密码、邮件服务器凭据和许可证密钥等环境变量","CVE_Consequence":"可能导致攻击者获取系统敏感信息，严重程度较高"} + +cve: ./data/2023/5xxx/CVE-2023-5166.json +Docker Desktop before 4.23.0 allows Access Token theft via a crafted extension icon URL. + +This issue affects Docker Desktop: before 4.23.0. + +analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未妥善保护的访问令牌","CVE_Consequence":"攻击者可以通过构造的扩展图标URL窃取访问令牌，可能导致未经授权的访问和数据泄露，严重程度较高"} + +cve: ./data/2024/21xxx/CVE-2024-21653.json +The vantage6 technology enables to manage and deploy privacy enhancing technologies like Federated Learning (FL) and Multi-Party Computation (MPC). Nodes and servers get a ssh config by default that permits root login with password authentication. In a proper deployment, the SSH service is not exposed so there is no risk, but not all deployments are ideal. The default should therefore be less permissive. The vulnerability can be mitigated by removing the ssh part from the docker file and rebuilding the docker image. Version 4.2.0 patches the vulnerability. + +analysis: {"Conatiner":"vantage6","CVE_Reason":"容器镜像中的Dockerfile默认配置了允许root用户通过密码进行SSH登录的不安全配置","CVE_Consequence":"可能导致攻击者通过SSH服务非法获取容器控制权，严重程度较高"} + +cve: ./data/2024/23xxx/CVE-2024-23651.json +BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. The issue has been fixed in v0.12.5. Workarounds include, avoiding using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options. + +analysis: {"Conatiner":"BuildKit构建的容器镜像","CVE_Reason":"共享缓存挂载的竞争条件导致主机文件被访问","CVE_Consequence":"可能导致容器内访问到主机系统的敏感文件，严重程度较高"} + +cve: ./data/2024/23xxx/CVE-2024-23652.json +BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. The issue has been fixed in v0.12.5. Workarounds include avoiding using BuildKit frontends from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature. + +analysis: {"Conatiner":"BuildKit构建的容器镜像","CVE_Reason":"恶意Dockerfile使用RUN --mount导致主机系统上的文件被删除","CVE_Consequence":"可能导致主机文件系统受损，严重程度高"} + +cve: ./data/2024/24xxx/CVE-2024-24557.json +Moby is an open-source project created by Docker to enable software containerization. The classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. 23.0+ users are only affected if they explicitly opted out of Buildkit (DOCKER_BUILDKIT=0 environment variable) or are using the /build API endpoint. All users on versions older than 23.0 could be impacted. Image build API endpoint (/build) and ImageBuild function from github.com/docker/docker/client is also affected as it the uses classic builder by default. Patches are included in 24.0.9 and 25.0.2 releases. + +analysis: {"Conatiner":"[任何使用classic builder构建的容器镜像]","CVE_Reason"："[由于FROM scratch构建时缓存中毒，导致敏感信息或恶意内容被引入镜像中]"，"CVE_Consequence":"[攻击者可能通过缓存中毒篡改构建过程，引入恶意代码或配置，严重程度：高]"} + +cve: ./data/2024/24xxx/CVE-2024-24756.json +Crafatar serves Minecraft avatars based on the skin for use in external applications. Files outside of the `lib/public/` directory can be requested from the server. Instances running behind Cloudflare (including crafatar.com) are not affected. Instances using the Docker container as shown in the README are affected, but only files within the container can be read. By default, all of the files within the container can also be found in this repository and are not confidential. This vulnerability is patched in 2.1.5. + +analysis: {"Conatiner":"Crafatar Docker容器镜像","CVE_Reason":"未妥善保护的文件，允许访问容器内非`lib/public/`目录的文件","CVE_Consequence":"可能导致容器内文件泄露，虽然默认文件非机密，但若用户添加了敏感文件，则可能造成严重信息泄露"} + +cve: ./data/2024/29xxx/CVE-2024-29967.json +In Brocade SANnav before Brocade SANnav v2.31 and v2.3.0a, it was observed that Docker instances inside the appliance have insecure mount points, allowing reading and writing access to sensitive files. The vulnerability could allow a sudo privileged user on the host OS to read and write access to these files. + +analysis: {"Conatiner":"Brocade SANnav","CVE_Reason":"未妥善保护的文件","CVE_Consequence":"允许具有sudo权限的主机操作系统用户读取和写入敏感文件，中等严重程度"} + +cve: ./data/2024/35xxx/CVE-2024-35137.json +IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could allow a local user to possibly elevate their privileges due to sensitive configuration information being exposed. IBM X-Force ID: 292413. + +analysis: {"Conatiner":"IBM Security Access Manager Docker","CVE_Reason":"敏感配置信息暴露","CVE_Consequence":"可能允许本地用户提升权限，严重程度：高"} + +cve: ./data/2024/35xxx/CVE-2024-35139.json +IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could allow a local user to obtain sensitive information from the container due to incorrect default permissions. IBM X-Force ID: 292415. + +analysis: {"Conatiner":"IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1","CVE_Reason":"未妥善保护的敏感信息文件，由于默认权限设置错误导致泄漏","CVE_Consequence":"本地用户可能获取容器内敏感信息，中等严重程度"} + +cve: ./data/2024/45xxx/CVE-2024-45497.json +A flaw was found in the OpenShift build process, where the docker-build container is configured with a hostPath volume mount that maps the node's /var/lib/kubelet/config.json file into the build pod. This file contains sensitive credentials necessary for pulling images from private repositories. The mount is not read-only, which allows the attacker to overwrite it. By modifying the config.json file, the attacker can cause a denial of service by preventing the node from pulling new images and potentially exfiltrating sensitive secrets. This flaw impacts the availability of services dependent on image pulls and exposes sensitive information to unauthorized parties. + +analysis: {"Conatiner":"docker-build","CVE_Reason":"未妥善保护的文件，敏感的config.json文件被映射到容器中且非只读","CVE_Consequence":"可能导致服务不可用，严重程度高；同时敏感信息可能被泄露，严重程度高"} + +cve: ./data/2024/47xxx/CVE-2024-47179.json +RSSHub is an RSS network. Prior to commit 64e00e7, RSSHub's `docker-test-cont.yml` workflow is vulnerable to Artifact Poisoning, which could have lead to a full repository takeover. Downstream users of RSSHub are not vulnerable to this issue, and commit 64e00e7 fixed the underlying issue and made the repository no longer vulnerable. The `docker-test-cont.yml` workflow gets triggered when the `PR - Docker build test` workflow completes successfully. It then collects some information about the Pull Request that triggered the triggering workflow and set some labels depending on the PR body and sender. If the PR also contains a `routes` markdown block, it will set the `TEST_CONTINUE` environment variable to `true`. The workflow then downloads and extracts an artifact uploaded by the triggering workflow which is expected to contain a single `rsshub.tar.zst` file. However, prior to commit 64e00e7, it did not validate and the contents were extracted in the root of the workspace overriding any existing files. Since the contents of the artifact were not validated, it is possible for a malicious actor to send a Pull Request which uploads, not just the `rsshub.tar.zst` compressed docker image, but also a malicious `package.json` file with a script to run arbitrary code in the context of the privileged workflow. As of commit 64e00e7, this scenario has been addressed and the RSSHub repository is no longer vulnerable. + +analysis: {"Conatiner":"RSSHub的docker-test-cont.yml工作流容器","CVE_Reason":"未验证并提取压缩文件内容，导致恶意文件覆盖或注入","CVE_Consequence":"可能导致代码执行、仓库接管等严重后果，高危"} + +cve: ./data/2024/55xxx/CVE-2024-55964.json +An issue was discovered in Appsmith before 1.52. An incorrectly configured PostgreSQL instance in the Appsmith image leads to remote command execution inside the Appsmith Docker container. The attacker must be able to access Appsmith, login to it, create a datasource, create a query against that datasource, and execute that query. + +analysis: {"Conatiner":"Appsmith","CVE_Reason":"未正确配置的PostgreSQL实例","CVE_Consequence":"可能导致远程命令执行，严重程度：高"} + +cve: ./data/2024/6xxx/CVE-2024-6222.json +In Docker Desktop before v4.29.0, an attacker who has gained access to the Docker Desktop VM through a container breakout can further escape to the host by passing extensions and dashboard related IPC messages. + +Docker Desktop v4.29.0 https://docs.docker.com/desktop/release-notes/#4290 fixes the issue on MacOS, Linux and Windows with Hyper-V backend. + +As exploitation requires "Allow only extensions distributed through the Docker Marketplace" to be disabled, Docker Desktop  v4.31.0 https://docs.docker.com/desktop/release-notes/#4310  additionally changes the default configuration to enable this setting by default. + +analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未妥善保护的IPC消息接口，允许容器逃逸至主机","CVE_Consequence":"攻击者可通过IPC消息逃逸到宿主机器，严重程度高"} + +cve: ./data/2024/7xxx/CVE-2024-7387.json +A flaw was found in openshift/builder. This vulnerability allows command injection via path traversal, where a malicious user can execute arbitrary commands on the OpenShift node running the builder container. When using the “Docker” strategy, executable files inside the privileged build container can be overridden using the `spec.source.secrets.secret.destinationDir` attribute of the `BuildConfig` definition. An attacker running code in a privileged container could escalate their permissions on the node running the container. + +analysis: {"Conatiner":"openshift/builder","CVE_Reason":"未对`spec.source.secrets.secret.destinationDir`属性的路径穿越进行妥善验证，导致可覆盖容器内可执行文件","CVE_Consequence":"攻击者可在特权容器中执行任意命令，进而提权至运行容器的OpenShift节点，严重程度高"} + +cve: ./data/2024/7xxx/CVE-2024-7771.json +A vulnerability in the Dockerized version of mintplex-labs/anything-llm (latest, digest 1d9452da2b92) allows for a denial of service. Uploading an audio file with a very low sample rate causes the functionality responsible for transcribing it to crash the entire site instance. The issue arises from the localWhisper implementation, where resampling the audio file from 1 Hz to 16000 Hz quickly exceeds available memory, leading to the Docker instance being killed by the instance manager. + +analysis: {"Conatiner":"mintplex-labs/anything-llm","CVE_Reason":"上传低采样率音频文件导致内存耗尽","CVE_Consequence":"可能导致容器实例被杀掉，造成拒绝服务（严重）"} + +cve: ./data/2024/9xxx/CVE-2024-9407.json +A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files. + +analysis: {"Conatiner":"[使用Dockerfile构建的容器镜像]","CVE_Reason"："[未正确验证bind-propagation选项的输入，导致任意参数传递至mount指令]","CVE_Consequence":"[攻击者可在构建过程中将主机敏感目录挂载至容器，并可能修改挂载文件内容，甚至绕过SELinux保护机制，严重程度：高]"} + +cve: ./data/2025/27xxx/CVE-2025-27519.json +Cognita is a RAG (Retrieval Augmented Generation) Framework for building modular, open source applications for production by TrueFoundry. A path traversal issue exists at /v1/internal/upload-to-local-directory which is enabled when the Local env variable is set to true, such as when Cognita is setup using Docker. Because the docker environment sets up the backend uvicorn server with auto reload enabled, when an attacker overwrites the /app/backend/__init__.py file, the file will automatically be reloaded and executed. This allows an attacker to get remote code execution in the context of the Docker container. This vulnerability is fixed in commit a78bd065e05a1b30a53a3386cc02e08c317d2243. + +analysis: {"Conatiner":"Cognita Docker镜像","CVE_Reason":"未对上传路径进行严格限制，导致路径遍历漏洞，允许攻击者覆盖关键文件","CVE_Consequence":"攻击者可利用此漏洞实现远程代码执行，严重程度：高"} + +cve: ./data/2025/27xxx/CVE-2025-27615.json +umatiGateway is software for connecting OPC Unified Architecture servers with an MQTT broker utilizing JSON messages. The user interface may possibly be publicly accessible with umatiGateway's provided docker-compose file. With this access, the configuration can be viewed and altered. Commit 5d81a3412bc0051754a3095d89a06d6d743f2b16 uses `127.0.0.1:8080:8080` to limit access to the local network. For those who are unable to use this proposed patch, a firewall on Port 8080 may block remote access, but the workaround may not be perfect because Docker may also bypass a firewall by its iptable based rules for port forwarding. + +analysis: {"Conatiner":"umatiGateway","CVE_Reason":"用户界面由于docker-compose文件配置不当而可能被公开访问，导致配置可被查看和修改","CVE_Consequence":"攻击者可能通过公开的用户界面访问并更改配置，可能导致敏感信息泄露或系统被篡改，严重程度较高"} + +cve: ./data/2025/27xxx/CVE-2025-27650.json +Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.862 Application 20.0.2014 allows Private Keys in Docker Overlay V-2023-013. + +analysis: {"Conatiner":"Vasion Print Virtual Appliance Host","CVE_Reason":"未妥善保护的私钥文件","CVE_Consequence":"可能导致私钥泄露，严重程度高"} + +cve: ./data/2025/32xxx/CVE-2025-32111.json +The Docker image from acme.sh before 40b6db6 is based on a .github/workflows/dockerhub.yml file that lacks "persist-credentials: false" for actions/checkout. + +analysis: {"Conatiner":"acme.sh","CVE_Reason":"未设置persist-credentials: false，导致GitHub Actions中的actions/checkout可能泄露克隆仓库的凭据信息","CVE_Consequence":"可能导致容器构建过程中泄露仓库凭据，严重程度：高"} + +cve: ./data/2025/32xxx/CVE-2025-32754.json +In jenkins/ssh-agent Docker images 6.11.1 and earlier, SSH host keys are generated on image creation for images based on Debian, causing all containers based on images of the same version use the same SSH host keys, allowing attackers able to insert themselves into the network path between the SSH client (typically the Jenkins controller) and SSH build agent to impersonate the latter. + +analysis: {"Conatiner":"jenkins/ssh-agent","CVE_Reason":"容器镜像构建过程中生成的SSH主机密钥被多个容器共享","CVE_Consequence":"攻击者可以通过网络路径冒充SSH构建代理，严重程度：高"} + +cve: ./data/2025/32xxx/CVE-2025-32755.json +In jenkins/ssh-slave Docker images based on Debian, SSH host keys are generated on image creation for images based on Debian, causing all containers based on images of the same version use the same SSH host keys, allowing attackers able to insert themselves into the network path between the SSH client (typically the Jenkins controller) and SSH build agent to impersonate the latter. + +analysis: {"Conatiner":"jenkins/ssh-slave","CVE_Reason":"容器镜像构建过程中生成的SSH主机密钥被共享给所有基于同一镜像版本的容器","CVE_Consequence":"攻击者可以利用相同的SSH主机密钥进行中间人攻击，冒充SSH构建代理，严重程度为高"} + +cve: ./data/2025/3xxx/CVE-2025-3047.json +When running the AWS Serverless Application Model Command Line Interface (SAM CLI) build process with Docker and symlinks are included in the build files, the container environment allows a user to access privileged files on the host by leveraging the elevated permissions granted to the tool. A user could leverage the elevated permissions to access restricted files via symlinks and copy them to a more permissive location on the container. + +Users should upgrade to v1.133.0 or newer and ensure any forked or derivative code is patched to incorporate the new fixes. + +analysis: {"Conatiner":"AWS SAM CLI构建的容器镜像","CVE_Reason":"通过符号链接访问主机上的特权文件","CVE_Consequence":"攻击者可以利用此漏洞访问受限文件，可能导致敏感信息泄露，严重程度为高"} + +cve: ./data/2025/3xxx/CVE-2025-3048.json +After completing a build with AWS Serverless Application Model Command Line Interface (SAM CLI) which include symlinks, the content of those symlinks are copied to the cache of the local workspace as regular files or directories. As a result, a user who does not have access to those symlinks outside of the Docker container would now have access via the local workspace. + +Users should upgrade to version 1.134.0 and ensure any forked or derivative code is patched to incorporate the new fixes. After upgrading, users must re-build their applications using the sam build --use-container to update the symlinks. + +analysis: {"Conatiner":"AWS SAM CLI构建的容器镜像","CVE_Reason"："未妥善保护的符号链接内容","CVE_Consequence":"导致原本无权限访问符号链接内容的用户可以通过本地工作区访问这些内容，可能引发敏感信息泄露，严重程度为中高"} +