CVE-2016-0018: DLL Planting Leads to a Remote Code Execution Vulnerability

By on

DLL planting, also known as DLL side loading, is a popular attack technique today. If we take a look at the list of advisories Microsoft has recently published, it is clear that a large number of vulnerabilities encompass DLL planting. We have seen many targeted attacks that abuse Windows OLE in many ways. At BlackHat USA 2015, an McAfee team presented the paper “Attacking Interoperability: an OLE Edition,” which covered various attack techniques and attack surfaces of OLE. In this paper, my colleagues Bing Sun and Haifei Li showcased many interesting vulnerabilities in OLE.

Recently we informed Microsoft of a vulnerability that can be exploited by attackers to perform a DLL side-loading attack. In this case, the vulnerable COM class object ID (CLSID) is {f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}. This CLSID can be found in the registry at HKEY_CLASSES_ROOT\CLSID\{f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}. This CLSID’s InprocServer32 key points to the file invagent.dll. A quick Google search reveals this DLL is a part of Windows and is covered by the update KB2976978.

CVE_02016_0018_A_Tale_of_a_windows_library_loading

During our research we found that it is possible to load and initialize this COM object with specially crafted Office document. As proof of concept, we created a Word document with an embedded external OLE object. Opening our Word doc in Office, we see this:

CVE_02016_0018_A_Tale_of_a_windows_library_loading_2

Later we simply patched and changed the CLSID to {f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_3

Now if we double-click the embedded icon, Office tries to load the OLE object and associated DLLs into the process. One of the DLLs Office tries to load is api-ms-win-core-winrt-l1-1-0.dll. We noticed that if we placed a DLL named api-ms-win-core-winrt-l1-1-0.dll in the same location as the crafted doc, Office simply loads the DLL from the current working directory, allowing us to execute arbitrary code through a planted fake DLL. In Process Monitor, below, we can see that the DLL is loaded from the current working directory.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_4

To prove our point, we compiled a fake api-ms-win-core-winrt-l1-1-0.dll in which DLLMain() executes calc.exe and was placed that DLL in the same folder with the crafted Word doc. As we see in the following screen, as soon as we click on the embedded doc icon, calc.exe pops up.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_5

This same attack can also be performed with a specially crafted rich text format (RTF) document. What’s interesting about an RTF attack is that no user interaction (such as a mouse click) is required to achieve code execution.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_6

The next screen shows the stack trace of the vulnerable LoadLibraryEx() call. As we can see the OLE initialization process started from a call to ole32!OleLoad() -> ole32!CoCreateInstance() and goes on from there.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_7

The next screen shows the disassembly of the vulnerable function invagent!AeInvProvider::AeInvProvider(), in which the insecure library load happens.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_8

Microsoft pushed out a fix for this bug in January, as part of MS16-007 (https://support.microsoft.com/en-us/kb/2952664). As a fix, the dwFlags parameter of the LoadLibraryEx() function was set to 0x800. With this value, only the %windows%\system32 path is searched for the DLLs. The following screen shows the patched function after installing this fix.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_9

For a video demonstration of this attack, click here.

Disclosure time line:
January 8: McAfee reports the issue to Microsoft.
January 9: Automated response from Microsoft.
February 27: Microsoft confirms the issue and informs us a fix was part of Security Bulletin MS16-007 (January’s Patch Tuesday update).
April 21: Microsoft publicly acknowledges our report.

Categories: McAfee Labs
Tags: ,

Leave a Comment

Similar articles

While you might have been preoccupied with ghosts and goblins on Halloween night, a different kind of spook began haunting Google Chrome browsers. On October 31st, Google Chrome engineers issued an urgent announcement for the browser across platforms due to two zero-day security vulnerabilities, one of which is being actively exploited in the wild (CVE-2019-13720). ...
Read Blog
Fears and phobias. We all have them. But what are your biggest ones? I absolutely detest snakes but spiders don’t worry me at all. Well, new research by McAfee shows that cybercriminals and the fear of being hacked are now the 5th greatest fear among Aussies. With news of data breaches and hacking crusades filling ...
Read Blog