Principle Analysis of Word type Obfuscation Vulnerability (CVE-2015-1641)

Principle Analysis of Word type Obfuscation Vulnerability (CVE-2015-1641)

Aforementioned
Word does not verify the customXML object when parsing docx documents to process the displacedbymmxml attribute. It can pass in other tag objects for processing, resulting in type confusion and arbitrary memory writing, finally, the well-constructed labels and corresponding attribute values can cause remote arbitrary code execution.
The Exploitation details of this vulnerability and shellcode are currently listed in many analysis cases on the network. I am personally interested in how to locate the trigger point and trigger condition of this vulnerability. Therefore, I will try to locate this vulnerability step by step in this article.
Related Knowledge
In the previous articles, the analysis of Ropchain and 91ri-Leon is based on breakpoint debugging at the heap injection address 0x7c342404 In the POC, so that the program can go directly to shellcode and further analyze the entire exploitation process, therefore, my initial thought was to try to use the breakpoint backtracking 0x7c342404 to check whether the key functions can be found. However, it was very difficult to do this (possibly due to the debugging method problem ), you have to give up. I recently accidentally saw an article by Wayne Chin. He used a simple and crude method to directly modify the POC, then, the crash word triggers the exception of the debugger to locate the vulnerability and try it.
Lab environment:
OS: Windows 7
Word version: word 2010 sp2
Wwlib. dll version: 14.0.7015.1000
Build and modify POC
Since crash word is required, the POC must be modified as appropriate. Ropchain lists the main modules in the POC, as shown in the following table.
　　

Analysis shows that the POC file is an RTF file, which is constructed by embedding multiple OLE objects. In the table above, the first one is to load an ActiveX/COM Object otkloadr. WRAssembly.1: Call MSVCR71.DLL (bypass ASLR). The other three are embedded docx documents: the first docx, which uses Heap Spray to locate shellcode and drop-through DEP protection, and the second docx, it is the module that triggers the vulnerability, and the third docx is also the Heap Spray. Therefore, the third module that triggers the vulnerability is extracted from the original POC sample to obtain the modified sample file.
　　

It is strange that the extracted file size is inconsistent with that of Wayne Chin, which is the size of the file before and after Wayne Chin extraction.
　　

We found that the manually extracted file is KB different from Wayne Chin. It should be that his file also contains an OLE object. However, this does not affect the experiment.
Crash
After Windbg debugging and modification of the orignal_strip_first_second_fourth_ole.rtf file, word really crash, scene.
　　

Of course, to avoid accidental occurrence, crash remains stable after this process is reproduced N times. We can see that ECX always points to the address 0x7C38BD50. If it is a complete POC file, [ecx] certainly exists, and this address should exist in MSVCR71.DLL, this module is required to exploit the vulnerability. Verify that you have added the MSVCR71.DLL module to orignal_strip_first_second_fourth_ole.rtf, that is, add {\ object \ objocx {\ * \ objdata internal issue }}, set the module to load the breakpoint.
　　

The first module calls MSVCR71.DLL after loading otkloadr, and the address 0x7C38BD50 is located in MSVCR71.DLL. Extract the docx file from the RTF sample and decompress it using winrar. The address information exists in the document. xml file under path .. \ word.
　　

We can see that 0x7C38BD50 is constructed in the smartTag element. Therefore, it is generally clear that the vulnerability caused by an error in parsing smartTag by word. This is Microsoft's explanation of smartTag.
　　

This is a smart tag that can automatically recognize names and addresses. First, find out how the Word parses the tag.
Parsing process
By using the OD conditional breakpoint function, you can set the break condition before the crash position. The advantage of this conditional breakpoint is that the breakpoint will not disappear after heavy load, in this way, we can accurately break down at the desired position ,.
　　

The process of parsing the first smartTag tag in the sample by word can be found through several layers,
　　

After analysis, v18 points to the smartTag object, and * (v18 + 4) = 0x7C38BD50 stores the element value of the smartTag tag, src = 0xFFFFE696 (decimal 4294960790) the value of moveFromRangeStart is stored, and a series of calculations are performed on the two values to obtain an address 0x7C38BD74 for backup. The procedure is as follows:
　　

Then, the second smartTag is parsed, which is the same as the process of parsing the first smartTag. The element value of the smartTag tag is 0x7C38BD68, and the value of moveFromRangeStart is 0x7C376FC3 (decimal 2084007875 ), the calculated address is 0x7C38A428, And the memcpy function overwrites 0x7C376FC3 to the address 0x7C38A428.
Therefore, 0x7C38A428 is a virtual table pointer, which overwrites the virtual function pointer 0x76DE6D07 stored in the virtual table and points to kernel32.dll. It is overwritten as 0x7C376FC3 pointing to msvcr71.dll.
　　

Therefore, the original virtual function address was replaced by an arbitrary address by an attacker, and the vulnerability was exploited successfully.
Patch Analysis
Microsoft released the patch number KB2553428 on word2010 for this vulnerability, but it did not release the sp1 Patch. the patch is for sp2, so the sp1 office still has the vulnerability. The patch comparison tool Bindiff 4.2 was originally used for comparison. The size of the wwlib. dll file is 18 MB, which has been tried many times and cannot be fully compared, as shown in.
　　

This may be a bug in the software. In the end, you can use IDA to search for key commands to locate the key functions before and after the patch, as shown in.
　　

Through patch analysis, we can find that the functions before and after the patch mainly add verification before processing the smartTag. According to Alibaba's analysis, the incoming object pointer edi is the customXML Object Pointer, while [ebx + 48] is the current object pointer, in the patch file, only the current object is customXML. Otherwise, exit the program directly. The vulnerability is triggered by parsing the smartTag object. Therefore, this vulnerability does not distinguish customXML from the smartTag object, resulting in the object type confusion vulnerability.