看到xfocus上新貼了microsoft office excel 緩衝區溢出漏洞
就想自己分析一下其原理，可惜沒有搞定，只是明白了其大概
分析過程如下
第一
EXCEl每打開一個.xls文件時都會執行如下代碼，準備開闢一塊緩衝區，
緩衝區的大小應該是固定的，具體情況要根據函數被調用的上下文決定。
3003FCAC <EXCEL.tab1-1> movzx eax,word ptr ds:[ebx]
3003FCAF xor ecx,ecx
3003FCB1 cmp eax,0E
3003FCB4 mov dword ptr ss:[ebp-8],ecx
3003FCB7 jg <EXCEL.tab1-2>
第二
緩衝區的長度存儲在ds:[ebx]處，取該值放於eax中，只有該值大於14時，
纔對緩衝區初始化。
第三
緩衝區的起始地址是ss:[ebp-130]，因爲用ebp作索引，肯定在棧中。
301BFF47 <EXCEL.tab1-2> mov byte ptr ss:[ebp+ecx-130],cl
301BFF4E inc ecx
301BFF4F cmp ecx,0E
301BFF52 jle short <EXCEL.tab1-2>
第四
緩衝區的前15個字節初始化如下
000102030405060708090A0B0C0D0E
第五
緩衝區的剩餘部分(eax-15字節)，也就是從地址ss:[ebp+15-130]開始,
以4個字節爲單位,用0E0E0E0E初始化。
301BFF54 cmp ecx,eax
301BFF56 mov dword ptr ss:[ebp-8],ecx
301BFF59 jg EXCEL.3003FE14
301BFF5F sub eax,ecx
301BFF61 lea edi,dword ptr ss:[ebp+ecx-130]
301BFF68 inc eax
301BFF69 mov edx,eax
301BFF6B mov eax,0E0E0E0E
301BFF70 mov ecx,edx
301BFF72 mov esi,ecx
301BFF74 shr ecx,2
301BFF77 rep stos dword ptr es:[edi]//該處存在緩衝區溢出的可能
第六
剩餘部分的計算方法是
eax-15+1--->二進制右移2位(除以4)--->得的值乘以4(單位byte)
第七
考慮溢出的原因?
緩衝區的大小是固定的(eax的值)，
緩衝區的初始化是分兩部分完成的15bytes+在上文第六點中得出的結果。
如果初始化的長度大於緩衝區的固定大小，就導致棧緩衝區溢出了。
舉一個例子，eax=46
46-15+1=32
32的二進制表示是100000，右移2位1000,即8
8*4+15=47>46這樣就緩衝區溢出了。
第八
是誰導致了溢出?
有兩點值得懷疑，
一是eax的初始值，如果該值錯了，肯定有緩衝區溢出的可能；
二是上文第六點中計算剩餘部分的算法有問題,正如第七點中的例子所示。
第九
調試的問題?
ollydbg + microsoft excel 2000 + test.xls
該溢出只有在特殊的.xls文件作用下才會觸發，
對於一般的.xls文件，eax的值是0E，根本就走不到溢出點
要想利用該漏洞，有兩種辦法
一是，找到或者構造特殊的.xls文件，進一步跟蹤調試，
這種方式是最方便的；
二是，分析eax值得來源，從代碼看，就是反向追溯和正向跟蹤，
從原理上找到原因。
第十
進一步的思考
這個漏洞是與.xls文件相關的，並且必須是精心構造的.xls文件
其中eax值應該與.xls文件的某個屬性有關。
爲此，我查看了.xls的文件格式BIFF，其中有一種記錄類型PRECISION,
它的操作碼是0E,或許和這個漏洞有一定的關係。
第十一
下一步的工作量就很大了，我短時間內很難搞定。
第十二
看到有些網站有如下描述:
如果能夠通過Excel .xls文件的數據字段向"msvcrt.memmove()"傳送很大的值的話，
就可能導致內存破壞，執行任意代碼。
然後構造很大的數據字段,並定位到msvcrt.memmove(),卻沒有截獲到異常:(
又看到另一則描述:
Overview:
=========
A vulnerability exists in Microsoft Excel which can be exploited to run
a code of attacker's choice on user's PC.
Affected products:
==================
All tests were performed using Microsoft Excel 2003 (11.6560.6568) on
Windows XP and Windows 2000 Pro platforms. It is likely that all MS Excel
products are vulnerable.
Cause and Effect:
=================
Sufficient data validation is not performed when parsing "Named Range"
definitions in the document file, which makes possible to produce a negative
32-bit value that is later used as a length parameter for msvcrt.memmove()
function. As a result, a large chunk of memory is copied overwriting
critical memory ranges, including the stack space.
Demonstration:
==============
Below is a fragment of the empty XLS file containing a named range definition
"Sheet1!TEST1". Two bytes marked with asterisks cause exception to occur
when set to 0xFF.
00000720 00 80 00 ff 93 02 04 00 14 80 05 ff 60 01 02 00 |............`...|
00000730 00 00 85 00 0e 00 ba 05 00 00 00 00 06 00 53 68 |..............Sh|
00000740 65 65 74 31 8c 00 04 00 01 00 01 00 ae 01 04 00 |eet1............|
00000750 01 00 01 04 17 00 08 00 01 00 00 00 00 00 00 00 |................|
00000760 18 00 1b 00 00 00 00 05 07 ** ** 00 00 00 00 00 |................|
00000770 00 00 00 54 45 53 54 31 3a 00 00 00 00 00 00 c1 |...TEST1:.......|
00000780 01 08 00 c1 01 00 00 22 be 01 00 fc 00 08 00 00 |......."........|
00000790 00 00 00 00 00 00 00 ff 00 02 00 08 00 63 08 15 |.............c..|
仿照上面的方法也構造了一個test.xls文件,類似的fragment如下
00000870h: 93 02 04 00 14 80 06 FF 60 01 02 00 01 00 85 00 ; ?...€.`.....?
00000880h: 0E 00 ED 06 00 00 00 00 06 00 53 68 65 65 74 31 ; ..?......Sheet1
00000890h: 8C 00 04 00 56 00 56 00 AE 01 04 00 01 00 01 04 ; ?..V.V.?......
000008a0h: 17 00 08 00 01 00 00 00 00 00 00 00 18 00 1B 00 ; ................
000008b0h: 00 00 00 05 07 ** ** 00 00 00 00 00 00 00 00 74 ; .............t
000008c0h: 65 73 74 31 3A 00 00 00 00 00 00 C1 01 08 00 C1 ; est1:......?..?
000008d0h: 01 00 00 80 38 01 00 FC 00 08 00 00 00 00 00 00 ; ...€8..?.......
000008e0h: 00 00 00 FF 00 02 00 08 00 0A 00 00 00 09 08 10 ; ...............
結果跟蹤到異常，出現在excel.memmove()處
異常的原因是memmove的第三個參數爲負值
在上例中n=FFFFFF07(-249),異常語句是308D0168,不過該異常不在棧內
經粗略分析,應該是命名區域的問題,下一步需要分析命名區域的格式
再作打算!