Vulnerability Analysis of CVE-2016-0059 IE information leakage

Vulnerability Analysis of CVE-2016-0059 IE information leakage
0x00 Summary

This article will carry on the deep analysis to the CVE-2016-0059, this vulnerability is caused by the Microsoft Hyperlink Object Library memory data leakage, the successful use of this vulnerability can obtain some information to cause further threats to the user system. To exploit this vulnerability, attackers must induce users to click a hyperlink in an email or in an office document.

At first, I used this vulnerability as Microsoft Office Excel? A heap overflow vulnerability is reported to Microsoft. But is this vulnerability actually caused? Internet Explorer Object Library? Hlink. dll (Microsoft Hyperlink Object Library )? So Microsoft defines this vulnerability? Internet Explorer Information Leakage vulnerability. This article uses Microsoft Office to prove and analyze the vulnerability.

Affected products:

IE 9IE 10IE 11 (including win10) 0x01 vulnerability Verification

Can we use this vulnerability to reproduce it? Microsoft Office Excel 2007 Open the POC FG-VD-15-073_PoC.xls. Then we can see that excel.exe crashes. The crash information is shown as follows:

#!bash(3344.1804): Access violation - code c0000005 (first chance)First chance exceptions are reported before any exception handling.This exception may be expected and handled.eax=1a06d0d0 ebx=00000002 ecx=18b22fea edx=00000001 esi=18b23000 edi=18b22fe8eip=6cd40b40 esp=00b739b4 ebp=00b739c4 iopl=0 ? ? ? ? nv up ei ng nz na po nccs=0023 ?ss=002b ?ds=002b ?es=002b ?fs=0053 ?gs=002b ? ? ? ? ? ? efl=00010282hlink!WzDupWzToWz+0x16:6cd40b40 668b06 ? ? ? ? ?mov ? ? ax,word ptr [esi] ? ? ? ?ds:002b:18b23000=????0:000> uhlink!WzDupWzToWz+0x16:6cd40b40 668b06 ? ? ? ? ?mov ? ? ax,word ptr [esi]6cd40b43 03f3 ? ? ? ? ? ?add ? ? esi,ebx6cd40b45 6685c0 ? ? ? ? ?test ? ?ax,ax6cd40b48 75f6 ? ? ? ? ? ?jne ? ? hlink!WzDupWzToWz+0x16 (6cd40b40)6cd40b4a 2bf1 ? ? ? ? ? ?sub ? ? esi,ecx6cd40b4c d1fe ? ? ? ? ? ?sar ? ? esi,16cd40b4e 8d5e01 ? ? ? ? ?lea ? ? ebx,[esi+1]6cd40b51 85d2 ? ? ? ? ? ?test ? ?edx,edx0:000> !heap -p -a esi? ? address 18b23000 found in? ? _DPH_HEAP_ROOT @ 5601000? ? in busy allocation ( ?DPH_HEAP_BLOCK: ? ? ? ? UserAddr ? ? ? ? UserSize - ? ? ? ? VirtAddr ? ? ? ? VirtSize)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1a173a5c: ? ? ? ? 18b22fe8 ? ? ? ? ? ? ? 16 - ? ? ? ? 18b22000 ? ? ? ? ? ? 2000? ? 5e6d9abc verifier!AVrfDebugPageHeapAllocate+0x0000023c? ? 77c97ab1 ntdll!RtlDebugAllocateHeap+0x0000003c? ? 77c4ba4e ntdll!RtlpAllocateHeap+0x0004cfde? ? 77bfdc26 ntdll!RtlpAllocateHeapInternal+0x00000146? ? 77bfdab8 ntdll!RtlAllocateHeap+0x00000028? ? 770f32e6 combase!CRetailMalloc_Alloc+0x00000016 [d:thcomcombaseclassmemapi.cxx @ 641]? ? 6cd337fd hlink!CMalloc::Alloc+0x0000002d? ? 6cd40c32 hlink!operator new+0x00000023? ? 6cd3d50e hlink!HrReadLengthWzStm+0x00000034? ? 6cd39b2c hlink!HLNK_PersistStm::Load+0x0000010c*** ERROR: Symbol file could not be found. ?Defaulted to export symbols for C:Program Files (x86)Common FilesMicrosoft Sharedoffice12mso.dll -?? ? 3280dc07 mso!Ordinal2575+0x00000320? ? 3280dac1 mso!Ordinal2575+0x000001da? ? 3280da7a mso!Ordinal2575+0x00000193*** ERROR: Symbol file could not be found. ?Defaulted to export symbols for C:Program Files (x86)Microsoft OfficeOffice12oart.dll -?? ? 3a99fb87 oart!Ordinal5476+0x000007090:000> dp 18b22fe8 ? ? ? ? ? ? ??18b22fe8 ?00720041 00610072 00440079 006d007518b22ff8 ?00320070 d0d0d000 ???????? ????????18b23008 ????????? ???????? ???????? ????????18b23018 ????????? ???????? ???????? ????????18b23028 ????????? ???????? ???????? ????????18b23038 ????????? ???????? ???????? ????????18b23048 ????????? ???????? ???????? ????????18b23058 ????????? ???????? ???????? ????????0:000> kb?# ChildEBP RetAddr ?Args to Child ? ? ? ? ? ? ?00 00b739c4 6cd3590d 00000000 00b73a88 00b73a1c hlink!WzDupWzToWz+0x1601 00b739e0 6cd331cf 1a068f28 00000000 00b73a1c hlink!CExtensionService::Release+0x105d02 00b73a28 3280da8e 1a068f28 00000000 00b73a88 hlink!HLNK::GetStringReference+0x5fWARNING: Stack unwind information not available. Following frames may be wrong.03 00b73a58 3a99fb87 08f74fd0 00000000 00b73a88 mso!Ordinal2575+0x1a704 00b73d70 77bf6d70 77cc74a8 19cd6ff0 00000000 oart!Ordinal5476+0x70905 00b73d98 77c91c3a 000df3e0 00000060 14b90fa0 ntdll!RtlpPopEntrySListLockedAlt+0x2006 00b73de8 32c8de4f 32195748 2fc48b8c 00000000 ntdll!RtlpStdLockRelease+0x1407 00b73dec 32195748 2fc48b8c 00000000 00000000 mso!Ordinal1743+0x2f4308 00b73df0 2fc48b8c 00000000 00000000 00000000 mso!MsoPvAllocCore+0x3609 00b73df4 00000000 00000000 00000000 00b73c90 Excel!Ordinal40+0x108b8c

0x02 Vulnerability Analysis

The missing ending identifier of the input string causes memory data other than the string to be read during string reading, which leads to the vulnerability. This vulnerability occurs in hlink! WzDupWzToWz ()? This vulnerability is exploited to cause information leakage.

First, let's take a look at this special XLS file. The offset 0x66C and 0x140DC are different. The POC file and the normal file are compared in these two places.

Figure 1 Comparison of normal files and POC files at 0x66c offset

Figure 2 Comparison between normal files and POC files at the offset 0x140dc

Then we use the Offvis tool to parse the POC file.

Figure 3 POC file 0x66c resolution

Figure 4 POC file 0x140dc resolution

As shown in figure 3, 0x66C corresponds to the ModifyTime domain. In fact, it does not cause a vulnerability. We ignore it here. Figure 4 shows that the byte D0 at 0x140dc corresponds to the complexData field. In addition, complexData is part of the fopt (OfficeArtRGFOPTE) structure. The OfficeArtRGFOPTE structure is defined by Microsoft:

Figure 5 OfficeArtRGFOPTE Structure

From the above definition, we cannot see that the complexData domain contains a specific structure.

Then we set the breakpoint in windbg as follows:

#!bashbu hlink!HLNK::GetMonikerReference " .printf "GetMonikerReference:\n"; db poi(poi(esp+4)+0x4c);"

After the breakpoint is broken several times, you will see the following debugging information:

The preceding debugging information shows that the heap buffer 0x16c52fe8 contains part of the complexData field. It points to a wide byte string without an ending sign.

Below is the hlink! HLNK: some code of the GetMonikerReference function. is it called? Hlink! WzDupWzToWz ()? Function to process this wide byte string.

Yes for the function hlink! WzDupWzToWz () Analysis

Figure 6 hlink! WzDupWzToWz () function analysis

In general, this problem is caused by the fact that when reading the input string, the string does not end with an identifier, and thus the data outside the memory of the string is read. What is the process? Hlink! WzDupWzToWz ()? This occurs when the function is used to copy strings.

When the library file hlink. dll is used to process the hyperlink object. You can create a hyperlink to construct the POC file as follows:

Figure 7 create a hyperlink in the XLS file

We save it? Test.xls, and then use? The Offvis Parsing is as follows:

Figure 8 new EXCEL File Parsing

We can clearly see that the hyperlink we created is stored in the HLink? The HLink structure is defined by Microsoft as follows:

The Hyperlink Structure is defined as follows:

According to the above definition, we can infer the data structure of the complexData domain by comparing with the HLink structure. The HLink structure in test.xls is as follows:

It is inferred that the internal structure of the complexData domain data is as follows (Note: 00 D0 in the red box, which may be 00 00 ):

We modify the hyperlinkBitFields field value? | 08 00 00 00 | ?, Modify the string terminator of the HyperlinkString field to NULL? | 00 D0 |?

After the vulnerability is saved and tested in WIN7 and WIN10, The vulnerability can be triggered. In WIN10:

As shown in, open the modified test.xls. You can see that hlink. dll is not loaded. Click the hyperlink "test". At this time, hlink. dll is loaded and the vulnerability is triggered,