深入 Adobe Reader 保护模式 —— 第一部分 —

原作者：Liz McQuarrie, Ashutosh Mehra, Suchit Mishra, Kyle Randolph, Ben Roger
译者：lordVice
校对： StrokMitream
看雪翻译小组

介绍

我是 Kyle Randolph，和我一起的还有负责 Acrobat 系列产品的安全团队，这些产品中就包含今天我要讨论的， Adobe Reader。我将讲解七月份刚刚发布的应用于 Adobe Reader 保护模式中新的沙箱技术，这是系列文章中的第一篇。我们将带你了解沙箱为了遏制恶意代码执行而设计的结构，以及它的运作和各个组件之间的通信过程。

什么是沙箱

沙箱是一种可以将应用程序放在一个受限制的环境中运行的技术，其中一些特定的行为是被禁止的（如安装或删除文件，或更改系统信息）。在 Adobe Reader 中，“沙箱”（即保护模式）提供了更强的防护，使得 PDF 中包含的恶意代码会被遏制，并阻止对用户系统的提权行为。

Adobe Reader沙箱利用操作系统的安全控制功能将进程执行限制在最低的权限下。因此，可能被攻击者控制的进程只能执行有限的动作，而且必须通过一个独立且可靠的进程接触到文件。这个设计有三个主要的效果：

所有的 PDF 进程如 PDF 和图片的解析，JavaScript 运行，字体渲染和 3D 渲染都在沙箱中进行。
进程需要在沙箱外进行一些行为，必须通过一个叫做“broker process”可信的代理来进行。
该沙箱首次隔离了两个安全主体：用户主体，即当前登录用户的运行环境；以及** PDF 主体**，是一个隔离的进程，用于解析和渲染 PDF。这个分隔沙箱进程、其余的当前用户会话及操作系统的分隔带，是构建在进程级的可信边界之上的。

这个设计的目的在于将所有潜在的恶意数据在一个受限的 PDF 主体的环境中处理，而不是在一个拥有完全权限的用户主体下进行。正如下图所示，进程间通讯（IPC）会在沙箱的 broker 需要以用户主体，而非 PDF 主体进行一些行为时被启用，例如调用一个操作系统的 API 或获取某个文件的写权限。

沙箱技术对于大多数企业应用来说是很新的技术，因为它很难应用于已经部署有众多成熟软件（拥有上百万行代码的软件）的环境中。最近在产品中体现出沙箱概念的软件包括 Microsoft Office 2007 MOICE， Google Chrome，以及 Office 2010 保护模式。问题的难点在于如何在启动沙箱的同时，维持用户所依赖的功能仍能够运行。而终极目标是主动地提供一个支持漏洞发现与修复的高水平防护。

设计原则

沙箱的设计中包括了几个安全的最佳实践：

利用现有的操作系统安全架构： Adobe Reader 依赖于 Windows 操作系统的安全特性，例如受限的 token，任务对象以及低操作权限。
利用现有的实现： Adobe Reader 沙箱建立于 Google Chrome 沙箱之上，并且也将 Microsoft Office 2010 保护模式加入参考之中。
坚持最低权限的原则： 所有的进程（可执行代码）仅能在其合理的目的下接触到必需的资源。
“不信任”推定： 在验证合法性之前，假设所有于沙箱之外的数据通信都是潜在的恶意数据。

Reader 沙箱提供的漏洞缓解

为了便于此次的探讨，让我们假设攻击者能够通过一个未知的漏洞在 Adobe Reader 中执行任意的代码，并且能够引诱用户打开一个邮件附件里的 PDF 文件，或者打开一个攻击者控制的网站中的 PDF。曾经，仅仅双击并渲染 PDF 文件就能够完全地控制用户的电脑。例如，攻击者知道并能够利用一个未知的字体 JavaScript API 内存溢出漏洞，或者字体组件中的整数溢出漏洞。一旦完成了exploit,很显然，攻击者就会通过垃圾邮件、广告，或者放在受欢迎的网站上来传播，引诱受害者们打开武装好的 PDF 文件。

当前的目标： Adobe Reader 的沙箱架构初步聚焦于阻止攻击者做两件事情：

在用户的电脑上安装恶意软件
在用户使用其它程序的时候，监控用户的键盘输入

如果攻击者能够成功地避开上述的防御，那么他将能够对用户造成严重的损害。例如，一旦攻击者能够在用户的电脑上安装恶意软件，那么他就可以任意地修改文件系统和注册表，并且还有可能安装客户端来实现网络上的协同攻击。另一个场景下，当攻击者可以监控用户的键盘输入时，他就可以尝试偷取机密和敏感信息，如密码和信用卡信息。

所以简单来讲，Adobe Reader 沙箱与 Google Chrome 沙箱类似，不允许攻击者在用户的文件系统上安装永久或临时的恶意软件，并阻止攻击者获得对用户电脑的控制。这个与我们的设计理念——最低权限相符：一个漏洞可以用于运行一些程序但并不能对用户的电脑进行恶意行为，因为它的权限被完全隔离在了高度受限的沙箱环境中。总而言之，这极大地减小了 Adobe Reader 的攻击面。

局限

沙箱对于操作系统的依赖意味着它的表现可能取决于操作系统的漏洞。正如 Google Chrome 沙箱，Adobe Reader 保护模式利用了 Windows 安全模型以及操作系统提供的安全措施。这个内在的依赖性意味着沙箱并不能够防护操作系统的弱点或漏洞。然而，当程序运行在沙箱中时，它可以在一定程度上降低漏洞利用的严重程度，因为沙箱屏蔽了许多常用的攻击向量。

我们的第一版沙箱设计并没有对以下方面进行保护：

对文件系统和注册表在未授权的情况下进行读取。我们计划在未来的版本中解决这一问题。
网络权限。我们正在对未来能够限制网络权限的方法进行调查研究，
对粘贴板的读写权限
不安全的操作系统配置

根据 Windows 沙箱化的说明， Windows 沙箱的最后一部分是用独立的桌面进行用户界面（UI）的渲染。我们不采用这样的方法因为改变 Adobe Reader 很麻烦。取而代之的是，我们通过列出在使用同一个桌面时可能的攻击方向，如粉碎攻击（shatter attack）和 SetWindowsHookEx DLL 注入攻击。这些攻击可以被多种方法避免，比如对沙箱中的任务目标使用低完整性和限制，这将会在之后的篇章中讨论到。

结束语

这总结了对 Adobe Reader 保护模式沙箱的架构和局限的概览。在之后的篇章中，我们将会探索沙箱的进程和 broker 进程的更多详细信息，以及它们的进程间交流（IPC）技术。最终，我们会对在 Adobe Reader 上用于验证的安全测试进行一些评价。