接上篇《深度剖析站點隔離機制，Part 1》

在上一篇文章中，我們?yōu)樽x者解釋了站點隔離以及相關安全機制是如何緩解諸如UXSS和Spectre之類的黑客攻擊的。然而，由于渲染器進程中的安全漏洞極為常見，因此，Chromium的威脅模型假設渲染器進程可能會遭到入侵，也就是該進程是不可信任的。為了與這種威脅模型保持一致，Chromium在2019年宣布了對站點隔離機制進行相應的改進，以進一步緩解被入侵的渲染器進程可能造成的危害。在這篇文章中，我們將為讀者解釋這些改進的細節(jié)，以及在此過程中發(fā)現(xiàn)的各種安全漏洞。

什么是被入侵的渲染器進程?

攻擊者可能會在Chromium的渲染器進程中發(fā)現(xiàn)安全漏洞，例如在JavaScript引擎、DOM或圖像解析邏輯中，這并不稀奇。有時，這些漏洞可能涉及內(nèi)存錯誤(例如，UAF漏洞)，導致攻擊者的網(wǎng)頁在渲染過程中能夠執(zhí)行他們自己的、任意的、本地的代碼(例如匯編/C++代碼，而不是JavaScript代碼)。我們稱這樣的進程為“被入侵的渲染器”——作者：kasz Anforowicz

這意味著，被入侵的渲染器進程不僅可以讀取渲染器進程中的所有內(nèi)存空間，還可以對其進行寫入操作。比如說，允許攻擊者偽造渲染器進程的IPC消息給其他進程。這里列出了站點隔離的改進之處。

一個可以實現(xiàn)UXSS的站點隔離繞過漏洞

在尋找繞過站點隔離的方法時，我想起了Bo0oM發(fā)現(xiàn)的一個非常有趣的UXSS漏洞。在當時，站點隔離還只是一個實驗性的功能，而且出于禁用狀態(tài)，我想知道是否可以用這個漏洞來繞過站點隔離措施。

于是，我在啟用站點隔離機制的情況下對UXSS漏洞進行了測試，發(fā)現(xiàn)它在某些方面仍然奏效。當源發(fā)生變化后，之前網(wǎng)站的流程仍會被重用。例如，如果試圖訪問cookie，會導致渲染器進程崩潰，因為站點隔離機制認為該進程不應該為另一個源請求cookie。

這簡直就是一個完美的漏洞，完全可以用來繞過站點隔離，因為這個行為類似于一個被入侵的渲染器：我們可以覆蓋渲染器進程中的源信息;當然，我們無法藉此繞過進程隔離安全機制。通過這個漏洞，我們可以測試哪個API不會在意偽造的源，并允許我們訪問其他源的信息。所以，在進行測試的同時，我也把這個有趣的行為告訴了Masato。很快，他就發(fā)現(xiàn)了一個漏洞。原來，我們可以創(chuàng)建一個帶有偽造源的Blob URL，并且，只要導航到這個Blob URL，就可以訪問目標網(wǎng)站的cookie。

雖然我們挖到了上述漏洞，但我們必須確保這個漏洞仍然存在于穩(wěn)定版中，因為UXSS的漏洞早已經(jīng)被修復了。為此，我們進行驗證并發(fā)現(xiàn)，只要在發(fā)送IPC創(chuàng)建Blob URL之前通過WinDbg修改源，就能在穩(wěn)定版上觸發(fā)這個漏洞。

在創(chuàng)建Blob URL時，通過在瀏覽器進程中對源進行相應的驗證，就能修復這個問題。

偽造IPC消息

我們可以從上一個漏洞中可以清楚地看到，通過被入侵的渲染器測試站點隔離改進情況的最簡單的方法，就是在渲染器進程發(fā)送源或URL信息的地方偽造IPC消息。但是，通過閱讀代碼來尋找這樣的地方，并使用Mojo JS來發(fā)送偽造的IPC消息，似乎是一項浩大的工程。

于是，我為WinDbg創(chuàng)建了一個名為spoof.js的JavaScript調(diào)試器擴展。因為spoof.js能夠修改渲染器內(nèi)存中的源和URL，所以，我只需要進行正常的Web API調(diào)用，就能完成IPC的測試工作。這樣做還有一個意想不到的好處，就是還可以偽造傳統(tǒng)的IPC消息，而非Mojo實現(xiàn)的IPC消息(如果我選擇用Mojo JS進行測試，就不可能做到這一點)。

postMessage中安全漏洞

在使用spoof.js進行測試的過程中，我意外發(fā)現(xiàn)不僅可以將postMessage發(fā)送到一個跨站點的窗口/frame中，還可以通過偽造源來接收來自不同的目標源的消息。

為了修復這個漏洞，只要通過在瀏覽器進程中對postMessage IPC的源進行相應的驗證即可。

利用被入侵的渲染器欺騙地址欄

遺憾的是，我通過spoof.js只在postMessage中找到了一個漏洞。之后，我開始思考是否能夠通過其他地方中的漏洞來繞過站點隔離，以確定代碼審查與測試的目標。所以，我決定研究一下導航機制。

如果您稍微研究一下Chromium的導航機制，就會發(fā)現(xiàn)一個有趣的步驟：渲染器進程在提交導航時會向瀏覽器進程發(fā)送一個IPC消息。這個IPC消息非常耐人尋味，因為渲染器進程可以在導航啟動后(即網(wǎng)絡進程已經(jīng)開始下載響應后)，知道渲染器進程會將導航提交至哪個源和URL。如果瀏覽器進程的驗證機制不夠嚴謹，就容易出現(xiàn)安全漏洞。

在測試導航的處理過程時，我注意到，如果源是一個不透明的源(opaque origin)，我就可以佯稱導航已經(jīng)提交至渲染器進程的任何URL。之所以存在這個漏洞，是因為任何URL都可以是一個不透明的源(使用iframe/CSP沙箱)，所以對常規(guī)的的源與URL進行檢查是沒有任何意義的。目前，這個檢查已經(jīng)得到了加強，以確保地址欄欺騙無法實施。

濫用協(xié)議處理程序

我的另一個想法是，如果我可以使用registerProtocolHandler API來導航任何協(xié)議到一些“壞”的URL(例如Data URL)，結果會如何?所以，我檢查了它們的實現(xiàn)代碼，發(fā)現(xiàn)下面的限制是可以繞過/欺騙的：

協(xié)議/scheme必須位于allow-list中：

• 這個檢查是在渲染器進程中進行的，而瀏覽器進程只實現(xiàn)了與瀏覽器處理的協(xié)議(例如http:, https:等)相關的deny-list檢查。
• 目標URL必須與注冊窗口同源。
• 這個檢查也是在渲染器進程里面進行的，因此可以繞過。
• 用戶必須接受權限提示。
• 權限提示中顯示的源是用目的URL計算出來的，而目的URL可以用前面提到的方法進行偽造。
• 跨源的iframe可以調(diào)用registerProtocolHandler API。
• 如果傳遞Data URL，權限提示中不會顯示源信息。

有了這些繞過技術，攻擊者就可以通過以下步驟繞過站點隔離機制：

• 請求一個協(xié)議處理程序的權限，將以下Data URL作為目標URL：data:text/html,點擊劫持一個帶有自定義協(xié)議鏈接的受害者頁面(如tel:、mailto:等)。
• 點擊該鏈接會導航到上面的Data URL，該URL會在受害者的渲染器進程中執(zhí)行。

通過在瀏覽器進程中加入適當?shù)臋z查，就能修復這個漏洞。 

Reader模式下的安全漏洞

當Edge開始提供閱讀視圖時，我們決定考察一下DOM Distiller，其作用是為Chrome中的Reader模式提供支持。我很好奇DOM Distiller是如何實現(xiàn)的，所以，開始著手對其進行了相應的安全測試。

Reader模式在渲染前會對網(wǎng)站的HTML內(nèi)容進行過濾處理，以獲得良好的閱讀體驗。雖然它們試圖刪除大部分危險的標簽(如script、style等)，但許多事件處理程序并沒有進行適當?shù)剡^濾(如< button onclick="alert(1)" >)。而網(wǎng)站的圖片和視頻則按照相應的設計來進行顯示。

這本質(zhì)上意味著,如果攻擊者能夠利用圖像或視頻解析中的內(nèi)存破壞漏洞，或者能夠繞過CSP，攻擊者就能夠入侵Reader模式進程或在Reader模式下執(zhí)行腳本。

Reader模式的呈現(xiàn)方式為chrome-distiller:scheme，其中主機名為GUID，url參數(shù)指向要處理的頁面，例如：

chrome-distiller://9a898ff4-b0ad-45c6-8da2-bd8a6acce25d/?url=https://news.example 

而且，由于可以重用GUID來呈現(xiàn)其他跨站點頁面，因此，攻擊者可以通過以下步驟利用Reader模式：

• 打開新的窗口進入受害者的網(wǎng)站(Reader模式會緩存頁面)。
• 使用相同的GUID將受害者窗口導航到Reader模式。
• 這時，攻擊者的窗口和受害者的窗口將處于在同一個過程中，使其可以竊取機密信息。

通過在主機名中加入url參數(shù)的哈希值以及改進過濾措施，就可以修復這個漏洞。

由此可以看出，Reader模式的設計非常脆弱，因為同一個進程可以處理來自不同站點的敏感數(shù)據(jù)，并且這個進程很容易被攻擊者所入侵。如果借鑒一下“The Rule of 2”的創(chuàng)意，那么站點隔離的“The Rule of 2”就是：

其他研究人員發(fā)現(xiàn)的站點隔離繞過方法

實際上，其他研究人員已經(jīng)發(fā)現(xiàn)了許多很好的站點隔離繞過方法。

小結

在上一篇文章中，我們?yōu)樽x者解釋了站點隔離以及相關安全機制是如何緩解諸如UXSS和Spectre之類的黑客攻擊的。然而，由于渲染器進程中的安全漏洞非常常見，因此，Chromium的威脅模型假設渲染器進程可能會遭到入侵，也就是該進程是不可信任的。為了與這種威脅模型保持一致，Chromium在2019年宣布了對站點隔離機制進行相應的改進，以進一步緩解被入侵的渲染器進程可能造成的危害。在這篇文章中，我們將為讀者解釋這些改進的細節(jié)，以及在此過程中發(fā)現(xiàn)的各種安全漏洞。由于本文篇幅較長，所以分為兩部分發(fā)表，更多精彩內(nèi)容，我們將在下篇中加以介紹。

(未完待續(xù))

本文翻譯自：https://microsoftedge.github.io/edgevr/posts/deep-dive-into-site-isolation-part-2