Fragnesia 把內核洞變成 root 權限

我把 Fragnesia 這個 Linux 內核漏洞拆成可執行的補丁與偵測清單，直接拿去做主機風險處理。

我最近一直在看 Linux 內核的漏洞公告，看久了真的會有一種很煩的熟悉感：每次都不是那種「哇，超戲劇化」的故事，反而是這種最討厭的類型。Fragnesia 這個洞，我一看到 SecurityWeek 的整理就先皺眉。不是因為名字很帥，是因為它聽起來就是那種會讓你整台 Linux 主機從「還行」直接掉到「怎麼又是我」的本地提權洞。

我最不爽的地方在於，它不是什麼很顯眼的外網 RCE，也不是那種一眼看得出來的爆炸型漏洞。它是本地的，這種最容易被低估。很多團隊會說「我們那台機器又沒對外開放」，然後就把風險往後拖。問題是，只要攻擊者先拿到一般使用者權限，內核一出事，root 就可能被拉出來。這種洞最會偷時間，等你想起來要修，通常已經有人開始玩你的主機了。

這篇我不是要寫成新聞稿，我是要把這種漏洞的處理邏輯拆給你看。你不用記住 Fragnesia 這個名字，你要記住的是：本地提權洞在營運上不是「小問題」，它常常是把前面那個小破口，直接接到整台主機失守。

先講結論：這不是單一 CVE，是主機接管路線

這個問題在 Linux 內核的 XFRM ESP-in-TCP 子系統裡，讓未授權的本地攻擊者有機會透過覆寫敏感系統檔案拿到 root。

翻譯一下就是：攻擊者不需要先打穿外網服務，只要能在機器上站穩一個一般帳號，就可能用內核洞把權限一路往上抬，最後變成 root。這不是理論課，是 Linux 權限邊界被硬生生戳破。

我看這類洞最怕的不是技術細節，而是團隊反應太慢。很多人一聽「本地」就鬆懈，覺得不算急。但本地提權的可怕之處，就是它常常是後面那一段。前面可能是釣魚、弱密碼、容器逃逸、開發機被偷 token，後面接上這個洞，整台機器就被補成 root shell。

實操上，我會直接把它當成主機接管事件來排優先級，不會當成單純 kernel patch。只要你的環境裡有一般使用者、共享主機、CI runner、跳板機、開發者工作站、或多租戶 Linux 環境，這洞都應該往前排。短命 VM 也不要自我安慰，短命不等於沒窗口。

• 先盤點所有允許本地登入的 Linux 主機。
• 把「外網風險」和「本地提權風險」分開看，不要混在一起。
• 有 shell 的主機先補，沒有 shell 的主機後補。

XFRM ESP-in-TCP 很冷門，但冷門不等於安全

這次最值得注意的技術面，是它落在 XFRM ESP-in-TCP 這個內核面。老實說，這種東西大多數團隊平常根本不會碰，除非你在做 VPN、加密封裝、或比較底層的網路堆疊。也因為冷門，大家才容易放過它。內核從來不在乎某個功能熱門不熱門，只要有 bug，就能變成攻擊面。

我看到 Microsoft 安全部落格 的相關說法時，最在意的是它提到這個原語像是內核中的記憶體寫入，接著能去破壞 /usr/bin/su 的 page cache。這種鏈條我很熟：先拿到寫入能力，再去污染一個你本來以為可信的東西，然後借它把權限升上去。很土，但很有效。

更麻煩的是，Microsoft 的說法還提到不只 /usr/bin/su，任何使用者可讀的檔案都有可能被改。這句話很重要，因為它把偵測思路整個往外拉了。你不能只盯著 su，有可能連 /etc/passwd 這種東西都要看。換句話說，這不只是權限問題，還是檔案完整性問題。

實操上，我會先問三件事：你的主機有沒有真的需要這個功能、你的檔案完整性監控有沒有覆蓋到可讀系統檔、你的 EDR 能不能抓到異常寫入行為。很多團隊監控做得很努力，但只盯一個符號檔，這種範圍太窄了。

• 檢查哪些主機真的需要 XFRM 相關功能。
• 把可讀系統檔納入完整性監控，而不是只看 su。
• 把異常寫入、權限跳升、root shell 這三件事串起來看。

它跟 Dirty Frag、Copy Fail 同一掛，這才是重點

SecurityWeek 提到 Fragnesia 跟 Dirty Frag、Copy Fail 類似。我覺得這個比喻很有價值，因為它不是在幫漏洞取綽號，而是在提醒你：這不是孤立事件，是一種重複出現的內核失敗模式。

我自己對這種家族型漏洞的反應會比較直接。只要同一類本地提權洞開始連著出現，防守策略就不能再每次都重新發明一次。你要的是一套固定流程：先補、再看、再追。本地提權洞的核心從來不是「會不會 crash」，而是「能不能把低權限變成 root」。

我以前待過一個環境，每次 kernel CVE 都像獨立專案。A 主機歸 A 團隊，B 主機歸 B 團隊，大家都說自己很忙，最後就是最重要的機器一直卡在待排程。那種狀態我看過一次就夠了。你越把每個洞當特例，越容易讓真正危險的主機躺著等。

實操上，我會把這類洞做成一個共用 runbook，不要每次都重寫。只要是內核本地提權，預設動作就是先修補，再做追查。你不需要先把每個 exploit 細節研究到像寫論文，先讓主機不要繼續裸奔比較重要。

有 PoC 就是開始倒數，不是「還沒爆」就安全

這次報導也提到有 proof-of-concept exploit，但目前沒有看到明確的實際攻擊證據。很多人看到這句就會鬆一口氣，我倒是相反。只要 PoC 已經公開，時間就開始往下走了，不是往上走。

「還沒有證據」不等於「沒事」。通常只是代表攻擊者還沒大規模出手，或是防守方還沒把線索串起來。PoC 一出來，從公告到被拿去濫用的距離通常只會越來越短，不會越來越長。

我自己會把 PoC 當成 SLA 的縮短器。以前你可能還能說「下個維護窗再修」，現在不行。只要有可用 PoC，這就是能被複製貼上的攻擊腳本，很多人會拿來測、拿來改、拿來打。你不應該假設外面沒人在試。

實操上，我會用「有 shell 的主機」和「有延後補丁的主機」兩個條件去排優先級。不是照部門喜好排，也不是照誰聲音大排。誰有機會被提權，誰就先修。

• 每個高影響內核漏洞都標記是否已有 PoC。
• 只要有 PoC，補丁 SLA 直接縮短。
• 有本地登入權限的主機，一律往前排。

偵測不要追爆點，去追結果

我很喜歡這類報導的一點，是它沒有把重點放在很炫的 exploit 細節上。這樣才對。大部分防守者根本不需要那種像密碼學論文一樣的步驟，他們需要的是結果：檔案被改了、權限跳了、root shell 出現了、正常管理行為不見了。

很多團隊會犯一個很常見的錯：等 exploit 特徵。這很累，也很不穩。因為內核洞的手法可能變，但結果通常很像。你看到一個一般使用者突然長出 root session，這比你硬追某個脆弱字串更有用。

我之前在一個案子裡就碰過這種情況，真正有價值的不是 payload 長什麼樣，而是使用者登入後，幾分鐘內就出現不合理的檔案變動和權限轉換。那才是你應該抓的東西。不要把自己綁死在 exploit 指紋上，結果很多事根本看不到。

實操上，我會把偵測重點放在三塊：權限跳升、系統檔變更、異常 root session。你有 audit log 就串 audit log，有 EDR 就串本機行為與檔案寫入。如果你兩個都沒有，那不是「先觀察看看」，那是該補基礎能力了。

補丁順序，比你補得漂不漂亮更重要

Microsoft 建議盡快套用可用修補，我同意，而且我想把話講得更白一點：補丁順序比補丁完美更重要。你不需要等一個看起來很體面的變更流程才開始降風險。你需要的是先把最危險的主機拉下來。

所以順序應該是：靠近外部的 Linux 伺服器、共享跳板機、CI runner、開發者工作站、允許多使用者登入的主機，全部先排前面。這些地方本來就比較容易有一般帳號存在，也比較容易被拿來當提權跳板。你如果把補丁排程拖到下個維護週期，很多時候就是在幫攻擊者爭取時間。

我不太吃那種「等各家發行版公告一致再說」的做法。內核不會因為你的工單流程很漂亮就晚一點被打。你只要知道風險存在，而且有可用修補，就可以開始動。

實操上，我會先列一份最小清單：哪些主機最值錢、哪些主機最容易有本地帳號、哪些主機一旦被 root 就能橫向移動。先修這些，其他再談。

• 先補高風險 Linux 主機，不要平均用力。
• 有本地使用者的主機優先。
• 不要等所有維護窗口都對齊，先止血。

可抄的模板

# Fragnesia 事件處理模板（Linux 主機版）

## 1. 影響範圍
- 允許本地登入的 Linux 主機
- 共享伺服器、CI runner、開發者工作站
- 可能受影響的內核版本主機

## 2. 立即動作
- 第一時間套用供應商釋出的修補
- 需要重開機就重開，不要硬撐
- 先處理有 shell、多人共用、或權限較寬的主機

## 3. 偵測重點
- 是否出現不合理的 root shell
- 是否有可讀系統檔被異常修改
- 是否有 `/usr/bin/su`、`/etc/passwd` 等檔案完整性警示
- 是否有本地使用者登入後短時間內出現權限跳升

## 4. 威脅狩獵問題
- 某個本地帳號在提權前是否有異常讀檔行為？
- 是否出現 kernel 警告、異常 crash、或 page cache 異常？
- 同一台主機上是否有不合理的管理行為痕跡？

## 5. 控制與隔離
- 若懷疑已被利用，先把主機隔離
- 暫時停用不必要的本地帳號
- 重新輪替受影響主機上的憑證
- 若完整性無法信任，直接重建主機

## 6. 作業原則
- 這不是單純 kernel bug，這是主機接管路線
- 不要等到確認有實際攻擊才修
- 只要有 PoC，就應該縮短 SLA

這段模板我故意寫得很直，因為事故處理時最怕花俏。你不需要先把文件修到像對外公告，先讓值班的人能照著做，比什麼都重要。你可以直接把它貼進 runbook、ticket、或值班 SOP。

原始來源是 SecurityWeek 的 Fragnesia 報導。我上面的拆解有一部分是沿著這篇報導延伸出來的防守思路，模板則是我把 Linux 主機處理流程重新整理成可直接使用的版本。

如果你要補上下游脈絡，我會順手看 kernel.org、Microsoft Security，以及你自己發行版的公告頁，例如 Ubuntu Security Notices 和 Red Hat Security Updates。我這篇是衍生整理，不是原始爆料。