容器安全 on KnightLi的博客

近期四个 Linux 本地提权漏洞影响梳理：Copy Fail、Dirty Frag、Fragnesia 与 ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近 Linux 生态连续出现几起高关注度的本地安全问题。单独看，它们分别落在加密接口、网络/IPsec 路径、页缓存处理、ptrace 访问检查等不同位置；放在一起看，真正值得警惕的是同一个结论：只要攻击者已经拿到低权限本地执行点，Linux 宿主机、容器节点、CI 机器和多用户服务器的风险都会被明显放大。

本文重点不复述每个漏洞的技术细节，而是整理它们对实际环境的影响，并给出站内四篇单独分析文章作为延伸阅读。

四次事件分别影响什么

近期最需要关注的四个风险是：

Copy Fail（CVE-2026-31431）：低权限本地用户可能通过内核加密相关路径影响页缓存，从而扩大权限。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 相关）：风险集中在 xfrm/ESP、RxRPC 等网络和内核数据路径，后渗透阶段危害很高。
Fragnesia（CVE-2026-46300）：与 Dirty Frag 相近，同样围绕 XFRM ESP-in-TCP、共享 fragment 和页缓存写入风险展开。
ssh-keysign-pwn（CVE-2026-46333）：不是直接 root shell 类型漏洞，而是本地信息泄露风险，可能读取 SSH 主机私钥、/etc/shadow 等敏感文件。

这四类问题的入口不同，缓解方式也不完全一样。不能因为处理了 Copy Fail，就默认 Dirty Frag 和 Fragnesia 也安全；也不能因为禁用了某些网络模块，就认为 ssh-keysign-pwn 的信息泄露风险自动消失。

Copy Fail：容器和 CI 节点优先级很高

Copy Fail 的关键影响不是“某个应用崩溃”，而是低权限执行能力可能被转化为 root 权限。它对以下环境尤其敏感：

允许用户上传或运行代码的 CI/CD 节点。
托管不可信工作负载的容器宿主机。
开发测试机、跳板机、共享服务器。
运行旧内核且补丁节奏较慢的云主机。

Copy Fail 的危险点在于攻击门槛偏低，而且容易和容器场景叠加。很多团队把容器当作强隔离边界，但普通容器默认仍共享宿主机内核。如果攻击者能在容器内获得 shell，内核本地提权就可能把容器问题放大为宿主机问题。

详细分析见站内文章：Copy Fail 漏洞 CVE-2026-31431：Linux 内核文件复制路径中的容器逃逸风险。

Dirty Frag：后渗透阶段的放大器

Dirty Frag 更像是攻击者进入系统后的权限放大工具。它不是典型的远程无认证漏洞，前提通常是攻击者已经通过弱口令、WebShell、低权限服务账号、容器任务或其他方式获得本地执行能力。

它的实际影响主要体现在：

已被入侵的低权限账号可能进一步变成 root。
容器环境中的低权限执行点可能威胁宿主机。
使用 IPsec、ESP、RxRPC 或相关内核网络能力的系统需要谨慎评估补丁和临时缓解。
安全团队不能只看边界防护，还要关注入侵后的提权链条。

Dirty Frag 提醒运维团队：本地提权漏洞虽然不是第一入口，却可能决定一次入侵最终能走多远。只要存在低权限落点，攻击者就会寻找内核漏洞把权限推到最高。

详细分析见站内文章：Dirty Frag CVE-2026-43284：Linux 本地提权漏洞风险与缓解指南。

Fragnesia：同类攻击面没有一次性清干净

Fragnesia 的重要性在于，它说明 Dirty Frag 附近的攻击面并不是一个孤立问题。即使某个漏洞被修复，相邻路径、相似数据结构、相同模块组合里仍可能存在新的可利用点。

它对运维的影响主要是：

不能只按漏洞名称做一次性处置，要按攻击面持续检查。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP 等相关路径需要结合业务依赖评估。
如果系统不依赖相关网络能力，可以考虑临时禁用，但必须先在测试环境确认不会影响 VPN、IPsec、隧道或内部网络功能。
页缓存污染类风险可能带来“看似文件没改，实际执行路径受影响”的检测盲点。

Fragnesia 对企业最大的提醒是：补丁管理不能只盯单个 CVE。更稳妥的做法是围绕子系统和攻击面建立清单，确认哪些机器暴露相关能力，哪些业务真正需要这些模块。

详细分析见站内文章：Fragnesia (CVE-2026-46300)：Linux 内核本地提权漏洞影响与缓解。

ssh-keysign-pwn：不直接 root，也足够危险

ssh-keysign-pwn 与前三个漏洞的性质不同。它更偏向本地敏感信息泄露，不是直接拿 root shell 的漏洞。但在真实攻击中，敏感信息泄露常常能变成更严重的后果。

它的影响重点包括：

SSH host private keys 泄露后，可能影响主机身份可信度。
/etc/shadow 等文件被读取后，可能引发离线破解和账号接管。
多用户服务器、跳板机、构建机、共享开发机风险更高。
即使攻击者没有立刻提权，也可能拿到后续横向移动需要的凭据材料。

这类问题容易被低估，因为它没有“直接 root shell”那么刺激。但对企业环境来说，密钥和密码哈希泄露往往意味着更长周期的清理：轮换 SSH 主机密钥、排查信任关系、检查账号密码、审计登录日志，都可能成为必要动作。

详细分析见站内文章：ssh-keysign-pwn（CVE-2026-46333）解读：Linux 本地信息泄露、SSH 主机密钥与 /etc/shadow 风险。

共同影响：容器隔离不能再被当作强边界

这四次事件合在一起，最直接的影响是重新提醒大家：普通容器隔离不是虚拟机隔离。

Docker、containerd 和 Kubernetes 依赖 namespace、cgroup、capabilities、seccomp、AppArmor 或 SELinux 等机制减少攻击面，但它们通常仍共享宿主机内核。只要漏洞发生在共享内核里，容器内的低权限执行点就可能成为攻击入口。

高风险环境应重点检查：

是否允许不可信代码运行在共享宿主机上。
容器是否默认 root 用户运行。
是否授予了不必要的 capabilities。
seccomp 配置是否过宽。
多租户工作负载是否应该迁移到 gVisor、Kata Containers、Firecracker microVM、独立虚拟机或专用节点。

对 CI/CD 平台尤其要谨慎。构建任务天然会运行外部代码、依赖安装脚本、测试脚本和临时二进制。如果这些任务与长期服务共享宿主机，一次本地提权就可能影响更大的基础设施。

共同影响：补丁必须落到“正在运行的内核”

Linux 内核补丁有一个很常见的误区：包管理器显示已经更新，不代表机器正在运行新内核。

运维上至少要确认三件事：

`1`	`uname -a`

确认当前运行内核版本。

`1`	`dpkg -l \| grep linux-image`

或在 RHEL 系发行版上：

`1`	`rpm -qa \| grep kernel`

确认已安装内核包。

最后，还要确认机器已经重启到修复后的内核。对不能重启的核心业务，要评估 livepatch、热补丁或短期隔离方案，但不要把临时缓解当作最终修复。

共同影响：攻击面最小化要具体到模块和系统调用

这几次漏洞涉及的路径提醒我们，Linux 加固不能只停留在“更新系统”和“开防火墙”。

更具体的检查方向包括：

AF_ALG / algif_aead 是否被业务使用。
XFRM、ESP、ESP-in-TCP、IPsec 是否被 VPN、隧道或安全网关依赖。
RxRPC 是否需要启用。
非特权用户命名空间是否必须开放。
容器是否能创建过宽的 socket 类型。
ptrace 访问策略是否过松。

如果业务确实不需要某些能力，可以评估禁用模块、调整 sysctl、收紧 seccomp、减少 capabilities。生产环境不要盲目复制命令，应先盘点依赖，再灰度执行。

建议的处置顺序

第一，优先修复可本地执行代码的高暴露机器：

容器宿主机。
CI/CD runner。
跳板机。
多用户服务器。
对外服务所在主机。
运行不可信插件、脚本、扩展的系统。

第二，确认发行版公告和实际运行内核。不要只看上游版本号，Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler 等发行版可能会 backport 安全补丁。

第三，收紧容器运行策略。尽量做到非 root 用户、最小 capabilities、no-new-privileges、只读文件系统、明确 seccomp 和 AppArmor/SELinux 策略。

第四，检查密钥和凭据风险。尤其是涉及 ssh-keysign-pwn 的环境，应评估 SSH host key、/etc/shadow、跳板机凭据和 CI secrets 是否需要轮换。

第五，补上监控。重点关注异常 root shell、可疑本地提权 PoC、关键文件修改、异常 ptrace 行为、容器进程访问宿主机路径、CI 节点上的异常网络连接。

结论

这四次事件的重点不是“Linux 不安全了”，而是“默认信任不够用了”。

Linux 仍然是透明、可修复、可裁剪、可加固的主流系统。但在容器、CI、多租户和 AI 自动化代码执行越来越普遍的环境里，低权限执行点已经不能被看作小问题。只要内核里存在可利用的本地提权或敏感信息泄露漏洞，局部入侵就可能变成宿主机控制、凭据泄露或横向移动。

更现实的做法是把这四次事件当成一次提醒：补丁要快，重启要确认，模块要按需启用，容器要收紧，密钥要能轮换，多租户要重新评估隔离等级。

站内延伸阅读：

Copy Fail 漏洞 CVE-2026-31431：Linux 内核文件复制路径中的容器逃逸风险

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一个影响 Linux 内核文件复制路径的漏洞，编号为 CVE-2026-31431。 Bugcrowd 的分析把它称为一个值得关注的内核级问题：在特定条件下，非特权用户可以利用文件复制相关逻辑触发越权写入，进而造成权限提升或容器逃逸。

从风险角度看，它不是普通应用层漏洞。问题发生在内核处理文件复制和页面缓存的路径上，因此影响面会延伸到容器、共享主机、CI/CD Runner、PaaS 平台和多租户 Linux 环境。如果攻击者已经能在系统里运行低权限代码，漏洞就可能成为进一步突破隔离边界的跳板。

漏洞大致发生在哪里

Copy Fail 关联的是 Linux 内核中的文件复制能力。现代 Linux 提供了多种高效复制路径，例如 copy_file_range、splice 类路径以及不同文件系统之间的数据复制优化。这些机制的目标是减少用户态和内核态之间的数据搬运，提高大文件复制性能。

问题在于，高性能复制路径通常会复用页缓存、文件偏移、权限检查和文件系统回调。如果其中某个边界条件处理不严，内核可能在错误的权限上下文里执行写入，或者把本不应该被修改的数据页暴露给攻击者控制。

Copy Fail 的核心风险可以概括为：

攻击者不需要 root 权限；
攻击入口来自常见文件复制能力；
影响点在内核态；
在容器环境里，漏洞可能绕过命名空间和挂载隔离；
成功利用后可能写入宿主机上不应被容器修改的内容。

这也是它被重点讨论的原因。容器安全依赖 Linux 内核提供隔离能力，一旦内核路径本身出现越权写入，容器边界就会变得脆弱。

为什么容器场景更敏感

容器并不是虚拟机。容器内进程和宿主机共享同一个 Linux 内核，只是通过 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等机制做隔离。

如果漏洞发生在用户态服务里，通常只影响某个容器或某个进程。但如果漏洞发生在内核里，尤其是可以被非特权用户触发的内核漏洞，攻击者可能从容器内部影响宿主机。

Copy Fail 的危险点就在这里。很多平台允许用户提交构建任务、运行脚本、启动容器或执行插件。攻击者只要能在容器里运行代码，就可能尝试利用内核文件复制路径突破隔离。

高风险环境包括：

Kubernetes 集群中的不可信工作负载；
CI/CD 平台的共享 Runner；
允许用户上传代码执行的沙箱平台；
多租户 Linux 主机；
容器化 PaaS；
运行第三方插件或扩展的系统。

如果这些环境里的内核版本处于受影响范围，而且缺少额外限制，风险就会明显升高。

受影响范围要看内核补丁状态

这类漏洞的判断不能只看发行版名称。同一个 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影响取决于当前实际运行的内核包，以及发行版是否已经回补补丁。

排查时应优先确认三件事：

当前运行内核版本；
发行版安全公告是否提到 CVE-2026-31431；
云厂商或托管平台是否已经完成宿主机内核修复。

可以先在系统上确认内核版本：

`1`	`uname -a`

然后查看发行版安全公告、内核 changelog 或云平台公告。不要只根据主版本号判断是否安全，因为很多企业发行版会把安全补丁回补到旧版本内核里。

临时缓解思路

最可靠的修复方式仍然是更新内核。但在补丁无法立刻部署的环境里，可以先降低暴露面。

常见缓解方向包括：

禁止不可信用户运行特权容器；
避免给容器挂载敏感宿主机路径；
收紧容器 capability，尤其不要随意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危险系统调用和文件访问；
将不可信工作负载迁移到隔离更强的虚拟机；
对 CI/CD Runner 做按任务销毁，避免长期复用同一宿主机；
监控异常文件写入、权限变更和容器逃逸迹象。

这些措施不能替代补丁。它们的作用是降低攻击成功率和影响面，特别是在补丁发布到生产环境之前争取缓冲时间。

修复优先级

建议按环境风险排序处理。

优先修复：

对外提供容器执行能力的平台；
运行不可信代码的 CI/CD 节点；
多租户 Kubernetes 节点；
有用户自定义插件或脚本执行能力的系统；
共享开发机、教学机、实验平台。

相对低优先级：

单用户桌面；
只运行可信服务的内网主机；
已经使用虚拟机隔离不可信代码的环境。

即便风险较低，也建议随发行版更新内核。内核漏洞常常会被组合进更复杂的攻击链里，拖延补丁没有太多收益。

给运维团队的检查清单

可以按下面顺序处理：

盘点所有 Linux 主机和容器节点；
标记会运行不可信代码的机器；
检查当前内核版本和发行版安全公告；
优先更新高风险节点；
对无法立即更新的节点启用临时隔离策略；
检查容器运行时配置，移除不必要的特权和宿主机挂载；
更新后重启节点，确认新内核已经实际生效；
保留变更记录，方便后续审计。

内核包安装完成并不代表系统已经运行在新内核上。更新后必须重启，并再次确认：

`1`	`uname -a`

小结

Copy Fail / CVE-2026-31431 的重点不是某个应用崩溃，而是 Linux 内核文件复制路径中的权限边界问题。它让非特权代码有机会触碰更高权限的数据写入路径，因此在容器和多租户环境里尤其值得重视。

处理这类漏洞时，最重要的是两件事：

尽快跟进发行版或云厂商提供的内核补丁；
在补丁部署前限制不可信代码、特权容器和敏感宿主机挂载。

对个人桌面来说，它可能不是马上需要恐慌的问题。但对运行容器平台、CI/CD、沙箱和共享主机的团队来说，应该把它当作高优先级内核安全更新处理。

参考来源：