原作者：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 的沙箱架構初步聚焦于阻止攻擊者做兩件事情：

1. 在用戶的電腦上安裝惡意軟件
2. 在用戶使用其它程序的時候，監控用戶的鍵盤輸入

如果攻擊者能夠成功地避開上述的防御，那么他將能夠對用戶造成嚴重的損害。例如，一旦攻擊者能夠在用戶的電腦上安裝惡意軟件，那么他就可以任意地修改文件系統和注冊表，并且還有可能安裝客戶端來實現網絡上的協同攻擊。另一個場景下，當攻擊者可以監控用戶的鍵盤輸入時，他就可以嘗試偷取機密和敏感信息，如密碼和信用卡信息。

所以簡單來講，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 上用于驗證的安全測試進行一些評價。