containerd和containerd-shim之间采用abstract socket通信，当容器共享了宿主机的网络namespace且容器内部UID设置为0时，攻击者就可以以Root用户访问宿主机上的containerd-shim进程，进而逃逸出容器并使用containerd-shim的相关接口发起下一步的提权攻击。 说明 containerd作为支撑Kubernetes集群运行时，负责管理底层的runC容器，通常包含一个守护进程并通过本地的Unix套接字暴露gRPC服务接口用于容器生命周期的各种管理操作。 containerd-shim作为containerd的一个组件，用于隔离containerd守护进程和容器进程，并且通过containerd-shim调用runC接口直接和容器交互。
漏洞概览
- CVE 编号
- CVE-2020-15257
- 文章标题
- CVE-2020-15257 containerd-shim 权限提升漏洞
- 影响产品或组件
- 未命名漏洞案例
- 漏洞类型
- 以原文描述为准，未单独列出 CWE
- 原文字符数
- 4385
- 资料核验日期
- 2026-09-18
安全风险等级评估
原文未提供独立的风险等级评估。处置优先级应结合漏洞可利用性、资产暴露面和业务影响判断。
影响范围与修复版本
| 产品或分支 | 受影响范围 | 历史修复边界或说明 |
|---|---|---|
| 未命名漏洞案例 | containerd社区在1 | 按厂商公告与产品矩阵核对 |
| 未命名漏洞案例 | 3版本修复了该漏洞，当前ACK所有版本的k8s集群均在该漏洞影响范围内 | 按原文或厂商公告核对修复边界 |
| 未命名漏洞案例 | 您可以使用以下kubectl命令查看集群内有哪些Pod共享了主机网络 | 按厂商公告与产品矩阵核对 |
原文范围说明：containerd社区在1.3.9和1.4.3版本修复了该漏洞，当前ACK所有版本的k8s集群均在该漏洞影响范围内。您可以使用以下kubectl命令查看集群内有哪些Pod共享了主机网络。 kubectl get pods – A – o json | jq – c '.items[] | select(.spec.hostNetwork==true) |[.metadata.namespace, .metadata.name]'
漏洞详情
漏洞机制
containerd和containerd-shim之间采用abstract socket通信，当容器共享了宿主机的网络namespace且容器内部UID设置为0时，攻击者就可以以Root用户访问宿主机上的containerd-shim进程，进而逃逸出容器并使用containerd-shim的相关接口发起下一步的提权攻击。 说明 containerd作为支撑Kubernetes集群运行时，负责管理底层的runC容器，通常包含一个守护进程并通过本地的Unix套接字暴露gRPC服务接口用于容器生命周期的各种管理操作。 containerd-shim作为containerd的一个组件，用于隔离containerd守护进程和容器进程，并且通过containerd-shim调用runC接口直接和容器交互。
触发条件与权限边界
containerd社区在1.3.9和1.4.3版本修复了该漏洞，当前ACK所有版本的k8s集群均在该漏洞影响范围内。您可以使用以下kubectl命令查看集群内有哪些Pod共享了主机网络。 kubectl get pods – A – o json | jq – c '.items[] | select(.spec.hostNetwork==true) |[.metadata.namespace, .metadata.name]'
场景与影响
containerd和containerd-shim之间采用abstract socket通信，当容器共享了宿主机的网络namespace且容器内部UID设置为0时，攻击者就可以以Root用户访问宿主机上的containerd-shim进程，进而逃逸出容器并使用containerd-shim的相关接口发起下一步的提权攻击。 说明 containerd作为支撑Kubernetes集群运行时，负责管理底层的runC容器，通常包含一个守护进程并通过本地的Unix套接字暴露gRPC服务接口用于容器生命周期的各种管理操作。 containerd-shim作为containerd的一个组件，用于隔离containerd守护进程和容器进程，并且通过containerd-shim调用runC接口直接和容器交互。 containerd社区在1.3.9和1.4.3版本修复了该漏洞，当前ACK所有版本的k8s集群均在该漏洞影响范围内。您可以使用以下kubectl命令查看集群内有哪些Pod共享了主机网络。 kubectl get pods – A – o json | jq – c '.items[] | select(.spec.hostNetwork==true) |[.metadata.namespace, .metadata.name]'
检测与排查
资产、配置与日志核查
围绕 CVE-2020-15257 盘点实际资产、软件包或插件版本、启用组件、访问入口和相关日志；修复后回读运行版本与补丁状态，复核业务功能、访问控制和异常进程。不要在生产环境通过投递恶意样本或反复认证失败来验证漏洞。
防范措施与修复验证
修复与缓解
为了尽可能降低您受到提权攻击的概率，您需要尽可能地让业务应用运行在独立的五个核心Net、Mount、IPC、PID或UTS Namespace内，与宿主机共享的namespace越多，被攻击的概率就越高。您也尽可能不要在Pod配置中使用Host Networking配置，可以通过以下方式限制Host Networking的使用： 开启PSP特性，通过PSP策略中的hostNetwork配置可以限制指定namespace的Pod无法使用共享主机网络。ACK容器服务提供了PSP安全策略的控制台配置能力，具体操作，请参见 使用PSP安全策略 。 装gatekeeper组件，具体操作，请参见 组件介绍 。基于 示例OPA策略 。 如果因为业务原因必须使用Host Networking配置， 建议您在Pod的 securityContext 中配置以非Root用户启动，设置 allowPrivilegeEscalation 参数为 false 。具体配置样例如下： hostNetwork: true #特殊原因必须使用主机共享网络。 containers: – name: foo securityContext: runAsUser: 12345 allowPrivilegeEscalation: false
修复后的验证
完成变更后回读 未命名漏洞案例 的实际版本、补丁和配置，确认已落在厂商修复范围；需要重启的服务应验证重启结果，再检查相关业务功能、访问控制与日志。临时缓解应单独标注并跟踪正式修复。
参考来源
英文技术描述已按原文语义整理为中文，产品名、协议名、版本号、命令、路径和官方链接予以保留。涉及多 CVE 的文章维持为一篇，不拆分原文章。
暂无评论内容