Jump to...
redirecting...

Log for Ubuntu 台灣社群

Januscape:KVM/x86 中的客體到主機逃逸漏洞 [CVE-2026-53359] (★ 114 分)

Januscape(CVE-2026-53359)是 Hyunwoo Kim(@v4bel)揭露的 KVM/x86 客體到主機逃逸漏洞。KVM(Kernel-based Virtual Machine,Linux 核心內建虛擬化技術)在 x86 的 shadow MMU(影子記憶體管理單元)模擬中存在 use-after-free(釋放後使用)問題,攻擊者可只靠客體 VM 端操作破壞主機核心的 shadow page,進而突破 VM 與主機之間的隔離。作者稱,這是公開研究中首個可同時在 Intel 與 AMD 上觸發的 KVM 客體到主機逃逸研究,並已在 Google kvmCTF 中作為 0-day(尚未公開修補的漏洞)成功利用。

這項漏洞主要威脅啟用 nested virtualization(巢狀虛擬化)的 x86 KVM 多租戶環境,特別是同一實體主機承載多個客戶 VM 的公有雲情境,例如 GCP(Google Cloud Platform)與 AWS(Amazon Web Services)。攻擊者若在租用的 VM 內具備 root 權限,可能使主機核心 panic,造成 DoS(Denial of Service,阻斷服務),也可能在受控環境中做到 RCE(Remote Code Execution,遠端程式碼執行;此處指在主機上執行攻擊者程式碼)並取得主機 root,進一步影響同機其他 VM。公開的 PoC(proof of concept,概念驗證)目前只用於觸發主機當機;作者表示完整逃逸 exploit 存在但暫不公開。

受影響範圍橫跨 2010 年 8 月導入問題的 Linux 核心提交到 2026 年 6 月修補提交 81ccda30b4e8 之前,代表漏洞潛伏約 16 年。作者建議營運 x86 KVM 主機、允許不受信任 VM 且啟用巢狀虛擬化的單位,確認主機核心已套用修補。Januscape 不影響 arm64 KVM 主機,且漏洞不在 QEMU(常見的虛擬機器模擬與管理程式)本身,而是在核心內的 KVM,因此即使大型雲端業者使用自有虛擬化堆疊,只要底層依賴相關 KVM 機制仍可能受影響。另在部分發行版如 RHEL(Red Hat Enterprise Linux)中,若 /dev/kvm 權限為 0666,未具特權的本機使用者也可能把漏洞轉為 LPE(Local Privilege Escalation,本機權限提升)。

Hacker News 討論補充了幾個實務重點。KVM 維護者 bonzini 確認此漏洞需要啟用巢狀虛擬化才可利用,主機端可用 kvm_intel.nested=0 或 kvm_amd.nested=0 關閉;也有留言指出巢狀虛擬化會促使使用 shadow paging,而漏洞正位於該路徑。bonzini 也表示這是 2026 年 4 月透過 fuzzing(模糊測試)發現的 CVE-2026-46113 變體,因此「16 年未被發現」更精確地說是未被公開揭露。討論中另有不少人關注 /dev/kvm 是否應讓一般使用者存取:一方認為若禁止會導致大家改用 sudo 執行虛擬化工具,反而擴大風險;另一方則指出 Linux 權限常以使用者為單位,難以細緻限制個別應用程式。整體共識偏向:公開 VM 代管環境若不必要,應避免開啟巢狀虛擬化,並儘速更新核心。

👥 38 則討論、評論 💬
https://news.ycombinator.com/item?id=48807908
軟可透過 Windows 全域裝置識別碼 (GDID) 追蹤使用者 (★ 100 分)

PCMag 報導指出,19 歲的 Peter Stokes 因涉嫌參與 Scattered Spider(知名網路犯罪組織)攻擊而遭美國引渡與起訴,案件意外揭露 Microsoft 能用 Windows 的 GDID(Global Device ID,全域裝置識別碼)把一台 Windows PC 與其網路活動連在一起。FBI(美國聯邦調查局)在刑事訴狀中表示,Stokes 涉嫌於 2025 年 5 月使用 VPN(虛擬私人網路)攻擊一家高級珠寶零售商,而 Microsoft 紀錄協助調查人員把他的 IP 位址對應到特定 GDID。

訴狀引用 Microsoft 代表說法,GDID 是 Windows 生態系中的持久性、裝置層級識別碼,用來在部分 Microsoft 服務與情境中辨識某個實體裝置或虛擬機器上的 Windows 安裝。文件顯示,調查人員不只看到識別碼與 IP 的關聯,還取得該 GDID 在特定時間造訪第三方服務的紀錄,例如 2025 年 5 月 12 日造訪 ngrok(常用於把本機服務公開到網際網路的開發工具)註冊頁面,以及透過 Tzulo 代管伺服器相關網站進行活動。這讓外界擔心,Microsoft 可能在不依賴第三方瀏覽器 cookie 的情況下,仍能把 Windows 裝置與部分網路行為串連起來。

文章指出,GDID 似乎沒有簡單的停用方式;它會在 Windows 更新後維持不變,但重新安裝 Windows 會產生新的 GDID。即使如此,PCMag 認為 Microsoft 仍可能藉由 Microsoft 帳號登入、IP 位址或其他識別資料,把新舊 GDID 串起來。資安專家 Matthew Hickey 因此批評 Windows 具有監控軟體特徵;研究員 Costin Raiu 則提醒,類似能力未必只有 Microsoft 才有,Apple 等平台也可能有裝置或硬體層級識別機制,若追求更高匿名性,可能需要改用 Linux、FreeBSD,並搭配代理伺服器、Tor(洋蔥路由匿名網路)或 VPN 等工具。

Hacker News 討論多半聚焦在 Microsoft 究竟如何收集這些紀錄。有人推測 Windows 遙測、Defender、MAPS(Microsoft Active Protection Service,前身名為 SpyNet)或 Edge 可能把安裝識別碼、目前 IP 與近期 DNS 或 URL 活動送回 Microsoft;也有人建議用 Wireshark 抓封包、搭配 MITM(中間人)SSL 測試來確認內容,但其他人認為 Microsoft 可能使用憑證釘選或額外加密,讓攔截分析更困難。也有留言指出,文章顯示的不是只有網域,而是完整 URL,這讓問題更敏感。

討論中也有較保守的觀點,認為文章尚未證明 Microsoft 能看見 Chrome 或 Firefox 中所有瀏覽頁面,尤其 Edge 本身有「傳送診斷資料」與「儲存瀏覽活動」等可調整設定,實際範圍仍需釐清。另一些人把問題放到更大的平台識別脈絡:Linux 的 systemd 與 dbus 也有 machine-id,Chrome 等程式可能讀取;反作弊系統也常用 TPM(Trusted Platform Module,可信賴平台模組)或 Secure Boot 做硬體指紋辨識。整體來看,這起案件一方面展現裝置識別碼可協助追查網路犯罪,另一方面也凸顯作業系統供應商在透明度、使用者同意、資料保存與可退出機制上的隱私爭議。

👥 39 則討論、評論 💬
https://news.ycombinator.com/item?id=48815196
Oh, Snap! 😂
感謝,最後讓 opencode 去搞定了
恭喜搞定🎉
[photo](media:AgACAgUAAx0CPRn5XQABAlVeak4chIroa9JTckNzq1dtJBuWZdMAAjUPaxsnz3BWrwVV4rPGY0kBAAMCAANzAAM8BA@telegram)