Analyzing Microsoft Office Zero-Day Exploit CVE-2017-11826

McAfee Labs has performed frequent analyses of Office-related threats over the years: In 2015, we presented research on the Office OLE mechanism; in 2016 at the BlueHat conference, we looked at the high-level attack surface of Office; and this year at the SYSCAN360 Seattle conference, we presented deep research on the critical Office “Moniker” zero-day vulnerabilities.

This month, Microsoft released an update for an Office zero-day attack. We examined an in-the-wild sample, and with this post we share our findings to help others understand the threat.

The sample arrives as an RTF file, and embeds at least three objects (through the control word “\object”). This is a memory corruption vulnerability, so it needs additional steps to archive the full exploitation.

1. The first object, in the following figure, shows that it loads a COM object whose CLASSID is D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731.

If we look into the Windows registry, we see that the COM DLL C:\Windows\system32\msvbvm60.dll will be loaded. The purpose of loading this DLL is that msvbvm60.dll is not compatible with address space layout randomization (ASLR), thus it can be used to bypass ASLR and data execution prevention (DEP) on older Office versions. (We will explain later.) This is not a new trick; researcher Parvez Anwar described this process in 2015.

2. The second object is a .docx file that employs the ActiveX.bin technique to spray the heap, also not a new trick. McAfee Labs first identified this exploitation technique in a zero-day attack discovery in 2013; our colleague Debasish Mandal discussed this technique in one of his recent posts.

3. The third object is the cause of this vulnerability. It is an embedded .docx file. When this .docx is rendered, a memory corruption vulnerability is triggered. Specifically, we have identified the problem is due to mishandling of nested tags in the Office Open XML format. The key tags follow:

With help from the first and the second steps, an attacker can hijack the program’s control flow to a predictable address in msvbvm60.dll’s code by exploiting the memory corruption vulnerability. This is the classic step of “stack pivot” for defeating ASLR and DEP. (See the next figure.) Following the return-oriented programming chain and shellcode comes the main payload, which we will not discuss in this post.

This exploitation technique works only on older Office versions. Since Office 2013, Microsoft has employed the security feature Forced-ASLR. As its name suggests, the feature forces the randomization of a module’s loading address even if the DLL is not ASLR compatible. Thus this in-the-wild attack can work only on Office 2010 and older versions. Nonetheless, because the underlying vulnerability does affect newer versions of Office, we recommend that all Office users install the official patch as soon as possible.

For McAfee NSP customers, we have released signature 0x45219c00 (UDS-HTTP: Microsoft Office Memory Corruption Vulnerability (CVE-2017-11826)) to prevent this attack.

Thanks to my colleague Bing Sun for his help with the analysis.

Introducing McAfee+

Identity theft protection and privacy for your digital life

Download McAfee+ Now