CVE-2018-4990 漏洞詳情分析

原文地址：

測試版本:AcroRdrDC1700920044_en_US

漏洞模組: Escript.api

漏洞函式

修復函式

問題分析

複製物件的時候把DWORD型別的物件地址作為BYTE型別進行了複製，堆物件複製溢位漏洞。物件偏移在0x50的地方，也就是錯誤的位置。



Javascript裡面噴射的物件程式碼。

修復方案

定位到問題很好修復。

ROP技術

使用EScript.api模組作為ROP執行地址，基址為69260000，ROP表如下.

0D130064 692E2803 EScript.692E2803

0D130068 692E2803 EScript.692E2803

0D13006C 692E2802 EScript.692E2802

0D130070 693F7084 <&KERNEL32.VirtualAlloc>

0D130074 69271784 EScript.69271784

0D130078 693EAF26 EScript.693EAF26

0D13007C 69278000 EScript.69278000

0D130080 69283AAA EScript.69283AAA

0D130084 6936F282 EScript.6936F282

0D130088 00010201

0D13008C 692E2802 EScript.692E2802

0D130090 692695C4 EScript.692695C4

0D130094 77842FB6 kernel32.VirtualAlloc

0D130098 69283AAA EScript.69283AAA

第一條ROP指令RETN在692E2803，為一條RETN指令。因為有ASLR保護，所以地址看起來不一樣。

ROP指令不進行一一講解，接下來透過ROP技術構造了一個函式VirtualAlloc分配一段記憶體。注意看下EAX暫存器的值。

EAX是0x90909090，adobe的javascript的堆噴射器裡面也有0x90909090。

使用VirtualAlloc函式申請了一段可讀可寫可執行的記憶體，大小為66049位元組。為什麼呢?因為惡意pdf裡面還有個pe檔案，shellcode應該帶有一個pe載入器，直接在本程式在記憶體執行pe檔案。

接下來返回到了惡意記憶體中的shellcode繼續執行。注意一下，前面4位元組是0x90。說明那個是填充的NOP指令。

Shellcode

第一個功能就是在shellcode長度(0x2710位元組長度)後面搜尋一個4位元組的標記0xBFAFBFAF。搜尋標記的作用是定位PE頭。

接下來用經典的fs:[0x30]技術定位kernel32的基址。

接下來透過解析PE檔案搜尋GetProcAddress函式的地址，這也是windows經典的shellcode技術。

<p style="font-size:16px;" >使用getprocaddress函式得到loadlibrarya、virtualalloc、virtualfree、virtualprotect、getmodulehandlea的地址

接著是PE載入器的經典功能，複製PE頭、修復區段、重定位、填充輸入表等等。

接著使用VirtualProtect函式改寫PE為可讀可執行可寫。

最後呼叫PE檔案的入口函式，因為PE是dll所以入口是DllMain。

這個dll只有一個功能，使用MessageBoxA彈一個對話方塊。

Dll的入口函式。

完事收工。