在 中,我们为读者解释了站点隔离以及相关安全机制是如何缓解诸如 UXSS 和 Spectre 之类的黑客攻击的。然而,由于渲染器进程中的安全漏洞极为常见,因此,Chromium 的威胁模型假设渲染器进程可能会遭到入侵,也就是该进程是不可信任的。为了与这种威胁…

深度剖析站点隔离机制,Part 2 (上)-区块链315嘶吼专业版区块链作者,团队,专栏,公众号,头条· 2021年1月13日 12:06 ·阅读约 7 分钟

深度剖析站点隔离机制,Part 2 (上)-区块链315

在 中,我们为读者解释了站点隔离以及相关安全机制是如何缓解诸如 UXSS 和 Spectre 之类的黑客攻击的。然而,由于渲染器进程中的安全漏洞极为常见,因此,Chromium 的威胁模型假设渲染器进程可能会遭到入侵,也就是该进程是不可信任的。为了与这种威胁模型保持一致,Chromium 在 2019 年宣布了对站点隔离机制进行相应的改进,以进一步缓解被入侵的渲染器进程可能造成的危害。在这篇文章中,我们将为读者解释这些改进的细节,以及在此过程中发现的各种安全漏洞。

深度剖析站点隔离机制,Part 2 (上)-区块链315

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

攻击者可能会在 Chromium 的渲染器进程中发现安全漏洞,例如在 JavaScript 引擎、DOM 或图像解析逻辑中,这并不稀奇。有时,这些漏洞可能涉及内存错误(例如,UAF 漏洞),导致攻击者的网页在渲染过程中能够执行他们自己的、任意的、本地的代码(例如汇编 /C++代码,而不是 JavaScript 代码)。我们称这样的进程为“被入侵的渲染器”——作者:kasz Anforowicz

这意味着,被入侵的渲染器进程不仅可以读取渲染器进程中的所有内存空间,还可以对其进行写入操作。比如说,允许攻击者伪造渲染器进程的 IPC 消息给其他进程。这里列出了站点隔离的改进之处。

深度剖析站点隔离机制,Part 2 (上)-区块链315一个可以实现 UXSS 的站点隔离绕过漏洞

在寻找绕过站点隔离的方法时,我想起了 Bo0oM 发现的一个非常有趣的 UXSS 漏洞。在当时,站点隔离还只是一个实验性的功能,而且出于禁用状态,我想知道是否可以用这个漏洞来绕过站点隔离措施。

于是,我在启用站点隔离机制的情况下对 UXSS 漏洞进行了测试,发现它在某些方面仍然奏效。当源发生变化后,之前网站的流程仍会被重用。例如,如果试图访问 cookie,会导致渲染器进程崩溃,因为站点隔离机制认为该进程不应该为另一个源请求 cookie。

深度剖析站点隔离机制,Part 2 (上)-区块链315

这简直就是一个完美的漏洞,完全可以用来绕过站点隔离,因为这个行为类似于一个被入侵的渲染器:我们可以覆盖渲染器进程中的源信息;当然,我们无法藉此绕过进程隔离安全机制。通过这个漏洞,我们可以测试哪个 API 不会在意伪造的源,并允许我们访问其他源的信息。所以,在进行测试的同时,我也把这个有趣的行为告诉了 Masato。很快,他就发现了一个漏洞。原来,我们可以创建一个带有伪造源的 Blob URL,并且,只要导航到这个 Blob URL,就可以访问目标网站的 cookie。

深度剖析站点隔离机制,Part 2 (上)-区块链315

虽然我们挖到了上述漏洞,但我们必须确保这个漏洞仍然存在于稳定版中,因为 UXSS 的漏洞早已经被修复了。为此,我们进行验证并发现,只要在发送 IPC 创建 Blob URL 之前通过 WinDbg 修改源,就能在稳定版上触发这个漏洞。

在创建 Blob URL 时,通过在浏览器进程中对源进行相应的验证,就能修复这个问题。

深度剖析站点隔离机制,Part 2 (上)-区块链315伪造 IPC 消息

我们可以从上一个漏洞中可以清楚地看到,通过被入侵的渲染器测试站点隔离改进情况的最简单的方法,就是在渲染器进程发送源或 URL 信息的地方伪造 IPC 消息。但是,通过阅读代码来寻找这样的地方,并使用 Mojo JS 来发送伪造的 IPC 消息,似乎是一项浩大的工程。

于是,我为 WinDbg 创建了一个名为 spoof.js 的 JavaScript 调试器扩展。因为 spoof.js 能够修改渲染器内存中的源和 URL,所以,我只需要进行正常的 Web API 调用,就能完成 IPC 的测试工作。这样做还有一个意想不到的好处,就是还可以伪造传统的 IPC 消息,而非 Mojo 实现的 IPC 消息(如果我选择用 Mojo JS 进行测试,就不可能做到这一点)。

postMessage 中安全漏洞

在使用 spoof.js 进行测试的过程中,我意外发现不仅可以将 postMessage 发送到一个跨站点的窗口 /frame 中,还可以通过伪造源来接收来自不同的目标源的消息。

深度剖析站点隔离机制,Part 2 (上)-区块链315

为了修复这个漏洞,只要通过在浏览器进程中对 postMessage IPC 的源进行相应的验证即可。

深度剖析站点隔离机制,Part 2 (上)-区块链315利用被入侵的渲染器欺骗地址栏

遗憾的是,我通过 spoof.js 只在 postMessage 中找到了一个漏洞。之后,我开始思考是否能够通过其他地方中的漏洞来绕过站点隔离,以确定代码审查与测试的目标。所以,我决定研究一下导航机制。

如果您稍微研究一下 Chromium 的导航机制,就会发现一个有趣的步骤:渲染器进程在提交导航时会向浏览器进程发送一个 IPC 消息。这个 IPC 消息非常耐人寻味,因为渲染器进程可以在导航启动后(即网络进程已经开始下载响应后),知道渲染器进程会将导航提交至哪个源和 URL。如果浏览器进程的验证机制不够严谨,就容易出现安全漏洞。

在测试导航的处理过程时,我注意到,如果源是一个不透明的源(opaque origin),我就可以佯称导航已经提交至渲染器进程的任何 URL。之所以存在这个漏洞,是因为任何 URL 都可以是一个不透明的源(使用 iframe/CSP 沙箱),所以对常规的的源与 URL 进行检查是没有任何意义的。目前,这个检查已经得到了加强,以确保地址栏欺骗无法实施。

深度剖析站点隔离机制,Part 2 (上)-区块链315滥用协议处理程序

我的另一个想法是,如果我可以使用 registerProtocolHandler API 来导航任何协议到一些“坏”的 URL (例如 Data URL),结果会如何?所以,我检查了它们的实现代码,发现下面的限制是可以绕过 / 欺骗的:

·协议 /scheme 必须位于 allow-list 中:

  • 这个检查是在渲染器进程中进行的,而浏览器进程只实现了与浏览器处理的协议(例如 http:, https: 等)相关的 deny-list 检查。

·目标 URL 必须与注册窗口同源。

  • 这个检查也是在渲染器进程里面进行的,因此可以绕过。

·用户必须接受权限提示。

  • 权限提示中显示的源是用目的 URL 计算出来的,而目的 URL 可以用前面提到的方法进行伪造。

  • 跨源的 iframe 可以调用 registerProtocolHandler API。

  • 如果传递 Data URL,权限提示中不会显示源信息。

深度剖析站点隔离机制,Part 2 (上)-区块链315

有了这些绕过技术,攻击者就可以通过以下步骤绕过站点隔离机制:

请求一个协议处理程序的权限,将以下 Data URL 作为目标 URL:

data:text/html, 点击劫持一个带有自定义协议链接的受害者页面(如 tel:、mailto: 等)。

点击该链接会导航到上面的 Data URL,该 URL 会在受害者的渲染器进程中执行。

通过在浏览器进程中加入适当的检查,就能修复这个漏洞。

深度剖析站点隔离机制,Part 2 (上)-区块链315

深度剖析站点隔离机制,Part 2 (上)-区块链315Reader 模式下的安全漏洞

当 Edge 开始提供阅读视图时,我们决定考察一下 DOM Distiller,其作用是为 Chrome 中的 Reader 模式提供支持。我很好奇 DOM Distiller 是如何实现的,所以,开始着手对其进行了相应的安全测试。

Reader 模式在渲染前会对网站的 HTML 内容进行过滤处理,以获得良好的阅读体验。虽然它们试图删除大部分危险的标签(如 script、style 等),但许多事件处理程序并没有进行适当地过滤(如 < button onclick="alert(1)" >)。而网站的图片和视频则按照相应的设计来进行显示。

这本质上意味着 , 如果攻击者能够利用图像或视频解析中的内存破坏漏洞,或者能够绕过 CSP,攻击者就能够入侵 Reader 模式进程或在 Reader 模式下执行脚本。

Reader 模式的呈现方式为 chrome-distiller:scheme,其中主机名为 GUID,url 参数指向要处理的页面,例如:

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

而且,由于可以重用 GUID 来呈现其他跨站点页面,因此,攻击者可以通过以下步骤利用 Reader 模式:

打开新的窗口进入受害者的网站(Reader 模式会缓存页面)。

使用相同的 GUID 将受害者窗口导航到 Reader 模式。

这时,攻击者的窗口和受害者的窗口将处于在同一个过程中,使其可以窃取机密信息。

深度剖析站点隔离机制,Part 2 (上)-区块链315

通过在主机名中加入 url 参数的哈希值以及改进过滤措施,就可以修复这个漏洞。

由此可以看出,Reader 模式的设计非常脆弱,因为同一个进程可以处理来自不同站点的敏感数据,并且这个进程很容易被攻击者所入侵。如果借鉴一下“The Rule of 2”的创意,那么站点隔离的“The Rule of 2”就是:

深度剖析站点隔离机制,Part 2 (上)-区块链315

其他研究人员发现的站点隔离绕过方法

实际上,其他研究人员已经发现了许多很好的站点隔离绕过方法。

深度剖析站点隔离机制,Part 2 (上)-区块链315小结

在上一篇文章中,我们为读者解释了站点隔离以及相关安全机制是如何缓解诸如 UXSS 和 Spectre 之类的黑客攻击的。然而,由于渲染器进程中的安全漏洞非常常见,因此,Chromium 的威胁模型假设渲染器进程可能会遭到入侵,也就是该进程是不可信任的。为了与这种威胁模型保持一致,Chromium 在 2019 年宣布了对站点隔离机制进行相应的改进,以进一步缓解被入侵的渲染器进程可能造成的危害。在这篇文章中,我们将为读者解释这些改进的细节,以及在此过程中发现的各种安全漏洞。由于本文篇幅较长,所以分为两部分发表,更多精彩内容,我们将在下篇中加以介绍。

参考及来源:https://microsoftedge.github.io/edgevr/posts/deep-pe-into-site-isolation-part-2/

深度剖析站点隔离机制,Part 2 (上)-区块链315
深度剖析站点隔离机制,Part 2 (上)-区块链315

免责声明:作为区块链信息平台,本站所发布文章仅代表作者个人观点,与链闻 ChainNews 立场无关。文章内的信息、意见等均仅供参考,并非作为或被视为实际投资建议。