When Queues Become Vulnerabilities: Reverse Engineering GCD, XPC Races, and macOS Detection
三句話摘要
在 macOS 上透過 GCD 佇列分析與遙測檢測競態條件，防止特權服務因併發配置錯誤導致沙箱逃逸。 透過佇列配置審查、併發壓力遙測監測、以及相對基線的行為異常檢測，可以在 macOS 特權服務的競態條件演變為可利用漏洞前攔截它們。 優先權反轉與同步原語選擇的安全後果
重點整理
重點- 1
優先權反轉與同步原語選擇的安全後果
- 2
GCD 使用 QoS 等級（服務質量）排程任務，高優先順序任務若等待持有鎖的低優先順序任務完成，會導致優先權反轉。Pthread 互斥鎖和 OS 不公平鎖支援優先權繼承（核心臨時提升低優先順序執行緒許可權），但排程訊號量和自旋鎖不攜帶所有權資訊，無法通知排程器應提升哪個執行緒，因此成為"訊號量反模式"的根源——高成本工作項同步等待低成本任務，意外造成服務停滯。
- 3
dispatch_sync 導致的排程死鎖
- 4
對正在執行的同一序列佇列呼叫 dispatch_sync 會立即凍結。經典案例：主執行緒呼叫主佇列的 dispatch_sync，或工作執行緒排隊後又對主佇列執行同步排程，導致主執行緒阻塞等待可用工作執行緒，而所有工作執行緒都被主執行緒佔用，形成無法避免的迴圈等待。
- 5
GSS Cred 漏洞：佇列配置錯誤演變為許可權提升漏洞
- 6
2018年 Brandon Azad 發現的 CVE 中，macOS 的 com.apple.gsscred XPC 服務本應使用序列佇列序列化憑證操作，但未繫結目標佇列，導致訊息處理程式預設使用併發佇列。攻擊者透過並行 XPC 請求製造競態視窗——一個執行緒釋放憑證同時另一個執行緒仍在使用——從而在特權根上下文中破壞記憶體並注入任意程式碼。這表明隱式執行緒假設本質不安全，特權 XPC 服務必須顯式強制序列化。
- 7
三層檢測框架：靜態審查、遙測、行為檢測
- 8
靜態審查尋找佇列配置缺陷（缺失目標佇列、隱式序列假設、dispatch_sync 濫用、無鎖的共享可變狀態）。遙測監測併發壓力跡象：重複崩潰模式、執行緒建立峰值、佇列積壓與長同步等待時間。行為檢測標記相對基線的異常執行緒建立頻率、高併發 XPC 請求速率、佇列排空延遲異常——這些往往先於明顯崩潰出現，且是對抗性時機探測的典型遙測特徵。
實用技巧與重點
乾貨- 核心概念與工具
- Grand Central Dispatch (GCD)：Apple 併發框架
- 佇列型別：序列佇列（FIFO 一次一任務）/ 併發佇列（多工並行）
- QoS 等級：決定排程優先權和 CPU 資源分配
- Pthread 互斥鎖、OS 不公平鎖：支援優先權繼承
- 排程訊號量、自旋鎖：不支援優先權繼承，易導致反轉
- dispatch_sync / dispatch_async：同步（阻塞）/ 非同步（非阻塞）排程
- Xcode 執行緒效能檢查器：執行時檢測優先權反轉工具
- libdispatch：GCD 底層實現，使用執行緒池執行併發佇列任務
- XPC：macOS 程序間通訊機制
- com.apple.gsscred：macOS 身份服務（管理 Kerberos/企業 SSO 憑證）
- 漏洞案例
- CVE (2018年) - GSS Cred XPC 服務：佇列配置錯誤 → 併發處理代替序列化 → 競態視窗 → 記憶體損壞 + 根上下文程式碼執行
- 檢測訊號
- 靜態審查模式
- XPC 連線佇列檢查：是否總是呼叫目標佇列中的處理程式
- 隱式序列假設：程式碼依賴"請求逐個到達"但未強制執行
- dispatch_sync 濫用：對高優先順序程式碼中的相同佇列呼叫
- 共享可變狀態無同步：全域性單例/共享物件在多處理程式間無鎖訪問
- 遙測訊號
- 重複崩潰/斷言失敗，尤其在狀態轉換、清理路徑、請求處理邊界
- 執行緒建立峰值/異常佇列清空行為變化
- 佇列等待時間過長、同步負載過重、工作堆積速度超過處理速度
- 相對基線的執行緒建立頻率異常增加
- 行為檢測
- 標記相對基線的執行緒峰值頻率（而非絕對數量）
- XPC 呼叫速率異常（高併發請求量指向競態探測）
- 佇列排空/同步等待時間異常（死鎖、鎖爭用、排程反轉的強烈訊號）
結論
結論“透過佇列配置審查、併發壓力遙測監測、以及相對基線的行為異常檢測，可以在 macOS 特權服務的競態條件演變為可利用漏洞前攔截它們。”
完整解析
詳細macOS 上的競態條件不僅僅是可靠性問題，也是嚴重的安全隱患。為了理解這一點，需要先掌握 GCD 的工作原理。GCD 是 Apple 的併發框架，透過佇列抽象執行緒管理細節。系統提供兩類排程佇列：序列佇列確保任務按接收順序逐一執行，併發佇列允許多個任務同時執行。關鍵是 QoS（服務質量）等級——它直接影響排程優先權和 CPU 資源分配。高優先順序任務若等待持有資源的低優先順序任務完成，就會發生優先權反轉，導致高優先順序工作被阻塞。這種問題在特別是使用不支援優先權繼承的同步原語（如訊號量和自旋鎖）時尤為嚴重。排程器無法瞭解所有權關係，因此無法自動提升低優先順序執行緒的許可權。
另一類常見漏洞源於 dispatch_sync 的誤用。dispatch_sync 在目標佇列的任務完成前會阻塞當前執行緒。如果對同一序列佇列呼叫 dispatch_sync，執行緒會陷入自等待——本應執行佇列中的任務以解除阻塞，但執行緒本身正被阻塞，導致即時凍結。這類錯誤在系統守護程序中特別危險，因為它們會耗盡有限的 GCD 工作執行緒池。極端情況下，如果所有工作執行緒都被阻塞，libdispatch 會建立更多執行緒試圖打破僵局，導致"執行緒爆炸"——幾十甚至幾百個執行緒瘋狂消耗 CPU 資源，卻無實際進展。
2018年的 GSS Cred CVE 完美詮釋了這些原理如何演變成現實漏洞。Brandon Azad 發現 macOS 的身份服務（com.apple.gsscred）XPC 服務存在競態條件。該服務本應用序列佇列序列化所有憑證操作，但由於未繫結目標佇列，訊息處理程式預設在併發佇列上執行。攻擊者透過平行傳送多個 XPC 請求，製造精確的競態視窗——一個執行緒釋放憑證同時另一個執行緒仍在使用——導致記憶體損壞。由於該服務以 root 許可權執行，攻擊者成功在特權上下文中執行任意程式碼，實現完整的沙箱逃逸。這個案例表明隱式執行緒假設本質不安全，特權服務必須顯式強制序列化。
從檢測角度，防禦分為三層。首先進行靜態審查，尋找佇列配置缺陷——是否所有 XPC 連線都設定了明確的目標佇列，程式碼是否隱含地依賴序列處理，是否存在 dispatch_sync 對同一佇列的呼叫，共享狀態是否缺乏鎖保護。其次監測遙測訊號：重複的崩潰模式（尤其在時間敏感的程式碼路徑）、執行緒建立峰值、佇列積壓與長同步等待時間——這些往往先於明顯故障出現。最後運用行為檢測，相對於程序的基線標記異常的執行緒建立頻率增加（某程序突然變得比平時更"吵鬧"），檢測向特權守護程序發起的高併發 XPC 請求（可能在探測競態視窗），以及佇列排空延遲的異常峰值。這三層防禦相輔相成——靜態分析指出漏洞在哪，遙測顯示何時承受壓力，行為檢測識別何時被對抗性操縱。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
