linnemanlabs/dirtyfrag-arm64

# dirtyfrag-arm64 [V4bel/dirtyfrag](https://github.com/V4bel/dirtyfrag) 的 arm64/aarch64 移植版本 (CVE-2026-43284, CVE-2026-43500)。 已在 AWS Graviton 上的 Ubuntu 24.04.4 LTS（`linux-aws 6.17.0-1013-aws`）上进行了测试（截至撰写本文时的最新可用版本）。 ## arm64 上的不同之处 上游的 x86\_64 PoC 使用了两个漏洞利用路径：一个是破坏 `/usr/bin/su` 的 ESP/xfrm 路径，另一个是破坏 `/etc/passwd` 的 rxrpc/rxkad 备用路径。在 arm64 上，rxrpc 路径会导致内核 oops，因此无法使用。而 ESP 路径则可以正常工作。 ### rxrpc 崩溃：`flush_dcache_page` 在 x86\_64 上，`flush_dcache_page()` 是一个空操作。x86 具有硬件自动保持一致的数据/指令缓存。而在 arm64 上，它会执行真正的 dcache 维护，并解引用 `struct page*` 元数据。当 rxrpc 加密路径（`rxkad_secure_packet` -> `crypto_pcbc_encrypt` -> `skcipher_walk_done`）对一个通过 splice/vmsplice 链篡改了引用的页面调用 `flush_dcache_page` 时，x86\_64 会静默跳过它，但 arm64 会触发转换错误 并引发 oops： ``` pc : flush_dcache_page+0x18/0x58 lr : skcipher_walk_done+0xbc/0x260 crypto_pcbc_encrypt+0xe8/0x1c8 [pcbc] crypto_skcipher_encrypt+0x48/0xb8 rxkad_secure_packet+0x108/0x270 [rxrpc] rxrpc_send_data+0x264/0x550 [rxrpc] ``` 在阻止非特权用户命名空间创建的 arm64 系统上，两个漏洞利用路径都应该无法生效。ESP 路径无法创建所需的网络命名空间，而 rxrpc 备用路径则会导致内核 panic。而在 x86\_64 上，rxrpc 路径提供了一个免命名空间的替代方案。 ### 仅限 ESP 的操作 在 arm64 上，只有 ESP 路径是可行的。此路径需要创建非特权用户命名空间（`unshare -U -n`），这在大多数 Linux 发行版和云镜像中都是默认启用的。各发行版有自己的限制方式，例如 Ubuntu 通过 AppArmor 配置文件，Debian 通过 `kernel.unprivileged_userns_clone`，RHEL 通过 `user.max_user_namespaces`，如果配置得当，这些方法都可以阻止 ESP 路径。 在 x86_64 上，rxrpc 路径提供了一个无需命名空间即可生效的备用方案。但在 arm64 上，不存在这样的备用方案：阻断非特权用户命名空间会使系统免受任何一条路径的攻击。 ### 特定架构的 payload 该漏洞利用程序会使用一个最小化的静态 ELF 文件去覆写页缓存 中的 `/usr/bin/su`。上游的 PoC 嵌入了一个包含 x86\_64 shellcode 的 x86\_64 ELF。本移植版用一个等效的 aarch64 ELF 替换了它： - ELF `e_machine`：使用 `EM_AARCH64` (183) 而不是 `EM_X86_64` (62) - Shellcode：使用 `svc #0` 而不是 `syscall` 的 aarch64 指令 - 系统调用号：setuid=146, setgid=144, setgroups=159, execve=221（而在 x86\_64 上分别是 106, 105, 116, 59） - 固定的 4 字节指令宽度（不同于 x86\_64 的变长指令），导致 payload 略大（约 216 字节，而之前是 192 字节） ## 构建与运行 ``` # Clone git clone https://github.com/linnemanlabs/dirtyfrag-arm64.git # Build cd dirtyfrag-arm64 gcc -O0 -Wall -o dirtyfrag_arm64 dirtyfrag_arm64.c -lutil # Run ./dirtyfrag_arm64 --force-esp ``` `--force-esp` 标志会完全跳过 rxrpc 路径，以确保避免在 arm64 上引发内核 oops。 ## 测试环境 | 属性 | 值 | |---|---| | 实例 | AWS t4g.micro (Graviton2) | | 操作系统 | Ubuntu 24.04.4 LTS | | 内核 | `6.17.0-1013-aws #13~24.04.1-Ubuntu` (构建于 2026-04-24) | | 架构 | aarch64 | | `unprivileged_userns_clone` | 1 (已启用) | | esp4 模块 | 可用，可加载 | | rxrpc 模块 | 可用，可加载 (但在 arm64 上会崩溃) | | 配置 | 原版 ubuntu 24.04 云镜像，默认内核模块 | 截至 2026-05-09，最新可用的 Ubuntu 24.04 aws 内核（`6.17.0-1013-aws`，构建于 4 月 24 日）尚未针对 Copy Fail (CVE-2026-31431，披露于 4 月 29 日) 或 Dirty Frag (CVE-2026-43284/43500，披露于 5 月 7 日) 打上补丁。 ## 紧急缓解措施 将易受攻击的模块加入黑名单，并针对您的发行版应用适当的系统加固措施。 ### 将模块加入黑名单 对于任何未主动使用 IPsec 传输模式 或 AFS 的系统来说，这都是安全的。为了防止加载这些模块，请将以下内容放入 `/etc/modprobe.d/dirtyfrag.conf`： ``` install esp4 /bin/false install esp6 /bin/false install rxrpc /bin/false ``` ### 卸载模块 要在正在运行的系统上卸载这些模块： ``` rmmod esp4 esp6 rxrpc 2>/dev/null ``` ### 刷新页缓存 刷新页缓存应该能清除恶意内容，并使文件重新从磁盘读取。 ``` echo 3 > /proc/sys/vm/drop_caches ``` 注意：我在这方面得到过一些不一致的结果，但我尝试重现的次数越多，它就越能按预期工作。对于这个 PoC，您可以检查 /usr/bin/su 的 md5sum，如果不匹配，请重新启动。 ### 缓解后验证 ``` sha256sum /usr/bin/su # 或从 package manager： dpkg -V util-linux # Debian/Ubuntu rpm -V util-linux # RHEL/Amazon Linux ``` ### 主动防御措施 有关应对整个漏洞类别（而不仅是特定 CVE）的更主动防御措施，请参阅完整的文章，了解 AppArmor userns 限制、模块预加载防范、基于 Tetragon 的运行时检测以及 YARA 规则。 ## 致谢 - [Hyunwoo Kim (@v4bel)](https://github.com/V4bel) - 原始漏洞研究、披露以及 x86\_64 PoC。即所有真正的工作。 - [Keith Linneman / LinnemanLabs](https://linnemanlabs.com) - arm64 移植、`flush_dcache_page` 崩溃分析以及检测规则。 ## 法律声明 本工具仅用于授权的安全测试和研究。 在未经同意的情况下，对您不拥有或未获得明确测试许可的系统使用本工具是非法且不道德的。 ## 许可证 MIT。复制它，窃取它，修改它，从中学习，与我分享您的改进。或者不分享。这只是代码，随心所欲地使用它。

标签：0day挖掘, aarch64, arm64, AWS Graviton, CVE-2026-43284, CVE-2026-43500, dcache, dirtyfrag, ESP, Exploit, Go语言工具, IPSec, Linux内核, PoC, rxrpc, Web报告查看器, 内存损坏, 内核安全, 协议分析, 客户端加密, 暴力破解, 本地提权, 权限提升, 缓冲区错误, 网络协议安全