M08 · CTF
驗 audit token 不驗 PID（confused-deputy 防線）
IPC 圖含一個 sandboxed-renderer（低權）、一個 privileged-xpc（高權 daemon），以及一條 renderer→daemon 的 mach-lookup/XPC 連線。daemon 收到請求後要決定「該不該為呼叫方做這件高權操作」。找出 daemon 目前用「呼叫方 PID →以 PID 查身分」來判定這個信任缺陷類別（confused-deputy 的根因），指出根因是 PID 可被回收重用導致的 TOCTOU （查身分與用身分之間對錯了對象），並選對防禦：改用連線的 audit token（含 pidversion，kernel 擔保的訊息發送者）， 對它驗 sandbox（sandbox_check_by_audit_token）與 code requirement（SecCodeCreateWithAuditToken）。引擎跑 「若改用 audit-token 驗證，此信任缺陷是否被擋」的反事實。本關只判定「指出類別＋根因＋防禦」，不存在也不接受任何可操作 exploit。
XPC 呼叫方驗證（confused-deputy 根因 vs 防禦）
- 高權 service 收到請求，需決定「該不該為這個呼叫方做事」。
- 用 PID 識別呼叫方 → 再拿 PID 去查身分/entitlement。
- PID 在 check 後、use 前被回收給另一個（低權）進程（TOCTOU 窗口）。
- service 對「原本那個 PID 的身分」放行，實際服務的卻是新進程 → 身分對錯對象。
根因：用 PID 認呼叫方（check 與 use 之間 PID 可被回收 → 身分對錯對象）。防禦一句話：驗 audit token，不驗 PID（含 pidversion，kernel 擔保）。本實驗室只示範類別與防禦，不含提權步驟。
過關目標
- 讓 graph.selectedFlaw.edge 達到 "renderer_to_daemon.callerIdentityCheck"
- 讓 rootCause.class 達到 "confused-deputy"
- 讓 rootCause.mechanism 達到 "pid-reuse-toctou"
- 讓 defense.chosen 達到 "verify-audit-token-not-pid"
- 讓 counterfactual.withAuditTokenCheck.flawBlocked 達到 true
- 用自己的話解釋：為什麼「用呼叫方 PID 去查身分再放行」屬於 confused-deputy 類別？請用 PID reuse / TOCTOU 說明根因，並說出正確防禦（驗 audit token 不驗 PID）具體要用哪些 API（audit token、sandbox_check_by_audit_token、SecCodeCreateWithAuditToken），以及 audit token 的 pidversion 為何能消掉重用歧義。
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
缺陷不在某個 port 上，而在 daemon「怎麼識別呼叫方」這條判定上——它用了 PID，而 PID 不是 kernel 對「這條訊息發送者」的擔保。
走錯方向時
根因是 PID reuse 造成的 TOCTOU：查到「PID 1234 是受信任 App」與「現在送訊息的還是當初那個 1234」之間有時間差，原進程結束後 PID 可被別的進程取得，身分就對錯了對象。
想更深入
防禦＝驗 audit token 不驗 PID。用 xpc_connection_get_audit_token 取連線的 audit token（含 pidversion，無重用歧義），對它做 sandbox_check_by_audit_token 與 SecCodeCreateWithAuditToken 釘 client requirement。本關不涉及任何提權鏈步驟，只判類別／根因／防禦。