對於許多開發者來說，沙箱（Sandbox）就像是一個安全的隔離室，我們讓 AI Agent 在裡面執行程式碼或處理檔案，以為它無法接觸到我們電腦中的敏感資料。然而，近期揭露的 Claude Cowork 漏洞（代號 SharedRoot）給了我們一個深刻的教訓：如果底層的虛擬化配置不當，即使有沙箱，攻擊者或 AI Agent 依然能輕易地「逃逸」到主機系統中。
這篇分析將為工程師詳細拆解這個漏洞的運作脈絡，以及為什麼單靠更新補丁無法根除這類結構性風險。
沙箱逃逸的技術路徑
Claude Cowork 在 macOS 上運作時，採用了一種混合架構。桌面應用程式以當前登入使用者的權限執行，而實際的 AI Agent 工作則運行在一個透過 Apple Virtualization framework 建立的 Linux 虛擬機（VM）中。
為了確保安全，這個 VM 採取了多層防護：每個會話都有獨立且無權限的用戶，並使用了 seccomp（Secure Computing Mode，一種 Linux 核心機制，用來限制系統呼叫，防止程式執行危險的操作）來限制 Agent 的行為。
然而，漏洞出在檔案共享的設計上。為了讓 AI 能讀取使用者指定的資料夾，系統使用了一個名為 coworkd 的根權限守護進程（root daemon）將主機檔案系統掛載到 VM 中。致命的設計在於：整個主機的根目錄（/）都被以讀寫權限掛載到了 VM 的 /mnt/.virtiofs-root 路徑下，雖然只有 VM 內具備 root 權限的用戶才能看到，但這就為逃逸留下了後門。
從無權限用戶到主機控制權的三步走
要完成這次逃逸，攻擊者需要完成一個權限提升鏈（Privilege Escalation Chain）：
第一步：獲取網路管理權限 透過建立使用者命名空間（User Namespace）與網路命名空間（Network Namespace），Agent 在其私有網路環境中獲得了 CAP_NET_ADMIN 權限。這讓它能夠操作 Linux 核心的網路相關路徑。
第二步：利用核心漏洞獲取 VM Root 權限 利用第一步獲得的權限，Agent 可以觸發 Linux 核心中 act_pedit（流量控制封包編輯子系統）的漏洞（CVE-2026-46331，稱為 pedit COW）。透過這個記憶體錯誤，Agent 能將自己的權限從普通用戶提升為 VM 內部的 root 用戶。
第三步：從 VM 跨越到 macOS 主機 一旦成為 VM 的 root，Agent 就能看到之前提到的 /mnt/.virtiofs-root。由於這裡直接對應到 macOS 主機的根目錄且具備讀寫權限，Agent 隨即可以讀取主機上的 SSH 金鑰、雲端憑證以及任何使用者權限下的檔案，完全繞過了 macOS 的權限提示。
結構性風險：為什麼補丁不是唯一答案
這起事件最值得工程師思考的是，這並非單一漏洞的問題，而是結構性的設計缺陷。
研究人員指出，Linux 的網路調度子系統（net/sched）經常出現類似的漏洞模式：一個可自動載入的模組，加上一個普通用戶可觸及的配置路徑，最後接上一個記憶體漏洞。即使修補了這次的 CVE，只要主機根目錄依然被掛載到 VM 中，下一個核心漏洞出現時，逃逸鏈條會立刻重新生效。
這意味著開發者陷入了「永遠落後一個漏洞」的被動局面。
如何正確設計 AI Agent 的隔離環境
為了避免類似的沙箱逃逸，實務上應採取以下防禦策略：
最小化掛載範圍 絕對不要將主機的根目錄（/）掛載進 VM。應該僅掛載使用者明確授權的特定資料夾，且除非必要，否則應設定為唯讀（Read-Only）。
限制核心功能 禁用不必要的非特權使用者命名空間（unprivileged user namespaces），並限制核心模組的自動載入（autoloading of modules），減少攻擊面。
強化守護進程隔離 運行 coworkd 等管理進程時，應使用 ProtectSystem=strict 等設定，將其置於獨立的掛載命名空間中，防止被 VM 內被污染的二進位檔案反向攻擊。
總結來說，當我們在設計 AI Agent 的執行環境時，不能過度信任虛擬機的隔離能力。真正的安全應該建立在最小權限原則（Principle of Least Privilege）上，確保即使沙箱內部被攻破，攻擊者在主機上也找不到任何可利用的路徑。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。