Shulou(Shulou.com)05/31 Report--

This article will explain in detail the principle analysis, utilization and protection scheme of the second generation of Office formula editor vulnerabilities. The content of the article is of high quality. Therefore, Xiaobian shares it with you as a reference. I hope that after reading this article, you will have a certain understanding of relevant knowledge.

In a Microsoft Routine Update dated January 9, 2018, Microsoft again patched multiple memory corruption vulnerabilities in Formula Editor 3.0 in Office and classified the vulnerabilities as CVE-2018-0802.

After the vulnerability was disclosed, the Golden Eye security research team followed up on the vulnerability related security incidents in a timely manner.

Vulnerability Impact Version:

Office 365

Microsoft Office 2000

Microsoft Office 2003

Microsoft Office 2007 Service Pack 3

Microsoft Office 2010 Service Pack 2

Microsoft Office 2013 Service Pack 1

Microsoft Office 2016

Vulnerability Event Analysis:

There are currently two known ways to trigger vulnerabilities.

One of them, proposed by researchers at domestic security companies, exploits the FONT record parsing vulnerability of the formula, which is closer to the previous CVE-2017-11882 vulnerability. There are already wild samples of exploitation in this way, and since the new exploitation method will cause crashes on machines without CVE-2017-11882 patch, it needs to be used together with the previous exploit formula.

Another proposed by researchers at foreign security companies uses a MATRIX record of the formula (mistaken for SIZE record in the original report) to parse vulnerabilities to cause stack overflow. No samples have been found using this approach. Since this bypass of the ASLR mechanism requires brute force enumeration, it can lead to extremely long opening times for documents.

Since the former report is very detailed and the principle is close to CVE-2017-11882, this article will mainly analyze the latter.

Vulnerability details analysis:

In a patch (0x4164FA) for CVE-2017-11882, the patch code fixes stack overflow by adding extra parameters (number of copies) and adding predicate and truncation statements.

The code before and after patching is shown below:

Figure 1 -Comparison of code before and after patching

However, the problem is in this repair method, because there are many code using similar reading methods, it is inevitable that there will be fish missing. By looking at XREF of GetByte function (0x416352), you can find another ReadData function (0x443F6C) that may produce out-of-bounds copies.

Figure 2 -Vulnerable ReadData function

The value of the actual copied data size (real_size) is calculated from the passed parameter (size), but this passed parameter is controllable data in the formula. Therefore, changing this value to a larger value will overwrite subsequent data on the stack.

The ReadData function is called in the 0x443E34 function, and going up XREF finds that the function is only mentioned at address 0x454F50. Looking up, you can see a struct at 0x454F30, and by reversing this part, you can get the following (see http://rtf2latex2e.sourceforge.net/MTEF3.html).

Figure 3 -Functions that parse TAG

The structure at 0x454 F30 corresponds to case 4, the MATRIX record. The structure of MATRIX records can be found by consulting as follows:

Offset (in bytes) Field Name Description-1(already read)TAG Low 4 bits are 0101(i.e. 5) High 4 bits are optional flags The "[nudge]if xflMOVE is set" mentioned in the document is also in this field 0valign specifies the alignment 1h_just2v_just3rows matrix rows and columns This value is not checked, so stack overflow occurs 4cols5row_parts matrix row data and column data type col_parts…lines matrix row data and column data

Since ProcessMatrixRecord(0x443E34) function does not check the values of rows and cols, the actual copied data size can be calculated by real_size = (2 * size + 9) / 8.

Through actual debugging, you can get the memory layout on the stack as follows:

EBP - 0x14row_dataEBP -0x10 EBP - 0x0CCol_dataEBP -0x08 EBP -0x04 EBPEBP +0x04 Return Address

Specify 0x1C (28) for rows, which actually copies (2 * 28 + 9) / 8 = 8 bytes, and then specify a larger value for cols (0x94 in this case, which copies 38 bytes) to overwrite the original contents of the stack.

Assuming that the base address is 0x400000, first cover the stack with certain data, and the result is as follows.

Figure 4 -Status of registers at ret

Figure 5 -Address pointed to by EAX register at ret

When the ret statement is executed, the address pointed to by the EAX register differs by 0x32 bytes from the controllable input data in the sample. An attacker can execute arbitrary commands by constructing a ROP chain that elevates the value of the EAX register. Check Point gives the following idea:

Figure 6 - ROP chain construction ideas

The general idea is to raise the value of the EAX register twice (0x32/ 2 = 0x19) and then use its value as a parameter to WinExec.

An address value of 0x455 B28 appears in the middle. The reason starts with the function ProcessMatrixRecord(0x443E34) that handles MATRIX records.

Figure 7 -Function parsing MATRIX records (ProcessMatrixRecord, 0x443E34)

In line 26 of the figure above, you can see the call to the sub_4428F0 function, which has a read and write operation on a1(ebp+8)(the data is an address), and after ReadData, the data we constructed has overwritten this memory, destroying the original data. Therefore, we should at least ensure that these four bytes of data are a readable address.

Since Microsoft has forced ASLR to be turned on in the CVE-2017-11882 patch, this mechanism still needs to be bypassed for exploit to work. This approach takes advantage of a Word feature: When the Formula Editor generates an exception, Word takes over the exception without giving any information. EQNEDT32.exe is a 32-bit process, and the base address corresponding to the ASLR space is still in the range that can be enumerated-by constructing a large number of formulas, ROP chains using different base addresses can bypass the ASLR mechanism.

But in Check Point's POC demo video, it can be found that Word's loading window has not disappeared, that is, Word has been trying to load RTF files, and the calculator is popped up in the process. The POC that I tried to construct based on this method was 3MB in size and took several minutes to trigger. In actual attack samples, samples using this overflow method may need other ways to bypass the ASLR mechanism.

Solution: 1. Download the latest Microsoft patch

(1) https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802

(2)Turn on Windows automatic updates. Microsoft has removed this module from the latest version Microsoft has removed EQNEDT32.EXE from the product and no longer supports the old formula format.

2. Unregister the module in the registry reg add "HKLM\SOFTWARE\Microsoft\Office\Common\COM Compatibility\{0002CE02-0000-0000-C000- 000000046}" /v "Compatibility Flags" /t REG_DWORD /d 0x400

For 32-bit Office on 64-bit operating systems, do the following

reg add "HKLM\SOLUTWARE\Wow6432Node\Microsoft\Office\Common\COM Compatibility\{0002CE02-0000-0000-C000- 000000046}" /v "Compatibility Flags" /t REG_DWORD /d 0x400 About Office Formula Editor Vulnerability II Principle Analysis, Exploitation and Protection Scheme is how to share here, I hope the above content can be of some help to everyone, You can learn more. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.