Azimuth Security: The Chrome Sandbox (2010) Part 1
**这是一篇发布于2010年的文章，许多内容可能已经过时**
http://blog.azimuthsecurity.com/2010/05/chrome-sandbox-part-1-of-3-overview.html
http://blog.azimuthsecurity.com/2010/08/chrome-sandbox-part-2-of-3-ipc.html
机器翻译人工润色
今年早些时候，CanSecWest举办了流行的“Pwn2Own”竞赛，参赛者试图利用他们在流行的软件包中发现的漏洞。该比赛非常关注网络浏览器，今年它并没有让人失望：除了谷歌的Chrome之外所有主要的网络浏览器都被成功入侵。我相信Chrome的生存主要归功于它的集成沙箱，它旨在隔离浏览器，使其无法在运行它的系统上执行任何潜在的不利操作。过去几个月我一直在谷歌与谷歌合作，其中一项主要指控是对沙箱及其相关组件进行安全审查。
第一篇文章将讨论基本的Chrome架构和流程交互。它旨在成为一个高级别的介绍，为将在后续内容上提出的更多技术性讨论奠定基础。第二篇文章将重点介绍Chrome进程用于相互通信的消息传递工具。这些通信失败是Chrome沙箱功能的基础，但更重要的是暴露了广泛的攻击面以实现权限提升。最后的帖子将详细介绍用于从系统其余部分沙箱渲染器进程的Linux和Windows操作系统功能的细节。
多进程架构
Chrome采用多进程架构作为Google“最小特权原则”安全策略的一部分。实质上，沙箱试图将进程与访问目标系统上任何有价值的东西隔离开来 - 包括文件，其他进程和IPC对象（Chrome本身使用的除外）。为了理解Chrome的沙箱，熟悉在浏览会话期间通常存在的各种进程之间如何分区工作非常重要。下图说明了Chrome的多进程架构。
[那张经典的图]
注意
可能存在一些尚未描述的其他进程，具体取决于浏览会话中发生的操作。例如，可以在下载Chrome扩展程序时生成安装程序进程。为简单起见，图中省略了这些辅助进程。
下面简要描述每个主要组件。
浏览器进程 - 在浏览会话期间存在单个特权浏览器进程。浏览器进程负责根据需要生成其他进程，为其配置任务，以及代表没有所需系统访问权限的进程执行特权操作以自行执行操作。
渲染器进程 - 每次打开新选项卡或窗口时都会生成渲染器进程，并负责执行正在查看的网页的解析和呈现。这包括HTML解析，JavaScript功能和图像处理。
插件流程 - 插件托管在自己的私有进程中，并与渲染器和浏览器进程通信。每个不同的插件都有一个进程，无论该插件有多少个不同的嵌入式对象实例。默认情况下，插件进程实际上以完全权限运行（就像浏览器进程一样），但是当某些兼容性问题得到解决时，这最终会发生变化。
GPU流程 - 可选择存在单个GPU流程，以代表渲染器流程执行GPU相关任务。（**注：曾经**）GPU进程不受限于沙盒。
IPC通道 - IPC通道构成了Chrome的消息传递框架，为各种Chrome流程提供了通过本地操作系统特定的传输机制相互交互的工具。
攻击Chrome
从上面的描述中可以明显看出，由于与执行操作的进程相关的特权，某些浏览器组件中的缺陷与其他组件相比具有更严重的安全相关后果。下表提供了暴露于攻击的浏览器的一些主要组件的基本细分以及进行处理的位置。
部分 处理者
网络协议解析 浏览器
创建/管理选项卡/ Windows 浏览器
输入文本的缓存 浏览器
拼写检查/正常化 浏览器
剪贴板管理 浏览器
HTML解析/渲染 渲染
JavaScript解析 渲染
图像处理 渲染
插件 插入
GPU处理 GPU
IPC消息 [所有]
在列出的所有进程中，只有渲染器是沙箱。因此，定位由呈现器以外的任何其他内容执行的公开功能（例如网络协议解析）可能会产生导致远程访问目标系统的错误，而不会产生沙箱通常会施加的任何其他限制。话虽如此，渲染器执行的功能包含了Web浏览器常用攻击面的很大一部分，因此未来Chrome中发现的大部分漏洞可能会继续与这些组件相关。由于Chrome沙箱的限制性，攻击者必须在损害渲染器以获得进一步访问系统后使用第二个漏洞升级其权限。因此，Chrome中的权限提升向量也是任何安全审核的关键焦点。特权升级有几个主要攻击面，如下所示：
IPC消息传递 - 在用于进程间通信的消息传递框架中解析缺陷将提供获得其中一个非沙盒进程的特权的理想方法。这个区域将在下一篇博客文章中进行深入研究。
公开服务 - 参与Chrome浏览会话的每个流程都通过上述IPC渠道向其他流程公开服务。重要的是要评估可以从渲染器调用的所有公开函数，以便编程缺陷或导致沙箱旁路的无意间产生的安全漏洞。此攻击面也将在下一篇博文中广泛介绍。
沙箱弱点 -在攻击任何沙箱时，必须熟悉沙箱防范的内容，以及它在执行单独处理的各种限制时的有效性。本系列的第三篇博文将讨论沙箱本身及其在Linux和Windows上的实现方式。我还将举例说明我在两个沙箱实现中发现的漏洞
共享资源 - 应该注意的是，攻击更多特权进程有几种间接形式。具体而言，一些音频，视频和图形数据由渲染器进程提供给更具特权的进程（例如GPU进程），方法是将该数据放在共享内存缓冲区中，然后通知更具特权的进程。由于这些数据的某些解析发生在更多特权进程中，因此它可能是一种可能有用的途径，可用于定位解析漏洞以获得对系统的进一步访问。这条途径虽然很有趣，但没有进一步讨论，而是留给读者练习。
操作系统/外部软件 - 当然，攻击者可以针对操作系统内核或外部软件组件（如本地服务）中的缺陷进行攻击。这些载体超出了本讨论范围，不再进一步考虑。
结论
正如您所看到的，需要覆盖大量材料。收听我接下来的两篇文章，我会更深入地了解沙箱的细节，并提出我在整个审核过程中发现的一些缺陷！