# Isolated and Exhausted: Attacking Operating Systems via Site Isolation in the Browser 論文解析 ## Site Isolation Site 定義: 協定（Protocol）+ 主要網域（Main Domain，即 eTLD+1）。 舉例來說， 和 是不同的 Origin，但在 Site Isolation 的邏輯下，它們被視為同一個 Site（主網域都是 a.com），在正常情況下，瀏覽器會為了節省資源，把這兩個網頁放在同一個 OS 行程中處理 。 雖然在同一個行程，但瀏覽器的 JavaScript 引擎（如 V8）依然會執行「同源政策（SOP）」的檢查 。這意味著雖然 的資料跟 存在同一個記憶體空間，但 JavaScript 層級依然無法直接跨過 Port 邊界去讀取對方的資料。 比較特別的是，如果對 IP 瀏覽器會把每個 IP 當作一個 Site，因為瀏覽器之所以能把 和 合併為同一個 Site，是因為它參考了一張全世界公認的清單：公共後綴清單 (Public Suffix List, PSL)。 - 網域邏輯：瀏覽器查表後知道 <.com> 是公共的，所以往左推一格 就是註冊者擁有的「主網域」 。既然是同一個主人，放在同一個進程裡是安全的 - IP 邏輯：IP 位址沒有 PSL 這種清單。對於瀏覽器來說，<1.2.3.4> 和 <1.2.3.5> 在沒有額外資訊的情況下，它無法判斷這兩者是屬於同一個單位，還是兩個完全不相關的租戶 2009 年瀏覽器就已經有 Process-per-site 的概念，每個頁面有自己的 Process。更進階概念是在 2019 年，因為一個網頁可能裡面有很多網站的內容，最常見像是 iframe 可能就是放不同網站，他們把一個 Page 裡面，針對每個 iframe 分成更多 Process。 {{< image src="image.png" alt="[維基百科](https://zh.wikipedia.org/zh-tw/%E7%AB%99%E7%82%B9%E9%9A%94%E7%A6%BB#CITEREFGierlingsBrinkmannSchwenk2023)" caption="[維基百科](https://zh.wikipedia.org/zh-tw/%E7%AB%99%E7%82%B9%E9%9A%94%E7%A6%BB#CITEREFGierlingsBrinkmannSchwenk2023)" >}} 此篇論文就是上面維基百科提到 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，也無法偽造正確的簽章，攻擊會直接失效。