CVE-2026-31431：Copy Fail 對上 rootless 容器 （★ 122 分）
這篇文章實測 CVE-2026-31431（Copy Fail）在 rootless Podman（以非 root 身分執行的 Podman）中的影響。作者先拆解公開 exploit，指出所謂 shellcode 其實是一個極小的 ELF（Executable and Linkable Format，Linux 常見可執行檔格式）二進位檔，會透過 `setuid(0)` 嘗試取得 root，接著執行 `/bin/sh`。攻擊手法不是直接改寫磁碟上的 `/usr/bin/su`，而是利用 Linux 核心的 AF_ALG（核心提供給使用者空間的加密 API）與 `splice()`，把惡意 ELF 分段寫入 `/usr/bin/su` 的頁面快取（page cache），讓系統執行 `su` 時載入被污染的快取內容。
作者在 Fedora 43、Linux 6.17.1 的測試環境中重現漏洞，並用 `strace` 追蹤 system call（系統呼叫），確認 exploit 會建立 AF_ALG socket、綁定到 `authencesn(hmac(sha256),cbc(aes))`，再以 4 位元組為單位將 payload 寫入頁面快取。由於 `strace` 會影響 SUID（Set User ID，執行時套用檔案擁有者身分）程式的權限轉換，作者另用 eBPF（extended Berkeley Packet Filter，可在核心層追蹤事件的機制）從主機觀察 `setuid(0)`：未受 `ptrace` 干擾時，漏洞確實能在容器內取得 root shell。
關鍵結論是，rootless Podman 的 User Namespace（使用者命名空間）阻止了這次權限提升擴散到主機。容器內的 UID 0 會對應到主機上的一般使用者 UID 1000，也就是 `podman` 帳號；因此攻擊者即使在容器內看到 root prompt，也無法修改主機系統檔案、讀取主機 `/etc/shadow`，或操作命名空間外的主機程序。作者認為這正是 rootless 架構的價值，也建議 OpenShift 使用者啟用 pod 的 User Namespace。不過文章後續補充指出，頁面快取仍可能在同一主機上被共享：若多個容器共用相同映像檔層，一個惡意 CI 工作可能污染某個二進位檔的快取，導致其他使用同一層的容器執行被毒化的版本，削弱容器之間的隔離。
Hacker News 討論多半肯定文章對 exploit 機制的拆解，但也有不少人提醒，這不是新的 CVE 公告，而是一次 rootless 容器情境下的實驗紀錄。技術上最受重視的批評是：Copy Fail 的「寫入唯讀頁面快取」原語仍然成功，rootless Podman 只是讓這個特定的 `su` 權限提升無法變成主機 root；若攻擊目標換成共用映像檔層、唯讀 bind mount、憑證目錄或其他 CoW（copy-on-write，寫入時複製）來源，仍可能破壞跨容器或跨租戶隔離。也有人指出，單靠 systemd 的 CapabilityBoundingSet（能力邊界設定）只能限制完整 root 權限，無法涵蓋 Copy Fail 可造成的其他檔案快取污染情境。
社群也討論了緩解方式與架構取捨。有人建議暫時停用 `algif_aead` 模組，或在 seccomp（secure computing mode，Linux 限制 system call 的沙箱機制）政策中封鎖 AF_ALG；Docker/Moby 與 containers 生態也已有相關政策或工具更新。反方則質疑是否應因單一漏洞長期停用核心加密介面，但多位留言者認為 AF_ALG 很少被一般工作負載使用，且過去曾多次出現安全問題，封鎖它的實務成本相對低。更廣泛的討論則集中在容器是否足以作為安全邊界：有人主張容器是便利邊界而非強安全邊界，microVM、gVisor 或完整 VM 的攻擊面較小；也有人認為安全隔離本來就是連續光譜，rootless 容器至少能有效降低這類 Linux 核心本機權限提升漏洞的直接傷害。
👥 57 則討論、評論 💬
https://news.ycombinator.com/item?id=48017813