slauger/CVE-2026-31431

# CVE-2026-31431 — "Copy Fail" Linux 内核加密子系统 `algif_aead` 中的本地权限提升漏洞。 ## 概述 CVE-2026-31431，被称为“Copy Fail”，是 Linux 内核 `authencesn` 加密模板（`algif_aead`）中的一个逻辑缺陷。它允许无特权的本地用户对任何可读文件的页缓存进行受控的 4 字节写入，这可以被用来修改 setuid 二进制文件并获取 root 权限。 - **CVSS：** 7.8（高） - **受影响版本：** 自 2017 年以来发布的所有主流 Linux 内核 - **漏洞利用：** 一个 732 字节的 Python 脚本 —— 无竞态条件，无特定内核偏移量 - **修复：** 主线提交 `a664bf3d603d` ## 时间线 | 日期 | 事件 | |---|---| | 2026-03-23 | 报告给 Linux 内核安全团队 | | 2026-04-01 | 补丁提交至主线 | | 2026-04-22 | 分配 CVE 编号 | | 2026-04-29 | 公开披露 | ## 影响矩阵 | 环境 | `allowPrivilegeEscalation` | 容器 Root | 宿主机 Root | 风险 | |---|---|---|---|---| | **RHEL 8 / RHEL 9**（本地用户） | n/a | n/a | **是** | **严重** | | **OpenShift 节点**（Shell 访问权限，例如 `oc debug node/`） | n/a | n/a | **是** | **严重** | | **OpenShift Pod** — `restricted-v2` SCC（默认） | `false` | 否 | 否 | **低** | | **OpenShift Pod** — `anyuid` SCC | `true` | **是** | 否（命名空间隔离） | **高** | | **OpenShift Pod** — `privileged` SCC | `true` | **是** | **是**（无隔离） | **严重** | | **OpenShift Pod** — 自定义 SCC | 视情况而定 | 视情况而定 | 视情况而定 | **需审计** | | **Kubernetes Pod** — PSS Restricted | `false` | 否 | 否 | **低** | | **Kubernetes Pod** — PSS Baseline / 无策略 | `true`（默认） | **是** | 否 | **高** | | **Docker / Podman** — `--security-opt no-new-privileges` | `false` | 否 | 否 | **低** | | **Docker / Podman** — 默认 | `true` | **是** | 否 | **高** | 该漏洞利用需要两个条件：一个 `AF_ALG` socket（在所有 seccomp 配置文件中默认允许）和一个 setuid 二进制文件（例如 `/usr/bin/su`）。关键的缓解措施是 `allowPrivilegeEscalation: false` —— 这会通过 `prctl(PR_SET_NO_NEW_PRIVS, 1)` 设置 Linux 内核的 [`no_new_privs`](https://docs.kernel.org/userspace-api/no_new_privs.html) 标志，从而使内核在执行 `execve()` 时忽略 setuid/setgid 位。由于该漏洞利用依赖于执行被修改的 setuid 二进制文件，因此这会阻止最终的提权步骤。 这**不是 OpenShift 特有的功能** —— 它在原生 Kubernetes（Pod 安全标准 Restricted）、Docker（`--security-opt no-new-privileges`）和 Podman 上的工作原理完全相同。OpenShift 只是通过 `restricted-v2` SCC 默认强制执行了该配置，而其他平台则需要显式配置。 ### RHEL 8 / RHEL 9 RHEL 8 和 RHEL 9 附带的内核包含此易受攻击的代码。拥有 shell 访问权限的无特权本地用户可以利用此漏洞获取 root 权限。**请立即打补丁。** ``` yum updateinfo list cves CVE-2026-31431 yum update kernel ``` ### OpenShift (4.x) OpenShift 运行在 RHCOS 之上，而 RHCOS 附带了带有此漏洞的内核。实际的影响取决于工作负载的安全上下文约束（SCC）。 使用默认 `restricted-v2` SCC 的标准工作负载**不可被利用**，因为强制执行了 `allowPrivilegeEscalation: false`。 使用提权 SCC（`anyuid`、`privileged` 或允许 `allowPrivilegeEscalation: true` 的自定义 SCC）运行的 Pod **存在漏洞**。这通常包括： - CI/CD 构建 Pod（Jenkins 代理，带有自定义 SCC 的 Tekton） - 需要 `anyuid` 的旧版应用程序 - 基础设施 Pod（监控、日志、存储） 直接访问节点（例如通过 `oc debug node/`）总是存在风险的 —— 这是标准的本地权限提升，不涉及容器隔离。 ## 测试 我们提供了一个测试 Pod，用于检查您的集群中是否满足漏洞利用的先决条件。它**不会**尝试利用该漏洞 —— 它仅检查： 1. 能否创建 `AF_ALG` socket？（内核攻击面可达） 2. 是否设置了 `no_new_privs`？（阻止 setuid 提权） 3. 容器镜像中是否存在 setuid 二进制文件？ 4. 底层节点的内核版本 ### 用法（Pod） ``` oc apply -f test-pod.yaml oc logs cve-2026-31431-check oc delete -f test-pod.yaml ``` ### 用法（Deployment） 使用 Deployment 变体可以通过扩展副本或使用 Pod 反亲和性来跨多个节点进行测试： ``` oc apply -f test-deployment.yaml oc logs -l app=cve-2026-31431-check oc delete -f test-deployment.yaml ``` ### 退出码 | 代码 | 含义 | |---|---| | `0` | 不可利用 — AF_ALG socket 被 seccomp 阻止 | | `1` | 部分暴露 — AF_ALG 可达，但 setuid 被 `no_new_privs` 阻止 | | `2` | 易受攻击 — 满足所有漏洞利用先决条件 | ### 默认 OpenShift 上的预期结果 在带有 `restricted-v2` SCC 的标准 OpenShift 集群上，您应该会看到退出码 `1`（部分暴露）：可以创建 AF_ALG socket（RuntimeDefault seccomp 未阻止它），但 `no_new_privs` 阻止了 setuid 提权步骤。已发布的 PoC 将不起作用，但内核级别的漏洞依然可达 —— 建议打补丁。 ## 缓解措施 ### 1. 给内核打补丁（P0） 这是唯一彻底的修复方法。更新所有节点上的内核并重启。 对于 OpenShift，更新至包含此修复的 RHCOS 版本并执行节点滚动重启。 ### 2. 禁用 algif_aead 模块（临时解决方法） 如果 `algif_aead` 被编译为**可加载模块**（`CONFIG_CRYPTO_USER_API_AEAD=m`）： ``` echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true ``` **如果 `algif_aead` 是内置的（`=y`），则此方法无效**，RHCOS 就是这种情况。请使用以下命令检查： ``` modinfo algif_aead 2>&1 | grep builtin grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r) ``` ### 3. 通过 seccomp 阻止 AF_ALG（OpenShift） 如果内核模块是内置的，那么对于容器而言，在打补丁前唯一的缓解措施就是通过自定义 seccomp 配置文件阻止 `socket(AF_ALG, ...)` 系统调用。 #### 通过 MachineConfig 部署 seccomp 配置文件 创建 MachineConfig 以将配置文件放置在所有节点上（对控制平面节点需使用 `role: master` 重复此操作）： ``` apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-seccomp-deny-af-alg spec: config: ignition: version: 3.2.0 storage: files: - path: /var/lib/kubelet/seccomp/deny-af-alg.json mode: 0644 contents: source: data:application/json;charset=utf-8;base64,ewogICJkZWZhdWx0QWN0aW9uIjogIlNDTVBfQUNUX0FMTE9XIiwKICAic3lzY2FsbHMiOiBbCiAgICB7CiAgICAgICJuYW1lcyI6IFsic29ja2V0Il0sCiAgICAgICJhY3Rpb24iOiAiU0NNUF9BQ1RfRVJSTk8iLAogICAgICAiYXJncyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaW5kZXgiOiAwLAogICAgICAgICAgInZhbHVlIjogMzgsCiAgICAgICAgICAib3AiOiAiU0NNUF9DTVBfRVEiCiAgICAgICAgfQogICAgICBdCiAgICB9CiAgXQp9 ``` Base64 内容解码为： ``` { "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "names": ["socket"], "action": "SCMP_ACT_ERRNO", "args": [ { "index": 0, "value": 38, "op": "SCMP_CMP_EQ" } ] } ] } ``` #### 在 Pod 规范中引用该配置文件 ``` securityContext: seccompProfile: type: Localhost localhostProfile: deny-af-alg.json ``` #### 集群范围的替代方案 为了在不修改 Pod 规范的情况下保护所有容器，可以通过 MachineConfig 向现有的默认配置文件（`/etc/crio/seccomp.json`）添加 AF_ALG 过滤规则，从而覆盖 CRI-O 的默认 seccomp 配置文件。 ### 4. 审计您的 SCC 识别以提升的权限运行的 Pod： ``` # 查找未使用 restricted-v2 的 pods oc get pods -A -o json | jq -r ' .items[] | select(.metadata.annotations["openshift.io/scc"] != "restricted-v2") | "\(.metadata.namespace)/\(.metadata.name) → \(.metadata.annotations["openshift.io/scc"])" ' ``` 这些 Pod 是能够运行完整漏洞利用链的地方。请优先为运行这些工作负载的节点打补丁或实施 seccomp 缓解措施。 ## 禁用 AF_ALG 的影响 阻止 AF_ALG socket 对大多数工作负载的**影响微乎其微**。以下内容**不受影响**： - dm-crypt / LUKS - kTLS - IPsec - OpenSSL / GnuTLS（标准构建） 只有显式配置为使用 OpenSSL `afalg` 引擎的应用程序才会受到影响。 ## 参考 - [Copy Fail — 项目主页](https://copy.fail) - [Red Hat CVE-2026-31431](https://access.redhat.com/security/cve/cve-2026-31431) - [NVD — CVE-2026-31431](https://nvd.nist.gov/vuln/detail/CVE-2026-31431) - [RuntimeDefault 并未阻止 AF_ALG (juliet.sh)](https://juliet.sh/blog/we-tested-copy-fail-in-kubernetes-pss-restricted-runtime-default-af-alg) - [Xint — Copy Fail 漏洞分析文章](https://xint.io/blog/copy-fail-linux-distributions) - [The Register — Linux 加密代码缺陷](https://www.theregister.com/2026/04/30/linux_cryptographic_code_flaw/)

标签：algif_aead, Copy Fail, CVE-2026-31431, JSONLines, Linux Kernel, Linux内核漏洞, OpenShift, PoC, RHEL, setuid提权, Web截图, Web报告查看器, 子域名枚举, 子域名突变, 容器安全, 容器隔离, 应用安全, 暴力破解, 本地提权, 漏洞分析, 漏洞缓解, 系统安全, 网络安全, 路径探测, 逆向工具, 隐私保护, 零信任, 页缓存篡改