如何使用類型混淆在Adobe Reader執行代碼

本篇文章給大家分享的是有關如何使用類型混淆在Adobe Reader執行代碼，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

前言

該漏洞的潛在原因是類型混淆。攻擊者通過構造XML數據包(XDP)模板并在XML Forms Architecture (XFA)對象上執行特定的JavaScript操作，可以迫使Reader跳出模板對象的范圍來引用數據。如果成功，就會在沙盤渲染程序中執行代碼執行。

漏洞分析

觸發該漏洞所需的XDP模板代碼相當簡單：
該漏洞由兩個JavaScript指令觸發。通過將一個子表單附加到另一個子表單，我們可以觸發對底層模板對象的超界(OOB)讀取。在這種情況下，當附加一個xfa引用的子表單時，就會出現漏洞。然后調用 <object>.presence = “inactive”;.
啟用PageHeap后，在讀取模板對象的OOB時，CMP指令上發生崩潰。雖然對象看起來只有0x140字節大小，但是我們在偏移量0x1d0處取消了對緩沖區邊界以外數據的引用：
根據崩潰情況，我們知道唯一對象的類型是0x7c00。通過觀察acroform.api的符號化版本。在Solaris 9.4.1中，我們可以看到這個特定類型的id屬于XFATemplateModelImpl對象，它只是底層XDP的“模板”對象：回到非符號化的Windows版本的acroform.api,我們可以確認模板對象的大小為0x140字節，這是上面引用的OOB對象的大小。我們可以通過幾個簡單的步驟找到:在XFATemplateModelImpl::Type method中Acroform.api可以找到靜態變量0x7c00。
Xref提供XFATemplateModelImpl vtable：

-Xref到vtable start提供構造函數。-Xref到構造函數并向上滾動幾行顯示對象的大小，即0x140字節：
由于我們導致了對模板對象的OOB讀取，所以我們可以推測代碼預期的是一個不同的、更大的對象，而不是模板對象，這也表明這是一個類型混淆錯誤。最有可能的是，類型混淆發生在xfa模板和xfa表單對象之間。而xfa模板大小為0x140字節，即xfa表單對象的大小為0x270字節。

##  Exploit我們不能在模板對象被實例化之前執行JavaScript代碼，要知道控制崩潰不是件小事。要實現這一點，需要在PDF解析過程或XDP解析之前的任何其他受控數據處理過程中求助于可控制的分配和釋放。控制崩潰的另一種方法是構造一個PDF，其中包含一個附加的PDF，這會觸發漏洞。Heap feng shui將發生在“外部”PDF中，觸發“內部”(附件)PDF中的vuln。然后，以使其執行JavaScript代碼的方式打開附加的PDF需要更高的權限，因此它可能對大多數用戶無效。通過執行“poc.pdg”可以觀察到這種崩潰是可以控制的。即使沒有PageHeap。由于要讀取Unicode字符串的某些部分并將其用作指針，因此最終會發生崩潰。下面是一個沒有PageHeap的崩潰輸出：

如果你想親自測試一下，PoC就在這里。它可以在2018.011.20040之前在adobereader版本上起作用。看看我們今年發布的建議，你會發現很多pdf相關的案例。adobereader可能是最流行的，但是Foxit Reader中也存在大量bug。在操作系統中加入內置的PDF渲染器，就可以理解為什么如此多的研究人員研究這種攻擊表面。

以上就是如何使用類型混淆在Adobe Reader執行代碼，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。