原作者：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 上用於驗證的安全測試進行一些評價。