CVE-2017-11826: Office Open XML tag nested parsing obfuscation vulnerability

\x01 Preface

• CVE-2017-11826It is said that 360 discovered a vulnerability in XML format parsing at the end of September 2017. Microsoft later 10released CVE-2017-11826a patch in September. The patch address is: https://portal.msrc.microsoft.com/en-US/security- guidance/advisory/CVE-2017-11826
  
• The cause of this vulnerability is that when parsing a closed element, the integrity of the element is not judged, resulting in the nesting relationship of the current element being added 1. In this case, wwlibwhen the module processes the closing tag, it will mistakenly use the address of the parent element 's w:nameattribute +44to make a virtual function call. By modifying the attribute, the attacker w:namecan make any address call.
• Affected Officeversions.
  

\x02 Debugging environment

• Operating system: Windows 7 + VMware
• Debugging tool: x64dbg
• Vulnerability sample: POC (extraction code: lxx6)

\x03 Debugging analysis

• GitHubDownload the folder about the vulnerability from CVE-2017-11826, and after decompressing it, it is found that it contains decompressed docxfiles, READMEdocuments, and Russian documents. I did not read the Russian document carefully, but it seems to be about exploiting the vulnerability.
  
• XMLThe file containing the vulnerability is document.xml, and the file is wordunder the path. Open document.xmlthe file, and after analysis, it is found that the tag is closed <w:font>using the tag, and the tag's attribute is a bit strange, and may be used to control the value of a certain address.</o:idmap><w:font>w:name
  
• Recompress the decompressed docxfile, and then use the registry to attach the debugger to prepare for debugging.
  
• After the attachment is completed, open the document containing the vulnerability and trigger an exception after running. The call [ecx+4]instruction is to use the virtual function table to call the virtual function, and ecxis the virtual function table pointer, which is wwlib.41249DA0returned by the function.
  
• View the stack call and find the module used to process XMLthe format msxml. The module assists in parsing the format msxmlby indirectly calling the module . For the time being, the function is designated as a vulnerable function.wwlibXMLwwlib.3161309E
  
• Record a breakpoint on the vulnerable function and check the log content. It is found that the vulnerable function has been called 6times. Based on document.xmlthe analysis of the tag elements in the file, the vulnerable function is most likely used to parse element tags. As for what is parsed, it is still unclear. .
  
  
• Select the lower conditional breakpoint of the last call to the vulnerable function espand analyze the vulnerability function processing flow.
  
• After the function is disconnected, it can be found from the parameters passed in that esiit may be a data structure that stores tag information.
  
• Step into this function, and the nesting relationship of the elements will be taken out at the position shown in the figure. At this time, <o:idmap>the label has been inserted w:fontafter the label (with ":"the symbol as the separator). The tag is <w:font>inserted when it is not closed <o:idmap>, indicating that the nested relationship has been incorrectly parsed.
  
• When debugging to the address , it was found that the function 0x31613084will be called. After analysis, it was found that the return value of the function is related to the virtual function table call at the exception, so enter this function to take a look.wwlib.31249DA0
  
• Through analysis, it is found that the function does some simple calculations for ecxand , the algorithm is , and the calculation result is ; and is passed in by and is equal to , so the algorithm becomes , controlled by the passed in . After subsequent analysis, it can be concluded that actually The nesting level of the current element.edx[[ecx]+8]*edx + [[ecx]+C] + [ecx]0x0751D140ecxesiedx[[esi]][[esi]+8]*([[esi]]-2) + [[esi]+C] + [esi]esi[[esi]]
  
• After the call is completed, the value of the address wwlib.31249DA0will be used as a virtual function table pointer to call the virtual function, thereby triggering an exception. [[0x0751D140+44]+44]As shown in the figure, it can be seen that [0x0751D140+44]the address is overwritten into the attribute <w:font>of the element w:name, so the attacker can call any address by modifying the attribute <w:font>of the tag .w:name
  
  
• Next, change the file in the sample document.xmland manually add </w:font>the closing tag to see if the exception will be triggered.
  
• Break at the vulnerable function, and the nesting level at this time is 5.
  
• Then wwlib.31249DA0calculate the virtual function call address as 0x075098F4. Since the nesting level is 5, the calculated result is F4( 4C*(5 - 2) + 10), and the previous one is 140( 4C*(6 - 2) + 10).
  
• The program did not trigger an exception after the virtual function was called.
  

\x04 Analyze msxml module processing steps

• In order to quickly understand the processing flow of the module, record breakpoints on msxmlall module functions in the call stack and view the logs.msxml
  
• It can be found from the log that the calls to the vulnerable functions are all implemented through the instructions sub_78887830in the function call [ebx+200], but the call to the penultimate vulnerable function does not go through call [ebx+200]and jumps directly to MSOthe module.
  
• Set a breakpoint on the penultimate vulnerable function. After disconnecting, we analyzed the stack calls and found that the instructions msxml.78887830in the function call [ecx+20]will also call the vulnerable function.
  
  
• In this case, the function call flow chart can be analyzed. The function call flow is shown in the figure below:
  
• Below is a brief analysis of the function chain calls under based on msxml.78887830the last call of the function .call [ebx+200]
  
  
• At msxml.78887830the beginning of the function, the element tag object will be stored in ebx. The element tag object stores the information of the currently parsed element, mainly the nesting relationship and nesting level of the element.
  
• After debugging downwards, I found that msxml.788872F7the function will obtain the pointer of the attribute character <w:font>of the element w:name.
  
• The following msxml.78887335function will obtain o:idmapthe pointer of the element character
  
• After obtaining o:idmapthe element character pointer, call msxml.788872F7the function to parse o:idmapthe element. You can see in the memory window that the character pointer has pointed to incerthe position, indicating that idmapthe tag has been parsed.
  
• After calling msxml.788873F0Calculate the nesting level of the element, you can see that the nesting level of the element is calculated as 6, but at this time the nesting level of the element is still 5, and has not been updated to 6.
  
• After [ebx+1e8]assigning to eax, a jump occurs, skipping call [ecx+20]the call to and proceeding to call [ebx+200]the call to .
  
  
  
• The function called is mso.32751CAA, in fact, MSOthe function call of the module does not have much effect, it just wwlibprovides indirect processing for subsequent modules.
  
• After reaching 0x32751D5Cthe position, execute call [ecx+20]the instruction to call sub_3277FAC0the function, at this time esi = [esi+60].
  
• Then the instruction call sub_3277FAC0will be executed in the function .call [eax+10]wwlib.3127D3FB
  
• After entering wwlib.3127D3FBthe function, continue debugging downwards. At this time, [[esi+b14]]the nesting relationship of the elements is stored in the address.
  
  
• After calling wwlib.3127E6B3the function, a judgment will be made, and if it ebxis equal to 0x80004001, it will jump.
  
• After the jump is completed, the vulnerable function is called. The following process has just been analyzed.
  
• Record breakpoints at several locations based on the results of the above debugging analysis. Looking at the log, you can find that msxml.78887830the function will parse the elements one by one. When <idmap>the tag is parsed, the nesting relationship is 5.
  
  
• However, the nesting relationship at the exception is . Set a breakpoint on 6the last function call to see when the nesting relationship changed .msxml.788878306
  
• After re-running, it will be disconnected. At this time, the nesting relationship is 5.
  
• When debugging to the position wwlib.3127D3FBin the function 0x3128E3AD, the nesting relationship changes 6, indicating that wwlib.312C6142the function has updated the nesting relationship.
  
• Then analyze w:namewhen the attributes are copied. Through the analysis of the vulnerability exception, it is found that w:namethe attributes are stored in the element object. By w:namewriting a breakpoint under the storage location of the element object, it is found that the function WWLIB.sub_3127D3FBwill be called in the wwlib.3127E773function and copied w:nameto the element object. After that, w:namethe attributes will be taken out and virtualized in the vulnerability function. Function table call.
  
  
  
• It should be noted that this jump is not implemented in the above analysis, which means that it w:namereturns directly after copying the attributes. It is judged that the value of the jump is wwlib.3127E6B3returned by , and after entering the function, it is found that at the end of the function, it will be 0x80004001assigned to eax. Before that, it will be called 0x3149BFA3as the base address and eax * 4as the offset address. Instead, eaxit will be [ebp-1c]passed in Yes, record a breakpoint at this location and check the log.
  
• According to the log, it can be found that the vulnerable function will be called only when [ebp+1c]the value of is 0xFFFF. And <w:font>it is called once before parsing the tag and <o:idmap>once after parsing the tag.
  
• Then <o:idmap>delete the tag and compare the log information.
  
• It can be found that <w:font>this value is only set before the tag is parsed 0xFFFF, so this value may be used to determine whether the element is closed.
  

\x05 Summary

• When msxml.78887830the function parses <w:font>the label, it will mistakenly think that the label has been closed, thereby adding <w:font>the label's w:nameattribute (if any) to the object, and at the same time updating the nesting relationship of the element (the nesting relationship becomes 6), resulting in the final use call [ecx+4]. When the virtual function table is called, the virtual table pointer is incorrectly overwritten into w:namethe data in the attribute, triggering an exception.
  
  

This concludes the vulnerability analysis of CVE-2017-11826 . If there are any errors, please correct them.