{"id":48979,"date":"2016-04-14T14:45:11","date_gmt":"2016-04-14T21:45:11","guid":{"rendered":"https:\/\/blogs.mcafee.com\/?p=48979"},"modified":"2025-05-29T03:11:58","modified_gmt":"2025-05-29T10:11:58","slug":"cve-2016-0153-microsoft-patches-possible-ole-typo","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/cve-2016-0153-microsoft-patches-possible-ole-typo\/","title":{"rendered":"CVE-2016-0153: Microsoft Patches Possible OLE Typo"},"content":{"rendered":"

Recently McAfee Labs discovered an interesting bug in Windows\u2019 OLE implementation, which Microsoft patched this week. Now that the patch is available, we can discuss this vulnerability, which resides in the OleRegEnumVerbs() function of ole32.dll.<\/p>\n

During our research we found that a stack corruption vulnerability in ole32!OleRegEnumVerbs can be triggered if we embed any OLE1 object into an Office document and try to load it. Whether a class identifier (CLSID) represents an OLE1 class can be determined from the registry.<\/p>\n

\"20160414<\/p>\n

As we see in the registry editor, HKEY_CLASSES_ROOT\\CLSID\\{00030000-0000-0000-C000-000000000046} represents an OLE1 object. Hence this CLSID can be used to trigger the bug.<\/p>\n

This CLSID was embedded in a Word document. We observed the app crash when an attempt was made to load that OLE object. The stack trace on Windows 8.1 appeared like this:<\/p>\n

\"20160414<\/p>\n

Using windbg we can see the crash occurred inside the OleRegEnumVerbs() function with the exception code STATUS_STACK_BUFFER_OVERRUN. From this exception code, we can tell this is a stack corruption.<\/p>\n

To find the root cause, we took a look at the disassembly of OleRegEnumVerb(). The first thing we see is a call to the CoIsOle1Class() function and the CLSID being passed to it.<\/p>\n

\"20160414<\/p>\n

According to the Microsoft Developer Network, the CoIsOle1Class() function verifies whether the CLSID passed to it represents an OLE1 object. In this case the CSID we feed into this function does represent an OLE1 object, so the program reaches the following code:<\/p>\n

\"20160414<\/p>\n

Here we see two calls: ProgIDFromCLSID() and StringCchCopyExW(). In this scenario we are interested in the StringCchCopyExW() call. The developer network tell us the StringCchCopyExW() function basically copies one string to another.<\/p>\n

Ret_value = StringCchCopyExW(szKey, 0x100u, psz, &pwszBase, &cchRemain, 0);<\/p>\n

In the preceding call:<\/p>\n

szKey is the destination buffer<\/p>\n

0x100 is the size of the destination buffer<\/p>\n

psz is the source string (RegionUsageHeap)<\/p>\n

pwszBase is the address of a pointer to the end of szKey<\/p>\n

cchRemain is the number of unused characters in szKey<\/p>\n

After this call succeeds, the program reaches following code, which is where the bug lies:<\/p>\n

\"20160414<\/p>\n

As we see, the code subtracts psz from pwszBase. Here pwszBase belongs to the stack, and psz belongs to the heap. Thus the value of pwszBase will less than psz, and the subtraction result (saved into ebx) becomes negative. At runtime, we can see value of ebx becomes 0xf9d93e2c, which points to kernel land.<\/p>\n

0:000>? 0x002d9844 – 0x06545a18<\/p>\n

Evaluate expression: -103203284 = 0xf9d93e2c<\/p>\n

This bug occurs most likely because the developer made a typo. The developer\u2019s intention probably was ebx = pwszBase \u2013 szKey, instead of ebx = pwszBase \u2013 psz.<\/p>\n

Later we see another call to OpenClassesRootKeyExW().If the call is successful, the program tries dereference the corrupted pointer in the stack and write 0x00 there. Thus we see the host application crash.<\/p>\n

\"20160414<\/p>\n

Under certain circumstance, when the exploit attempt is combined with other vulnerabilities, this flaw can lead to remote code execution.<\/p>\n

Vulnerability disclosure timeline<\/strong><\/h2>\n