Qubes OS 修補 QSB-118 漏洞：dom0 透過剪貼簿反向通道可被植入任意指令

編按：本文綜合整理自 Qubes OS 官方安全公告 QSB-118、Hacker News 討論串，並加入 Siami 編輯部觀點與分析。

事件概要

Qubes OS 官方於 2026 年 8 月 28 日發布 QSB-118 安全公告，揭露一個存在於 qvm-copy-to-vm 工具的高風險漏洞——當使用者從 dom0（管理層）複製檔案到一個已被入侵的 qube（虛擬機器）時，攻擊者可藉由精心設計的「錯誤回報訊息」反向注入任意指令到 dom0，進而接管整個系統。

這份公告由 Qubes Security Team 公布，並由維護者 Marek Marczykowski-Górecki 與 Simon Gaiser 加上 PGP 數位簽章，使用者可透過 QMSK 驗證真偽。修補套件 qubes-core-dom0-linux 4.3.22 已進入 security-testing repository，正常更新即可取得。

漏洞怎麼運作的

整個攻擊鏈發生在「錯誤訊息顯示」這個看似無害的環節：

• qvm-copy-to-vm 使用自訂的「qfile」協定從 dom0 傳檔到目標 qube，傳輸完成後目標端會回傳包含 checksum、錯誤代碼、與最後接收到的檔名的確認訊息
• dom0 收到錯誤回報時，會把該檔名塞進錯誤對話框的命令字串中，用 system() 呼叫 kdialog 或 zenity 來顯示 GUI
• 雖然 sanitize_remote_filename() 函式會把非 ASCII 字元和雙引號換成底線，但保留了所有 shell meta 字元（反引號、$()、;、|、& 等）
• 因此當目標 qube 在錯誤代碼中夾帶一個精心打造的「檔名」（例如 `malicious_cmd`），dom0 的 system() 就會乖乖執行它

值得留意的是，VM 端的 qvm-copy-to-vm 不受影響——它的錯誤回報函式改用 fork() + execlp() 直接呼叫 zenity/kdialog，不經過 shell。這正是 dom0 端用 system() 拼接命令的設計缺陷所在。

// 漏洞根源：core-admin-linux/file-copy-vm/qfile-dom0-agent.c
asprintf(&dialog_cmd, "%s '%s: %s (error type: %s)'",
         ret==0 ? KDIALOG_CMD : ZENITY_CMD,
         program_invocation_short_name, buf, strerror(errno));
...
system(dialog_cmd);  // ← 攻擊者的檔名在這裡被 shell 解析

為什麼這件事重要

對於一般 Linux 桌面使用者，這個漏洞或許「看起來」遙遠，但對 Qubes OS 的目標族群——記者、吹哨人、異議人士、資安研究員——卻是真實的災難：

• Qubes 的核心承諾是「就算使用者的某個 qube 被攻陷，攻擊者也不能跨過隔離界線觸碰 dom0」。這次漏洞直接打穿這道防線，拿到 dom0 等於全系統淪陷。
• 漏洞觸發情境非常日常。Hacker News 網友 nickzana 點出：用 xfce4-screenshooter 截圖、把檔案存到 dom0、再用 qvm-copy-to-vm 丟到工作 qube，是 Qubes 最普遍的工作流之一。換句話說，不是邊緣操作才會中，是日常動作就可能中。
• 攻擊模型符合真實威脅。Qubes 用戶常見的威脅場景是「瀏覽不可信網站的 qube 被 XSS/瀏覽器 0-day 拿下」，這個漏洞讓那個被拿下的 qube 反過來感染 dom0，把隔離價值直接歸零。
• 公告透明且修補迅速。Qubes 團隊在公告中附上完整 PoC 程式碼片段、影響範圍、修補版本與 PGP 簽章，這種透明度本身就是開源安全圈的示範。

數據解讀與質疑

• CVE 編號未公開於公告中。公告內文僅標示 QSB 內部編號，未對應到 MITRE CVE 編號。這在 Qubes 過去的公告中並不罕見（他們偏好自家編號體系），但對企業資安團隊的漏洞管理系統整合會造成困難。
• Hacker News 討論呈現「Qubes 哲學辯論」。除了技術分析，留言區有相當比例圍繞「Theo DeRaadt 對 C 語言的批評」與「Qubes 是不是過度設計」展開。這反映出社群對 Qubes 安全模型的根本質疑：複雜度本身就是攻擊面。本次漏洞（shell meta 字元未過濾）正是這種複雜度的副產品。
• 修補時程。從漏洞揭露到 4.3.22 套件進入 security-testing repo 約 2 週，屬於合理節奏。Qubes 4.2 以前的版本雖然公告沒明確列出 EOL 對應，但所有 4.x 系列皆受影響，使用者應一併升級。
• VM 端變體不受影響是個重要細節——代表攻擊者必須先說服使用者在 dom0 端執行 qvm-copy-to-vm，或誘使已經運行的 dom0 程序觸發。雖然 HN 網友認為這降低了實際被利用的機率，但完全依賴使用者行為的防禦，在記者/異議人士場景下並不牢靠。

受影響範圍與修補方式

• 所有 Qubes OS 4.x 版本皆受影響
• 修補套件：qubes-core-dom0-linux 4.3.22（4.3 系列）
• 修補路徑：套件會先在 security-testing repo 經社群短期測試，再 migrate 到 stable。使用者可透過 Qubes Update 工具或命令列執行正常更新即可
• PGP 簽章驗證：Marek Marczykowski-Górecki 與 Simon Gaiser (HW42) 雙重簽署公告，使用者可從 keys.qubes-os.org 取得 QMSK 並驗證 fingerprint

漏洞發現者：Tim C.（公告中致謝）

延伸資源

• Qubes 官方安全公告 QSB-118（原文）
• Qubes 更新指南
• Qubes Security Team 頁面
• Hacker News 討論串（60 則回應）