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

This article will explain in detail how to make an in-depth analysis of Microsoft Outlook vulnerabilities. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Words written in the front

MicrosoftOutlook is a component of Microsoft's Office suite that can be used to send and receive email, manage contacts, record and track schedules, or perform other tasks. Recently, researchers have discovered a heap crash vulnerability in Outlook 2010 to Outlook 2019 and Office 365ProPlus, which affects version 32 and 64 on the Windows platform. An attacker can use a malicious RWZ file to trigger this vulnerability. When Outlook receives the contents of a malicious RWZ file, it allocates only a small amount of heap memory and lacks proper boundary detection, resulting in out-of-bounds writing of heap memory.

Reproduce loophole

To replicate the vulnerability, we need to run Microsoft Outlook, then click "rules = > Administrative rules & Alerts = > options = > Import rules" to select the PoC file that can trigger the Outlook crash.

Here is the call to the stack in the event of a crash:

Analyze vulnerabilities

We can see from the stack call data that a program crash occurs when heap memory is freed. Because we can't tell what happens when the heap is released, we need to open the complete heap memory page table to track the data changes in the heap memory, as follows:

YOUR_WINDBG_INSATALL_LOCATION\ gflags.exe/p / enable outlook.exe / full

The results returned by the above command are as follows, indicating that the command has been executed successfully.

Next, we open Outlook again, select the PoC file, and monitor the new stack space when the crash occurs:

Now we can see that the non-zero memory address that ECX points to is unreadable, and an exception occurs when writing data to this memory address, most likely because the program is trying to write to an unallocated (or unfreed) memory address. We can verify this conjecture by checking the memory page allocation, and we will see that the memory still has the Reserve attribute:

Now we need to figure out why the program writes data to unused memory pages. Through static analysis, we can see that the value of ECX comes from EDI, while EDI seems to be modified after the program calls MAPIAllocateBuffer:

The results of the static analysis show that the MAPIAllocateBuffer function is actually an encapsulated function of RtlAllocateHeap, and this function ensures that the requested memory size parameter does not exceed 0x7FFFFFF7. However, it cannot detect whether the value of the parameter is 0 because the actual allocated heap size is 8 bytes, which exceeds the requested heap size, and the 8-byte fill value is 0x0000000001000010. Next, MAPIAllocateBuffer returns the heap address after these eight bytes. Therefore, after the call to MAPIAllocateBuffer, the value of EDI is the 8 + assigned heap address (from RtlAllocateHeap):

Based on the above static analysis results, we can roughly judge that the cause of the vulnerability is the integer overflow problem. After modulation, we find that the heap size parameter when MAPIAllocateBuffer is called is 0, because the heap size allocated by the MAPIAllocateBuffer request is 0-8-8, RtlAllocateHeap does not return an error, but returns the correct heap address. MAPIAllocateBuffer uses these 8 bytes to write the address 0x0000000001000010, and then returns the invalid memory address to the user:

Next, we need to figure out why the requested heap size value becomes 0. It turns out that the 0 value comes from a current function parameter: arg_4 (eax = arg_4 * 4 + 4). However, when this function is called, the value of arg_4 is not the parameter value passed in, which means that the value of arg_4 has been modified. After analysis, we find that the culprit is its subfunction sub_65F7DA:

After analyzing the subfunction sub_65F7DA, we find that it is also an encapsulated function. It turns out that this function is ReadFile, and the value of arg_4 actually comes from the PoC file:

The debugging results show that the content of the file read by arg_4 is 0xFFFFFFFF, so the allocated size of heap memory is 0xFFFFFFFF * 4 + 4 = 0 (integer overflow). However, the program does not detect this error, which eventually leads to an out-of-bounds write:

As we can see in the PoC file, the value 0xFFFFFFFF does not exist:

Change it to 0xAABBCCDD and debug it again, and we can confirm that the overflow is caused by these four bytes:

After installing the fix, we compared the program code before and after, and found that the patch added validation of the request allocation heap memory size:

Therefore, the majority of users please install the update patch as soon as possible to prevent attackers from exploiting this vulnerability.

Vulnerability information MS.Outlook.CVE-2018-8587.Remote.Code.Execution on how to share the in-depth analysis of Microsoft Outlook vulnerabilities here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.