容器安全 on KnightLi的博客

近期四個 Linux 本地提權漏洞影響梳理：Copy Fail、Dirty Frag、Fragnesia 與 ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近 Linux 生態連續出現幾起高關注度的本地安全問題。單獨看，它們分別落在加密介面、網路/IPsec 路徑、頁快取處理、ptrace 存取檢查等不同位置；放在一起看，真正值得警惕的是同一個結論：只要攻擊者已經拿到低權限本地執行點，Linux 宿主機、容器節點、CI 機器和多使用者伺服器的風險都會被明顯放大。

本文重點不複述每個漏洞的技術細節，而是整理它們對實際環境的影響，並給出站內四篇單獨分析文章作為延伸閱讀。

四次事件分別影響什麼

近期最需要關注的四個風險是：

Copy Fail（CVE-2026-31431）：低權限本地使用者可能透過內核加密相關路徑影響頁快取，進而擴大權限。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 相關）：風險集中在 xfrm/ESP、RxRPC 等網路和內核資料路徑，後滲透階段危害很高。
Fragnesia（CVE-2026-46300）：與 Dirty Frag 相近，同樣圍繞 XFRM ESP-in-TCP、共享 fragment 和頁快取寫入風險展開。
ssh-keysign-pwn（CVE-2026-46333）：不是直接 root shell 類型漏洞，而是本地資訊洩露風險，可能讀取 SSH 主機私鑰、/etc/shadow 等敏感檔案。

這四類問題的入口不同，緩解方式也不完全一樣。不能因為處理了 Copy Fail，就預設 Dirty Frag 和 Fragnesia 也安全；也不能因為禁用了某些網路模組，就認為 ssh-keysign-pwn 的資訊洩露風險自動消失。

Copy Fail：容器和 CI 節點優先級很高

Copy Fail 的關鍵影響不是「某個應用崩潰」，而是低權限執行能力可能被轉化為 root 權限。它對以下環境尤其敏感：

允許使用者上傳或執行程式碼的 CI/CD 節點。
託管不可信工作負載的容器宿主機。
開發測試機、跳板機、共享伺服器。
執行舊內核且補丁節奏較慢的雲主機。

Copy Fail 的危險點在於攻擊門檻偏低，而且容易和容器場景疊加。很多團隊把容器當作強隔離邊界，但普通容器預設仍共享宿主機內核。如果攻擊者能在容器內取得 shell，內核本地提權就可能把容器問題放大為宿主機問題。

詳細分析見站內文章：Copy Fail 漏洞 CVE-2026-31431：Linux 內核檔案複製路徑中的容器逃逸風險。

Dirty Frag：後滲透階段的放大器

Dirty Frag 更像是攻擊者進入系統後的權限放大工具。它不是典型的遠端無認證漏洞，前提通常是攻擊者已經透過弱密碼、WebShell、低權限服務帳號、容器任務或其他方式取得本地執行能力。

它的實際影響主要體現在：

已被入侵的低權限帳號可能進一步變成 root。
容器環境中的低權限執行點可能威脅宿主機。
使用 IPsec、ESP、RxRPC 或相關內核網路能力的系統需要謹慎評估補丁和臨時緩解。
安全團隊不能只看邊界防護，還要關注入侵後的提權鏈條。

Dirty Frag 提醒運維團隊：本地提權漏洞雖然不是第一入口，卻可能決定一次入侵最終能走多遠。只要存在低權限落點，攻擊者就會尋找內核漏洞把權限推到最高。

詳細分析見站內文章：Dirty Frag CVE-2026-43284：Linux 本地提權漏洞風險與緩解指南。

Fragnesia：同類攻擊面沒有一次性清乾淨

Fragnesia 的重要性在於，它說明 Dirty Frag 附近的攻擊面並不是一個孤立問題。即使某個漏洞被修復，相鄰路徑、相似資料結構、相同模組組合裡仍可能存在新的可利用點。

它對運維的影響主要是：

不能只按漏洞名稱做一次性處置，要按攻擊面持續檢查。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP 等相關路徑需要結合業務依賴評估。
如果系統不依賴相關網路能力，可以考慮臨時禁用，但必須先在測試環境確認不會影響 VPN、IPsec、隧道或內部網路功能。
頁快取污染類風險可能帶來「看似檔案沒改，實際執行路徑受影響」的檢測盲點。

Fragnesia 對企業最大的提醒是：補丁管理不能只盯單個 CVE。更穩妥的做法是圍繞子系統和攻擊面建立清單，確認哪些機器暴露相關能力，哪些業務真正需要這些模組。

詳細分析見站內文章：Fragnesia (CVE-2026-46300)：Linux 內核本地提權漏洞影響與緩解。

ssh-keysign-pwn：不直接 root，也足夠危險

ssh-keysign-pwn 與前三個漏洞的性質不同。它更偏向本地敏感資訊洩露，不是直接拿 root shell 的漏洞。但在真實攻擊中，敏感資訊洩露常常能變成更嚴重的後果。

它的影響重點包括：

SSH host private keys 洩露後，可能影響主機身分可信度。
/etc/shadow 等檔案被讀取後，可能引發離線破解和帳號接管。
多使用者伺服器、跳板機、建置機、共享開發機風險更高。
即使攻擊者沒有立刻提權，也可能拿到後續橫向移動需要的憑據材料。

這類問題容易被低估，因為它沒有「直接 root shell」那麼刺激。但對企業環境來說，密鑰和密碼雜湊洩露往往意味著更長週期的清理：輪換 SSH 主機密鑰、排查信任關係、檢查帳號密碼、審計登入日誌，都可能成為必要動作。

詳細分析見站內文章：ssh-keysign-pwn（CVE-2026-46333）解讀：Linux 本地資訊洩露、SSH 主機密鑰與 /etc/shadow 風險。

共同影響：容器隔離不能再被當作強邊界

這四次事件合在一起，最直接的影響是重新提醒大家：普通容器隔離不是虛擬機隔離。

Docker、containerd 和 Kubernetes 依賴 namespace、cgroup、capabilities、seccomp、AppArmor 或 SELinux 等機制減少攻擊面，但它們通常仍共享宿主機內核。只要漏洞發生在共享內核裡，容器內的低權限執行點就可能成為攻擊入口。

高風險環境應重點檢查：

是否允許不可信程式碼執行在共享宿主機上。
容器是否預設 root 使用者執行。
是否授予了不必要的 capabilities。
seccomp 配置是否過寬。
多租戶工作負載是否應該遷移到 gVisor、Kata Containers、Firecracker microVM、獨立虛擬機或專用節點。

對 CI/CD 平台尤其要謹慎。建置任務天然會執行外部程式碼、依賴安裝腳本、測試腳本和臨時二進位。如果這些任務與長期服務共享宿主機，一次本地提權就可能影響更大的基礎設施。

共同影響：補丁必須落到「正在執行的內核」

Linux 內核補丁有一個很常見的誤區：套件管理器顯示已經更新，不代表機器正在執行新內核。

運維上至少要確認三件事：

`1`	`uname -a`

確認目前執行內核版本。

`1`	`dpkg -l \| grep linux-image`

或在 RHEL 系發行版上：

`1`	`rpm -qa \| grep kernel`

確認已安裝內核套件。

最後，還要確認機器已經重啟到修復後的內核。對不能重啟的核心業務，要評估 livepatch、熱補丁或短期隔離方案，但不要把臨時緩解當作最終修復。

共同影響：攻擊面最小化要具體到模組和系統呼叫

這幾次漏洞涉及的路徑提醒我們，Linux 加固不能只停留在「更新系統」和「開防火牆」。

更具體的檢查方向包括：

AF_ALG / algif_aead 是否被業務使用。
XFRM、ESP、ESP-in-TCP、IPsec 是否被 VPN、隧道或安全閘道依賴。
RxRPC 是否需要啟用。
非特權使用者命名空間是否必須開放。
容器是否能建立過寬的 socket 類型。
ptrace 存取策略是否過鬆。

如果業務確實不需要某些能力，可以評估禁用模組、調整 sysctl、收緊 seccomp、減少 capabilities。生產環境不要盲目複製命令，應先盤點依賴，再灰度執行。

建議的處置順序

第一，優先修復可本地執行程式碼的高暴露機器：

容器宿主機。
CI/CD runner。
跳板機。
多使用者伺服器。
對外服務所在主機。
執行不可信插件、腳本、擴充的系統。

第二，確認發行版公告和實際執行內核。不要只看上游版本號，Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler 等發行版可能會 backport 安全補丁。

第三，收緊容器執行策略。盡量做到非 root 使用者、最小 capabilities、no-new-privileges、唯讀檔案系統、明確 seccomp 和 AppArmor/SELinux 策略。

第四，檢查密鑰和憑據風險。尤其是涉及 ssh-keysign-pwn 的環境，應評估 SSH host key、/etc/shadow、跳板機憑據和 CI secrets 是否需要輪換。

第五，補上監控。重點關注異常 root shell、可疑本地提權 PoC、關鍵檔案修改、異常 ptrace 行為、容器程序存取宿主機路徑、CI 節點上的異常網路連線。

結論

這四次事件的重點不是「Linux 不安全了」，而是「預設信任不夠用了」。

Linux 仍然是透明、可修復、可裁剪、可加固的主流系統。但在容器、CI、多租戶和 AI 自動化程式碼執行越來越普遍的環境裡，低權限執行點已經不能被看作小問題。只要內核裡存在可利用的本地提權或敏感資訊洩露漏洞，局部入侵就可能變成宿主機控制、憑據洩露或橫向移動。

更現實的做法是把這四次事件當成一次提醒：補丁要快，重啟要確認，模組要按需啟用，容器要收緊，密鑰要能輪換，多租戶要重新評估隔離等級。

站內延伸閱讀：

Copy Fail 漏洞 CVE-2026-31431：Linux 核心檔案複製路徑中的容器逃逸風險

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一個影響 Linux 核心檔案複製路徑的漏洞，編號為 CVE-2026-31431。 Bugcrowd 的分析把它稱為一個值得關注的核心級問題：在特定條件下，非特權使用者可以利用檔案複製相關邏輯觸發越權寫入，進而造成權限提升或容器逃逸。

從風險角度看，它不是普通應用層漏洞。問題發生在核心處理檔案複製和頁面快取的路徑上，因此影響面會延伸到容器、共享主機、CI/CD Runner、PaaS 平台和多租戶 Linux 環境。如果攻擊者已經能在系統裡執行低權限程式碼，漏洞就可能成為進一步突破隔離邊界的跳板。

漏洞大致發生在哪裡

Copy Fail 關聯的是 Linux 核心中的檔案複製能力。現代 Linux 提供了多種高效複製路徑，例如 copy_file_range、splice 類路徑以及不同檔案系統之間的資料複製最佳化。這些機制的目標是減少使用者態和核心態之間的資料搬運，提高大檔案複製效能。

問題在於，高效能複製路徑通常會複用頁面快取、檔案偏移、權限檢查和檔案系統回呼。如果其中某個邊界條件處理不嚴，核心可能在錯誤的權限上下文裡執行寫入，或者把本不應該被修改的資料頁暴露給攻擊者控制。

Copy Fail 的核心風險可以概括為：

攻擊者不需要 root 權限；
攻擊入口來自常見檔案複製能力；
影響點在核心態；
在容器環境裡，漏洞可能繞過命名空間和掛載隔離；
成功利用後可能寫入宿主機上不應被容器修改的內容。

這也是它被重點討論的原因。容器安全依賴 Linux 核心提供隔離能力，一旦核心路徑本身出現越權寫入，容器邊界就會變得脆弱。

為什麼容器場景更敏感

容器並不是虛擬機。容器內行程和宿主機共享同一個 Linux 核心，只是透過 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等機制做隔離。

如果漏洞發生在使用者態服務裡，通常只影響某個容器或某個行程。但如果漏洞發生在核心裡，尤其是可以被非特權使用者觸發的核心漏洞，攻擊者可能從容器內部影響宿主機。

Copy Fail 的危險點就在這裡。很多平台允許使用者提交建置任務、執行腳本、啟動容器或執行外掛。攻擊者只要能在容器裡執行程式碼，就可能嘗試利用核心檔案複製路徑突破隔離。

高風險環境包括：

Kubernetes 叢集中的不可信工作負載；
CI/CD 平台的共享 Runner；
允許使用者上傳程式碼執行的沙箱平台；
多租戶 Linux 主機；
容器化 PaaS；
執行第三方外掛或擴充的系統。

如果這些環境裡的核心版本處於受影響範圍，而且缺少額外限制，風險就會明顯升高。

受影響範圍要看核心補丁狀態

這類漏洞的判斷不能只看發行版名稱。同一個 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影響取決於目前實際執行的核心套件，以及發行版是否已經回補補丁。

排查時應優先確認三件事：

目前執行核心版本；
發行版安全公告是否提到 CVE-2026-31431；
雲端廠商或託管平台是否已經完成宿主機核心修復。

可以先在系統上確認核心版本：

`1`	`uname -a`

然後查看發行版安全公告、核心 changelog 或雲端平台公告。不要只根據主版本號判斷是否安全，因為很多企業發行版會把安全補丁回補到舊版本核心裡。

臨時緩解思路

最可靠的修復方式仍然是更新核心。但在補丁無法立刻部署的環境裡，可以先降低暴露面。

常見緩解方向包括：

禁止不可信使用者執行特權容器；
避免給容器掛載敏感宿主機路徑；
收緊容器 capability，尤其不要隨意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危險系統呼叫和檔案存取；
將不可信工作負載遷移到隔離更強的虛擬機；
對 CI/CD Runner 做按任務銷毀，避免長期複用同一宿主機；
監控異常檔案寫入、權限變更和容器逃逸跡象。

這些措施不能替代補丁。它們的作用是降低攻擊成功率和影響面，特別是在補丁發布到生產環境之前爭取緩衝時間。

修復優先級

建議按環境風險排序處理。

優先修復：

對外提供容器執行能力的平台；
執行不可信程式碼的 CI/CD 節點；
多租戶 Kubernetes 節點；
有使用者自定義外掛或腳本執行能力的系統；
共享開發機、教學機、實驗平台。

相對低優先級：

單使用者桌面；
只執行可信服務的內網主機；
已經使用虛擬機隔離不可信程式碼的環境。

即便風險較低，也建議隨發行版更新核心。核心漏洞常常會被組合進更複雜的攻擊鏈裡，拖延補丁沒有太多收益。

給維運團隊的檢查清單

可以按下面順序處理：

盤點所有 Linux 主機和容器節點；
標記會執行不可信程式碼的機器；
檢查目前核心版本和發行版安全公告；
優先更新高風險節點；
對無法立即更新的節點啟用臨時隔離策略；
檢查容器執行時設定，移除不必要的特權和宿主機掛載；
更新後重啟節點，確認新核心已經實際生效；
保留變更記錄，方便後續稽核。

核心套件安裝完成並不代表系統已經執行在新核心上。更新後必須重啟，並再次確認：

`1`	`uname -a`

小結

Copy Fail / CVE-2026-31431 的重點不是某個應用崩潰，而是 Linux 核心檔案複製路徑中的權限邊界問題。它讓非特權程式碼有機會觸碰更高權限的資料寫入路徑，因此在容器和多租戶環境裡尤其值得重視。

處理這類漏洞時，最重要的是兩件事：

盡快跟進發行版或雲端廠商提供的核心補丁；
在補丁部署前限制不可信程式碼、特權容器和敏感宿主機掛載。

對個人桌面來說，它可能不是馬上需要恐慌的問題。但對執行容器平台、CI/CD、沙箱和共享主機的團隊來說，應該把它當作高優先級核心安全更新處理。

參考來源：