原作者：Liz McQuarrie, Ashutosh Mehra, Suchit Mishra, Kyle Randolph, Ben Roger
譯者：lordVice
校對： StrokMitream
看雪翻譯小組

介紹

我是 Kyle Randolph， 和我一起的還有負(fù)責(zé) Acrobat 系列產(chǎn)品的安全團隊， 這些產(chǎn)品中就包含今天我要討論的， Adobe Reader。我將講解七月份剛剛發(fā)布 的應(yīng)用于 Adobe Reader 保護模式中新的沙箱技術(shù)，這是系列文章中的第一篇。我們將帶你了解沙箱為了遏制惡意代碼執(zhí)行而設(shè)計的結(jié)構(gòu)，以及它的運作和各個組件之間的通信過程。

什么是沙箱

沙箱 是一種可以將應(yīng)用程序放在一個受限制的環(huán)境中運行的技術(shù)，其中一些特定的行為是被禁止 的（如安裝或刪除文件，或更改系統(tǒng)信息）。在 Adobe Reader 中，“沙箱”（即保護模式） 提供了更強的防護，使得 PDF 中包含的惡意代碼會被遏制，并阻止對用戶系統(tǒng)的提權(quán)行為。

Adobe Reader沙箱利用操作系統(tǒng)的安全控制功能將進(jìn)程執(zhí)行限制在最低的權(quán)限下。 因此，可能被攻擊者控制的進(jìn)程只能執(zhí)行有限的動作，而且必須通過一個獨立且可靠的進(jìn)程接觸到文件。這個設(shè)計有三個主要的效果：

• 所有的 PDF 進(jìn)程如 PDF 和圖片的解析，JavaScript 運行，字體渲染和 3D 渲染 都在沙箱中進(jìn)行。
• 進(jìn)程需要在沙箱外進(jìn)行一些行為，必須通過一個叫做“broker process”可信的代理來進(jìn)行。
• 該沙箱首次隔離了兩個安全主體：用戶主體，即當(dāng)前登錄用戶的運行環(huán)境； 以及** PDF 主體**，是一個隔離的進(jìn)程，用于解析和渲染 PDF。這個分隔沙箱進(jìn)程、其余的當(dāng)前用戶會話及操作系統(tǒng)的分隔帶，是構(gòu)建在進(jìn)程級的可信邊界之上的。

這個設(shè)計的目的在于將所有潛在的惡意數(shù)據(jù)在一個受限的 PDF 主體的環(huán)境中處理， 而不是在一個擁有完全權(quán)限的用戶主體下進(jìn)行。正如下圖所示，進(jìn)程間通訊（IPC） 會在沙箱的 broker 需要以用戶主體，而非 PDF 主體進(jìn)行一些行為時被啟用，例如調(diào)用一個 操作系統(tǒng)的 API 或獲取某個文件的寫權(quán)限。

沙箱技術(shù)對于大多數(shù)企業(yè)應(yīng)用來說是很新的技術(shù)，因為它很難應(yīng)用于已經(jīng)部署有眾多成熟軟件（擁有上百萬行代碼的軟件）的環(huán)境中。最近在產(chǎn)品中體現(xiàn)出沙箱概念的軟件包括 Microsoft Office 2007 MOICE， Google Chrome， 以及 Office 2010 保護模式。問題的難點在于如何在啟動沙箱的同時，維持用戶所依賴的功能仍能夠運行。而終極目標(biāo)是主動地提供一個支持漏洞發(fā)現(xiàn)與修復(fù)的高水平防護。

設(shè)計原則

沙箱的設(shè)計中包括了幾個安全的最佳實踐：

• 利用現(xiàn)有的操作系統(tǒng)安全架構(gòu)： Adobe Reader 依賴于 Windows 操作系統(tǒng)的安全特性，例如受限的 token，任務(wù)對象以及低操作權(quán)限。
• 利用現(xiàn)有的實現(xiàn)： Adobe Reader 沙箱建立于 Google Chrome 沙箱之上，并且也將 Microsoft Office 2010 保護模式加入?yún)⒖贾小?/li>
• 堅持最低權(quán)限的原則： 所有的進(jìn)程（可執(zhí)行代碼）僅能在其合理的目的下接觸到必需的資源。
• “不信任”推定： 在驗證合法性之前，假設(shè)所有于沙箱之外的數(shù)據(jù)通信都是潛在的惡意數(shù)據(jù)。

Reader 沙箱提供的漏洞緩解

為了便于此次的探討，讓我們假設(shè)攻擊者能夠通過一個未知的漏洞在 Adobe Reader 中執(zhí)行任意的代碼，并且能夠引誘用戶打開一個郵件附件里的 PDF 文件，或者打開一個攻擊者控制的網(wǎng)站中的 PDF。曾經(jīng)，僅僅雙擊并渲染 PDF 文件就能夠完全地控制用戶的電腦。例如，攻擊者知道并能夠利用一個未知的字體 JavaScript API 內(nèi)存溢出漏洞，或者字體組件中的整數(shù)溢出漏洞。一旦完成了exploit,很顯然，攻擊者就會通過垃圾郵件、廣告，或者放在受歡迎的網(wǎng)站上來傳播，引誘受害者們打開武裝好的 PDF 文件。

當(dāng)前的目標(biāo)： Adobe Reader 的沙箱架構(gòu)初步聚焦于阻止攻擊者做兩件事情：

在用戶的電腦上安裝惡意軟件

在用戶使用其它程序的時候，監(jiān)控用戶的鍵盤輸入

如果攻擊者能夠成功地避開上述的防御，那么他將能夠?qū)τ脩粼斐蓢?yán)重的損害。例如，一旦攻擊者能夠在用戶的電腦上安裝惡意軟件，那么他就可以任意地修改文件系統(tǒng)和注冊表，并且還有可能安裝客戶端來實現(xiàn)網(wǎng)絡(luò)上的協(xié)同攻擊。另一個場景下，當(dāng)攻擊者可以監(jiān)控用戶的鍵盤輸入時，他就可以嘗試偷取機密和敏感信息，如密碼和信用卡信息。

所以簡單來講，Adobe Reader 沙箱與 Google Chrome 沙箱類似，不允許攻擊者在用戶的文件系統(tǒng)上安裝永久或臨時的惡意軟件，并阻止攻擊者獲得對用戶電腦的控制。這個與我們的設(shè)計理念——最低權(quán)限相符：一個漏洞可以用于運行一些程序但并不能對用戶的電腦進(jìn)行惡意行為，因為它的權(quán)限被完全隔離在了高度受限的沙箱環(huán)境中。總而言之，這極大地減小了 Adobe Reader 的攻擊面。

局限

沙箱對于操作系統(tǒng)的依賴意味著它的表現(xiàn)可能取決于操作系統(tǒng)的漏洞。正如 Google Chrome 沙箱，Adobe Reader 保護模式利用了 Windows 安全模型以及操作系統(tǒng)提供的安全措施。這個內(nèi)在的依賴性意味著沙箱并不能夠防護操作系統(tǒng)的弱點或漏洞。然而，當(dāng)程序運行在沙箱中時，它可以在一定程度上降低漏洞利用的嚴(yán)重程度，因為沙箱屏蔽了許多常用的攻擊向量。

我們的第一版沙箱設(shè)計并沒有對以下方面進(jìn)行保護：

• 對文件系統(tǒng)和注冊表在未授權(quán)的情況下進(jìn)行讀取。我們計劃在未來的版本中解決這一問題。
• 網(wǎng)絡(luò)權(quán)限。我們正在對未來能夠限制網(wǎng)絡(luò)權(quán)限的方法進(jìn)行調(diào)查研究，
• 對粘貼板的讀寫權(quán)限
• 不安全的操作系統(tǒng)配置

根據(jù) Windows 沙箱化的說明， Windows 沙箱的最后一部分是用獨立的桌面進(jìn)行用戶界面（UI）的渲染。我們不采用這樣的方法因為改變 Adobe Reader 很麻煩。取而代之的是，我們通過列出在使用同一個桌面時可能的攻擊方向，如粉碎攻擊（shatter attack）和 SetWindowsHookEx DLL 注入攻擊。這些攻擊可以被多種方法避免，比如對沙箱中的任務(wù)目標(biāo)使用低完整性和限制，這將會在之后的篇章中討論到。

結(jié)束語

這總結(jié)了對 Adobe Reader 保護模式沙箱的架構(gòu)和局限的概覽。在之后的篇章中，我們將會探索沙箱的進(jìn)程和 broker 進(jìn)程的更多詳細(xì)信息，以及它們的進(jìn)程間交流（IPC）技術(shù)。最終，我們會對在 Adobe Reader 上用于驗證的安全測試進(jìn)行一些評價。

總結(jié)

以上是生活随笔為你收集整理的深入 Adobe Reader 保护模式 —— 第一部分 —— 设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。