接上篇《深度剖析站點(diǎn)隔離機(jī)制，Part 1》

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

什么是被入侵的渲染器進(jìn)程?

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

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

一個(gè)可以實(shí)現(xiàn)UXSS的站點(diǎn)隔離繞過(guò)漏洞

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

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

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

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

在創(chuàng)建Blob URL時(shí)，通過(guò)在瀏覽器進(jìn)程中對(duì)源進(jìn)行相應(yīng)的驗(yàn)證，就能修復(fù)這個(gè)問(wèn)題。

偽造IPC消息

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

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

postMessage中安全漏洞

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

為了修復(fù)這個(gè)漏洞，只要通過(guò)在瀏覽器進(jìn)程中對(duì)postMessage IPC的源進(jìn)行相應(yīng)的驗(yàn)證即可。

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

遺憾的是，我通過(guò)spoof.js只在postMessage中找到了一個(gè)漏洞。之后，我開始思考是否能夠通過(guò)其他地方中的漏洞來(lái)繞過(guò)站點(diǎn)隔離，以確定代碼審查與測(cè)試的目標(biāo)。所以，我決定研究一下導(dǎo)航機(jī)制。

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

在測(cè)試導(dǎo)航的處理過(guò)程時(shí)，我注意到，如果源是一個(gè)不透明的源(opaque origin)，我就可以佯稱導(dǎo)航已經(jīng)提交至渲染器進(jìn)程的任何URL。之所以存在這個(gè)漏洞，是因?yàn)槿魏蜺RL都可以是一個(gè)不透明的源(使用iframe/CSP沙箱)，所以對(duì)常規(guī)的的源與URL進(jìn)行檢查是沒(méi)有任何意義的。目前，這個(gè)檢查已經(jīng)得到了加強(qiáng)，以確保地址欄欺騙無(wú)法實(shí)施。

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

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

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

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

有了這些繞過(guò)技術(shù)，攻擊者就可以通過(guò)以下步驟繞過(guò)站點(diǎn)隔離機(jī)制：

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

通過(guò)在瀏覽器進(jìn)程中加入適當(dāng)?shù)臋z查，就能修復(fù)這個(gè)漏洞。 

Reader模式下的安全漏洞

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

(未完待續(xù))

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