Isolated and Exhausted: Attacking Operating Systems via Site Isolation in the Browser 論文解析

Site Isolation

Site 定義: 協定（Protocol）+ 主要網域（Main Domain，即 eTLD+1）。

舉例來說，https://a.com:4444 和 https://b.a.com 是不同的 Origin，但在 Site Isolation 的邏輯下，它們被視為同一個 Site（主網域都是 a.com），在正常情況下，瀏覽器會為了節省資源，把這兩個網頁放在同一個 OS 行程中處理 。

雖然在同一個行程，但瀏覽器的 JavaScript 引擎（如 V8）依然會執行「同源政策（SOP）」的檢查 。這意味著雖然 a.com:4444 的資料跟 <b.a.com> 存在同一個記憶體空間，但 JavaScript 層級依然無法直接跨過 Port 邊界去讀取對方的資料。

比較特別的是，如果對 IP 瀏覽器會把每個 IP 當作一個 Site，因為瀏覽器之所以能把 <a.example.com> 和 <b.example.com> 合併為同一個 Site，是因為它參考了一張全世界公認的清單：公共後綴清單 (Public Suffix List, PSL)。

• 網域邏輯：瀏覽器查表後知道 <.com> 是公共的，所以往左推一格 <example.com> 就是註冊者擁有的「主網域」 。既然是同一個主人，放在同一個進程裡是安全的
• IP 邏輯：IP 位址沒有 PSL 這種清單。對於瀏覽器來說，<1.2.3.4> 和 <1.2.3.5> 在沒有額外資訊的情況下，它無法判斷這兩者是屬於同一個單位，還是兩個完全不相關的租戶

2009 年瀏覽器就已經有 Process-per-site 的概念，每個頁面有自己的 Process。更進階概念是在 2019 年，因為一個網頁可能裡面有很多網站的內容，最常見像是 iframe 可能就是放不同網站，他們把一個 Page 裡面，針對每個 iframe 分成更多 Process。

此篇論文就是上面維基百科提到 2023 的研究。

Site Isolation 比較難管理是因為，在原本 Tab Isolation 是以每個分頁（可視元件）分離，所以每次開啟一個新視窗，都是要使用者自己點擊（）可以看到的事件）。

但 Site Isolation 是在一個分頁裡面自動有不幾個 Site 內容，他就自動創建不同的 Process，是自動的而不是可視化的。

先前的攻擊

會分成有打 Sandobx 機制跟不打打硬體的方式

打硬體

因為邏輯隔離不等於物理安全：即使你在邏輯上完美阻斷了行程 A 存取行程 B 的檔案，但如果 A 和 B 共享同一個 CPU 核心或記憶體通道，A 仍可能透過側信道（如監控 CPU 負載波動）來獲取 B 的執行特徵。*

• Rowhammer.js：這類攻擊利用了 DDR 記憶體電路過於密集導致的電磁干擾 。透過 JavaScript 快速且反覆地存取特定的記憶體列（Hammering），會導致鄰近列的資料位元（Bits）發生翻轉（Flip）
• 利用行為特徵監聽（側信道攻擊

打沙盒機制

• 沙盒突破 (Sandbox Escape)：最常見的手段是透過 JIT spraying（利用即時編譯器的特性在記憶體植入惡意指令）或 Fuzzing（自動化測試漏洞）

• Spectre 漏洞： 即使不突破沙盒，攻擊者也可以在 JavaScript 中實作 Spectre 攻擊來竊取沙盒內的私密資料

  這算是在 Site Isolation 還沒出來的時候，因為那時一個 Tab 會有很多網站，全部擠在同一個 Process，所以才引入 Site Isolation

• DNS Poisoning: 攻擊者在正確的回應到達之前，瘋狂發送偽造的回應封包，嘗試破解 DNS based on UDP 的 TXID，一旦猜中，假的 IP 就會被存入快取，受害者就會被導向惡意網站

論文

OS 受害資源

OS 有哪些資源可以打呢，以瀏覽器的角度，像是

1. Proess：這篇論文就是讓 Process 塞爆 OS
2. Network Socket：這篇論文就是把 Port 佔滿
   1. 作業系統將 65536 個連接埠分為三類用途：
   2. 系統連接埠（System Ports, 0-1023）：保留給知名服務使用，例如 DNS 使用的 53 號連接埠
   3. 使用者連接埠（User Ports, 1024-49151）：供自定義應用程式靜態分配
   4. 短暫連接埠（Ephemeral Ports, 49152-65535）：供客戶端（如瀏覽器）進行單次查詢或連線時由 OS 自動隨機挑選
3. DNS Cache：這篇論文就是延續第二步，先把 Port 塞滿，這樣比較好猜 DNS query 的 source port，可以達到 DNS Poisoning

攻擊 Fork Bomb

如同先前講，原本分頁不會產生 Bomb 的原因是因為，開啟新視窗必須經過「受信任事件（Trusted Event）」（例如使用者親自點擊滑鼠），所以可以知道分頁高機率是安全的。

在 Site Isolation 下，分頁與進程的 1:1 關係消失了 。現在一個分頁在載入過程中，不需要使用者點擊，就可以自動觸發開啟多個進程（為了隔離不同網站的 iframe）。

所以基本上就是弄一個網站，裡面放一堆 iframe 並且指向不同的 IP_1, IP_2 … IP_10000，我們還需要一個伺服器來當作後面這 10000 個 IP 的伺服器，可以直接用 IPv6 with IP_FREEBIND 來快速架設這種有很多 IP 的伺服器。

UDP Port 耗盡

能開啟 UDP Sokcet 只有 QUIC or WebRTC API，他們使用 WebRTC API 開啟 UDP socket 並 Listen 來佔用 Port。

又因為一個 Process 能開啟的 Socket 數量有限制，所以可以結合 Site Isolation 產生一堆 Process。

最後又因為瀏覽器會盡量把多個 Socket 共用 (Multiplexing)，所以論文要讓不同 WebRTC UDP socket 有不同的連線描述協定（SDP）。

• 移除 BUNDLE 選項：強制停用多路復用功能
• 複製資料通道：在 SDP 中手動增加多組具有獨立 ID 的資料通道描述

最終目標將作業系統所有可用的「短暫通訊埠（Ephemeral Ports）」全部填滿，達成全域性的資源耗盡。

最後他們在測試可以看到：

• Chrome 與 Edge 的單一進程限制：
  • 在單一渲染進程中，最多只允許同時建立 500 個 WebRTC 物件
  • 正常情況：每個物件佔用 2 個 Port，因此一個分頁最多佔用 1000 個 Port
  • 篡改 (Munging) 後：透過修改 SDP，攻擊者能繞過限制，讓單一進程佔用高達 3000 個 Port
• 結合 Site Isolation 的效果：
  • Windows 系統：成功完全耗盡（$\approx 100%$）作業系統的 UDP 短暫通訊埠範圍 。這意味著系統此時無法再進行任何新的 UDP 通訊（例如 DNS 查詢）
  • Linux 系統：雖然能分配到約 8000 個 Port（遠超原本 3000 個的限制），但隨後瀏覽器會進入失效狀態，無法再分配更多資源
  • Firefox 的表現：
    • 驗證機制：Firefox 會驗證被篡改過的 SDP，因此無法使用 WebRTC 手法
    • 全域限制：Firefox 設有全域限制，無論是否開啟 Site Isolation，整個瀏覽器最多只能分配 1000 個 UDP Port
    • 結果：在 Firefox 上無法達成 OS 層級的通訊埠耗盡

論文有在附錄提到更詳細怎麼修改 SDP 字串的。

DNS Poisoning

透過佔用幾乎所有客戶端 UDP 通訊埠（僅留下兩個），來瓦解作業系統的「UDP 通訊埠隨機化（SPR）」防禦機制，並將開放的通訊埠資訊告知遠端的攻擊者（Poisoner）

DEMONS 攻擊需要以下三個組件協作：

• 網頁伺服器（Web Server）：託管含有惡意 JavaScript 代碼的網頁，引誘受害者訪問
• 毒化者（Poisoner）：接收來自受害者瀏覽器的訊號，向受害者發送大量偽造的 DNS 回應封包
• 惡意伺服器（Malicious Server）：當攻擊成功後，受害者的 DNS 請求會指向此伺服器的 IP，使其能冒充合法的目標伺服器

該攻擊的實施存在一些前提條件：

• IP 偽冒（IP Spoofing）：攻擊者必須能夠偽造來源 IP 位址，以冒充受害者的預設 DNS 伺服器
• 網路環境影響：攻擊的成功率取決於毒化者與受害者 DNS 伺服器的相對位置
  • 如果受害者使用公共 DNS（如 8.8.8.8）或與攻擊者在同一區域網路，攻擊較易成功
  • 如果受害者使用家用路由器的私有 IP 作為 DNS，攻擊難度較高，除非使用者手動更改了設定

他讓瀏覽器只剩下兩個 Port 的方法為，先建立一個特定的 WebRTC 物件，透過 JavaScript API（如 localDescription），攻擊者可以事先讀出這個 RTC 所佔用的 UDP 通訊埠號碼，之後佔滿所有 Port，最後在釋放他這樣。

然後在猜測 TXID 的時候，就是讓惡意網頁一直使用 XMLHttpRequest 查詢 DNS，惡意伺服器會一直送 DNS 回應。

當作業系統收到一個 TXID 不對的偽造包時，Windows 的解析器會立即觸發 「查詢重傳 (Retransmission)」。這對攻擊者來說反而有利：每一次重傳都是一次新的機會，讓原本還在路上、或是剛抵達的偽造包去對上新的查詢。

以前要猜 TXID + Port 總共 2^16 x 2^16 總共 42 億種可能，現在只需要猜 TXID (2^16) x 2 個 Port 大概是十三萬種可能。

Evaluaiton

DEMONS 表現：在 133 次實驗中，成功 48 次（36%），失敗 85 次。

對比惡意軟體模型：作者也實作了基於惡意軟體（Malware，使用 Python）的攻擊作為對照。結果顯示，惡意軟體模型的成功率為 57%。

作者對網頁版攻擊（DEMONS）與惡意軟體版攻擊進行了深入對比 ：

• 速度差異：惡意軟體的「設定階段」比 DEMONS 快很多，因為 WebRTC 在瀏覽器中建立物件的速度相對緩慢 。
• 成功率差距：DEMONS 的成功率比惡意軟體低了約 21% 。
• 效能抖動：這主要是因為 JavaScript 的執行時機存在抖動（Jitter），且瀏覽器本身的其他網路活動會對精準的攻擊時機產生干擾

雖然 DEMONS 的成功率（37%）略低於需要作業系統特權的惡意軟體（57%），但它證明的威脅更大——因為攻擊者只需要讓你點開一個網頁就能達成接近惡意軟體的效果。

防禦

1. 瀏覽器不應該只限制「每個進程」的連線數，而應該限制「每個分頁 (Per-tab)」或「每個頂層網站」的總連線數。即便 Site Isolation 開了再多進程，這些進程加起來能佔用的 UDP Port 必須有個總上限。
2. 效法 Firefox，對 WebRTC 的 SDP 字串進行嚴格檢查。如果發現惡意的「Munging（竄改）」行為（例如重複的 mid 或過多的媒體通道），就直接拒絕連線。
3. UDP Port 隨機化的演進：分段隔離 (Port Partitioning)：為不同的使用者或進程分配獨立的 Ephemeral Port 範圍，防止單一應用程式榨乾全系統的 Port 池。
4. DNSSEC：作者強調，如果全面採用 DNSSEC（具備數位簽章的 DNS），那麼即便攻擊者猜中了 TXID 和 Port，也無法偽造正確的簽章，攻擊會直接失效。