这个设计的目的在于将所有潜在的恶意数据在一个受限的 PDF 主体的环境中处理, 而不是在一个拥有完全权限的用户主体下进行。正如下图所示,进程间通讯(IPC) 会在沙箱的 broker 需要以用户主体,而非 PDF 主体进行一些行为时被启用,例如调用一个 操作系统的 API 或获取某个文件的写权限。
沙箱技术对于大多数企业应用来说是很新的技术,因为它很难应用于已经部署有众多成熟软件(拥有上百万行代码的软件)的环境中。最近在产品中体现出沙箱概念的软件包括 Microsoft Office 2007 MOICE, Google Chrome, 以及 Office 2010 保护模式。问题的难点在于如何在启动沙箱的同时,维持用户所依赖的功能仍能够运行。而终极目标是主动地提供一个支持漏洞发现与修复的高水平防护。
沙箱的设计中包括了几个安全的最佳实践:
为了便于此次的探讨,让我们假设攻击者能够通过一个未知的漏洞在 Adobe Reader 中执行任意的代码,并且能够引诱用户打开一个邮件附件里的 PDF 文件,或者打开一个攻击者控制的网站中的 PDF。曾经,仅仅双击并渲染 PDF 文件就能够完全地控制用户的电脑。例如,攻击者知道并能够利用一个未知的字体 JavaScript API 内存溢出漏洞,或者字体组件中的整数溢出漏洞。一旦完成了exploit,很显然,攻击者就会通过垃圾邮件、广告,或者放在受欢迎的网站上来传播,引诱受害者们打开武装好的 PDF 文件。
所以简单来讲,Adobe Reader 沙箱与 Google Chrome 沙箱类似,不允许攻击者在用户的文件系统上安装永久或临时的恶意软件,并阻止攻击者获得对用户电脑的控制。这个与我们的设计理念——最低权限相符:一个漏洞可以用于运行一些程序但并不能对用户的电脑进行恶意行为,因为它的权限被完全隔离在了高度受限的沙箱环境中。总而言之,这极大地减小了 Adobe Reader 的攻击面。
沙箱对于操作系统的依赖意味着它的表现可能取决于操作系统的漏洞。正如 Google Chrome 沙箱,Adobe Reader 保护模式利用了 Windows 安全模型以及操作系统提供的安全措施。这个内在的依赖性意味着沙箱并不能够防护操作系统的弱点或漏洞。然而,当程序运行在沙箱中时,它可以在一定程度上降低漏洞利用的严重程度,因为沙箱屏蔽了许多常用的攻击向量。
我们的第一版沙箱设计并没有对以下方面进行保护:
根据 Windows 沙箱化的说明, Windows 沙箱的最后一部分是用独立的桌面进行用户界面(UI)的渲染。我们不采用这样的方法因为改变 Adobe Reader 很麻烦。取而代之的是,我们通过列出在使用同一个桌面时可能的攻击方向,如粉碎攻击(shatter attack)和 SetWindowsHookEx DLL 注入攻击。这些攻击可以被多种方法避免,比如对沙箱中的任务目标使用低完整性和限制,这将会在之后的篇章中讨论到。