0x01 分析背景
我的目标是使不熟悉Chrome浏览器开发的人可以看懂这个帖子，因此，我将从了解Chrome的安全架构和IPC设计开始。请注意，此部分的所有内容也适用于基于Chromium的Edge，默认情况下已于2020年1月15日发布。
Chrome 架构
Chrome安全体系结构的关键支柱是沙箱。Chrome将网络的大部分攻击面（例如DOM渲染，脚本执行，媒体解码等）限制为沙盒进程。有一个中央进程，称为浏览器进程，它不在沙盒中运行。这个图表，显示了每个进程中的攻击面以及它们之间的各种通信通道。
除了沙盒功能外，Chrome还实现了站点隔离，可确保来自不同来源的数据在不同的沙盒流程中进行存储和处理。这样做的结果是，破坏沙盒进程甚至不应允许攻击者泄漏用户浏览数据的其他来源。
这种架构的结果是，大多数Chrome漏洞利用程序都需要两个或多个漏洞：至少一个要在沙盒进程（通常是渲染器进程）中执行代码，而至少一个要逃逸沙盒。
我将要研究的漏洞允许受损的渲染器进程逃逸沙箱。
Mojo IPC
Chrome进程通过两种IPC机制相互通信：旧版IPC和Mojo。旧版IPC即将淘汰，支持Mojo，并且与该bug的讨论无关，因此我仅关注Mojo。
引用Mojo文档，Mojo是运行时库的集合，这些运行时库提供了与平台无关的通用IPC原语抽象，消息IDL格式以及具有用于多种目标语言的代码生成功能的绑定库，以方便跨任意进程间和进程内边界传递方便的消息。
漏洞代码的Mojo接口定义：
- // Represents a system application related to a particular web app.
- // See: https://www.w3.org/TR/appmanifest/#dfn-application-object
- struct RelatedApplication {
- string platform;
- // TODO(mgiuca): Change to url.mojom.Url (requires changing
- // WebRelatedApplication as well).
- string? url;
- string? id;
- string? version;
- };
- // Mojo service for the getInstalledRelatedApps implementation.
- // The browser process implements this service and receives calls from
- // renderers to resolve calls to navigator.getInstalledRelatedApps().
- interface InstalledAppProvider {
- // Filters |relatedApps|, keeping only those which are both installed on the
- // user's system, and related to the web origin of the requesting page.
- // Also appends the app version to the filtered apps.
- FilterInstalledApps(array related_apps, url.mojom.Url manifest_url)
- => (array installed_apps);
- };
在Chrome构建过程中，此接口定义将转换为每种目标语言（例如C ++，Java甚至JavaScript）的接口和代理对象。这个特定的接口最初仅在使用Java Mojo绑定的Android上实现，但是最近对Windows的支持在C ++中实现。我的利用将使用JavaScript绑定（在受损的渲染器进程中运行）调用此C ++实现（在浏览器进程中运行）。
此接口定义一种方法FilterInstalledApps。默认情况下，所有方法都是异步的（有一个[Sync]属性可以覆盖此默认值）。在生成的C ++接口中，这意味着该方法采用一个额外的参数，该参数是要使用结果调用的回调。在JavaScript中，该函数将返回一个Promise。
了解一些Mojo术语将有助于阅读本文后面的代码。请注意，Mojo最近更改了这些名称，但是尚未迁移所有代码和文档，因此我将在必要时提供两个名称。另外，其中一些类型在Mojo接口上是通用的，但我仅引用InstalledAppProvider的类型。
· A是通过 MessagePipe发送Mojo消息的通道。消息包括方法调用及其回复。
