Project Zero 談緊急修補：不等完整更新，先用四種手段止血
Google Project Zero（Natalie Silvanovich） · 2026-10-06
當漏洞已經在傷害使用者，廠商不能再走「完整測試、完整發版」那條好幾週的路，而是要先用比正式 patch 更快的機制把洞堵住。Project Zero 在〈How to fix a bug in a fix〉裡，把這類緊急修補拆成四種做法，並指出 LLM 正在同時拉高攻擊者與防守者的漏洞發現與利用能力，廠商應該現在就把緊急應變的機制準備好。
原本的問題：正常修補流程太長
文章把一般修補流程分成六段：分流（triage）、開發修補、測試、夥伴審查、派送、啟用。其中最後的「啟用」有時還要重開機之類的額外動作，才能真正切換到新版軟體。
作者的判斷是：多數廠商的修補速度，瓶頸落在測試與派送兩段。測試不能省，因為沒測好的更新可能讓裝置「變磚」，連接收後續更新的能力都失去。所以緊急情況下的設計重點，是繞過這兩段，而不是壓縮它們。
四種緊急手段
| 手段 | 做法 | 文中例子 |
|---|---|---|
| 功能旗標 | 事先測好開關兩種狀態，出事時只切旗標 | Apple 2019 年用旗標關閉 Group FaceTime；Meta 的 WebRTC 雙版本 |
| 過濾 | 用可動態更新的規則擋掉特定攻擊路徑 | Android Intent Firewall（XML 規則） |
| 替代通道 | 不等整機更新，單獨更新元件 | Android APEX、以 dlopen 載入網路下發的函式庫 |
| 熱修補 | 執行中替換函式，不必重啟 | Linux Livepatch、Windows hotpatch |
功能旗標與過濾
功能旗標的價值在於測試可以提前做：每個旗標狀態都先測過，緊急時出貨的就不是沒測過的程式碼。Meta 的作法是同時帶兩個版本的 WebRTC 函式庫（dual stack），由旗標控制，出問題時能快速切換版本。
過濾則是針對特定漏洞，停用觸發它的某種用法。Android Intent Firewall 用可動態更新的 XML 規則，關掉特定 IPC 機制的特定用法；文中提到它近期被用來擋下 Android 錢包類應用裡第三方 SDK 的漏洞。作者提醒，新的過濾規則也要先測試，避免誤擋正常功能。
旗標： feature_x = on → feature_x = off （兩種狀態皆已預先測試）
過濾： 更新 XML 規則，停用特定 IPC 用法 （不改程式碼）替代通道與熱修補的限制
Android APEX 讓元件可以比整套系統更新更快送達。有些應用程式也會用網路旗標加 dlopen 單獨更新函式庫。風險在驗證：文章警告，這種方式送來的函式庫，客戶端往往沒有充分驗證它確實來自廠商，驗證不足本身就可能引入嚴重漏洞。
熱修補（Linux Livepatch 在記憶體中替換核心函式，Windows hotpatch 對執行中的程序送新函式）免重啟，但有明確限制：無法處理需要改動「函式間共用的結構定義」的更新。
影響範圍
- 維護自家更新機制的廠商：檢查你現有的旗標、規則推送、元件更新是否已能在一天內送出，並確認事先有測過各種狀態。
- 自己用
dlopen拉遠端函式庫的 App 團隊：補上來源驗證，否則緊急通道本身會變成新的攻擊面。 - 核心或系統層維護者：先判斷修補是否涉及共用結構，涉及就無法靠熱修補，要另找手段。
文章未提供任何 CVE 編號或量化數據，結論也沒有說哪一種手段最好，而是主張組合使用，各自覆蓋不同類型的漏洞。