β

From A Patched ITW 0day to Remote Code Execution (

奇虎360技术博客 13 阅读

Author:Yuki Chen of Qihoo 360 Vulcan Team

Background

In May 2018, the Advanced Threat Response Team of 360 Core Security Division detected an APT attack exploiting a 0-day vulnerability and captured the world’s first malicious office sample that uses a browser 0-day vulnerability.

The sample exploited a use-after-free vulnerability in the VBScript engine which was fixed by Microsoft as CVE-2018-8174 in May 2018 security update, the detailed analysis of the bug could be found at:

http://blogs.360.cn/blog/cve-2018-8174-en/

After analyzing the patch for CVE-2018-8174 carefully, we realized that the fix was not so complete and there still exists similar problems which could be leveraged to achieve reliable remote code execution in VBScript engine. We reported the issues we found to Microsoft immediately and Microsoft addressed them with a new fix (CVE-2018-8242) in July 2018 security update.

In this blog, we will introduce the details of the new exploitable issues with CVE-2018-8174 patch we found. We will also discuss how we exploit the new bug we found and get reliable remote code execution in an upcoming blog (part II).

The Original ITW 0day

Before starting to introduce the new bug, let’s have a quick look at the old bug first. The PoC for the original bug looks like this:

Here is how the poc works:

Set o = arr(0)

The Fix in May 2018 Security Patch

Microsoft’s fix for this bug was quite simple:

In oleaut32!VariantClear, if it is clearing a VT_DISPATCH (Object) variant, it will first set the type of the variant to VT_EMPTY before trigger the |Class_Terminate| callback, as shown below:

And the pseudo code of the patch looks like this:

if (variant is a dispatch object) {
variant.vt = VT_EMPTY;
Call VBScriptClass::Release which will call the class Terminate function.
}

Now with this patch, the original PoC won’t work anymore, because when you try to grab a reference to the element |arr(0)| in the callback function with the following statement in the poc:

Set o = arr(0)

You will get an empty variant because the variant’s type has already been set to VT_EMPTY, so the use after free will not happen.

Is the Patch Perfect?

Let’s consider the root cause of this vulnerability:

When we erase a SafeArray, it clears the elements in the array one by one. The problem is that we can still access the SafeArray when the elements are being cleared , by using the |Class_Terminate| callback.

Here “Access” a SafeArray means that we can:

1.Read elements from the array (which is leveraged in the original 0day poc)

2.Write elements to the array.

3.Modify the internal data of the array, including free the internal buffer of the array.

Now let’s get back to the patch: the patch prevents us from reading the element which is being cleared in the callback. It is easy to notice that this patch only (partially) prevents the first pattern but cannot address the other 2 patterns.

Let’s see whether we can find some new issues using that 2 patterns, after the CVE-2018-8174 patch.

Show Me New 0days

New Issue 1 – SafeArray Double Free

Let’s try pattern 3, to see what will happen if we try to delete the internal buffer of the SafeArray inside the |Class_Termiante| callback, with the new poc:

Here we slightly modified the original poc, tried to erase the array again inside the |Class_Terminate| callback, and to our surprise the new poc crashed immediately:

(14c8.258): Break instruction exception – code 80000003 (!!! second chance !!!)

eax=00000000 ebx=00000000 ecx=000014c8 edx=00000000 esi=65789d80 edi=00000000

eip=6578cd6f esp=0727ca14 ebp=0727ca38 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

verifier!VerifierStopMessage+0x27f:

6578cd6f 837df800        cmp     dword ptr [ebp-8],0  ss:0023:0727ca30=00000000

0:006> k

ChildEBP RetAddr

WARNING: Stack unwind information not available. Following frames may be wrong.

0727ca38 6578ab0c verifier!VerifierStopMessage+0x27f

0727ca9c 6578794d verifier!VerifierDisableFaultInjectionExclusionRange+0x414c

0727cb00 65787aa5 verifier!VerifierDisableFaultInjectionExclusionRange+0xf8d

0727cb24 65787d30 verifier!VerifierDisableFaultInjectionExclusionRange+0x10e5

0727cb40 65789e10 verifier!VerifierDisableFaultInjectionExclusionRange+0x1370

0727cb5c 779616d9 verifier!VerifierDisableFaultInjectionExclusionRange+0x3450

0727cbbc 778b8c0a ntdll!RtlpNtSetValueKey+0x3089

0727ccc0 778b64b8 ntdll!RtlFreeHeap+0x2eaa

0727cd10 7553d83b ntdll!RtlFreeHeap+0x758

0727cd24 753cc819 combase!CoCreateFreeThreadedMarshaler+0x1362b

0727cd40 753cc8a4 OLEAUT32!_SafeArrayFreeData+0x34

0727cd4c 753ccb52 OLEAUT32!_SafeArrayReleaseDescriptor+0x38

0727cd5c 5e02f348 OLEAUT32!SafeArrayReleaseDescriptor+0x12

0727cd68 5e034c1e vbscript!AutoVariantRef::ArrayPinnableData::Unpin+0x21

0727cd6c 5e034c12 vbscript!VbsErase+0xee

0727cda8 5dfec837 vbscript!VbsErase+0xe2

You can see that the verifier detected a critical error when calling RtlFreeHeap to free a heap block, which usually indicates a potential heap corruption. Notice that the problem is triggered with |VbsErase| in the callstack.

Let’s check the heap block being freed which triggered the verifier warning:

address 041b4fd8 found in

_DPH_HEAP_ROOT @ 701000

in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)

40b3f08:          41b4000             2000

65789e42 verifier!VerifierDisableFaultInjectionExclusionRange+0x00003482

779616d9 ntdll!RtlpNtSetValueKey+0x00003089

778b8c0a ntdll!RtlFreeHeap+0x00002eaa

778b64b8 ntdll!RtlFreeHeap+0x00000758

7553d83b combase!CoCreateFreeThreadedMarshaler+0x0001362b

753cc819 OLEAUT32!_SafeArrayFreeData+0x00000034

753cc8a4 OLEAUT32!_SafeArrayReleaseDescriptor+0x00000038

753ccb52 OLEAUT32!SafeArrayReleaseDescriptor+0x00000012

753741f7 OLEAUT32!SafeArrayDestroyDescriptor+0x00000087

5e034be6 vbscript!VbsErase+0x000000b6

You can see that the heap block passed to |RtlFreeHeap| had already been freed earlier, in another call to VbsErase.

Now it’s quite clear that it is a double free vulnerability. In our poc, when the first call to VbsErase tries to free the memory of the SafeArray descriptor, it has already been freed unexpectedly by the second call to VbsErase in our |Class_Terminator| callback.

The double free vulnerability itself is quite simple, however it requires some technique to exploit it. I will have some further discuss on this vulnerability including some detailed analysis and how to write a poc exploit for it, in a next blog. You can try to write a poc exploit by yourself if you are interested in it.

New Issue 2: Object Use After Free Caused by Reference Count Overflow

Now we have a new double free vulnerability. But We didn’t want to just stop here and got to have a rest, our brain storm continued.

So how about the pattern 2? Can we make some trouble by writing elements to the SafeArray inside the |Class_Terminate| callback?

The answer is yes. The problem is not so obvious: we just write some elements to a SafeArray whose memory is going to be freed, we are not writing out of the bounds of the array; we are not writing to already freed memory. Seems no big deal?

However, consider the following situation:

  1. We have a SafeArray with 2 elements.
  2. We call erase on the SafeArray.
  3. The elements in the SafeArray will be cleared one by one, it will first clear arr(0), and then clear arr(1)
  4. When clearing arr(1), we can trigger a |Class_Terminate| callback. And inside the callback, we store an object to arr(0) like this:
    Set arr(0) = SomeObject
    In VBScript, store an object into a SafeArray will increase the reference count of that object, so we get SomeObject.ref_cnt += 1. The reference count of the object will be decremented by 1 when we clear the object from the array, in normal case.
  5. Now after arr(1) is cleared, all elements in the SafeArray have been cleared. It will not go back to clear arr(0) because arr(0) has already been cleared before clearing arr(1). Next it will directly free the memory of the internal SafeArray buffer.
  6. So SomeObject.ref_cnt will not get decremented. It will cause a reference count leak on the object.
  7. The reference count of a VBScript object is 32-bits. By triggering the ref count leak for multiple times, we can finally overflow the 32-bits ref count and the ref count will become very small. Then we can free the object by clearing a few references to it, while we still have many references pointing to that object. This means with this vulnerability, we can create a dangling pointer to an already freed vbscript object and access the freed object at any time we want, which is quite easy to exploit.

The full poc is shown below:

The above PoC took ~10 minutes to crash on my test machine. It crashes when trying to access an already-freed object in oleaut32!VariantClear:

(58.1154): Access violation – code c0000005 (!!! second chance !!!)

eax=00000000 ebx=071cd010 ecx=0e9d2fc0 edx=04000000 esi=00000000 edi=00000009

eip=7537bbce esp=071ccfc0 ebp=071ccfe0 iopl=0         nv up ei pl nz na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

OLEAUT32!VariantClear+0xfe:

7537bbce 8b01            mov     eax,dword ptr [ecx]  ds:0023:0e9d2fc0=????????

address 0e9d2fc0 found in

_DPH_HEAP_ROOT @ 3fb1000

in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)

dab3fa4:          e9d2000             2000

65789e42 verifier!VerifierDisableFaultInjectionExclusionRange+0x00003482

779616d9 ntdll!RtlpNtSetValueKey+0x00003089

778b8c0a ntdll!RtlFreeHeap+0x00002eaa

778b64b8 ntdll!RtlFreeHeap+0x00000758

752d77c5 msvcrt!free+0x00000065

5f430619 vbscript!VBScriptClass::`scalar deleting destructor’+0x00000019

5f476fca vbscript!VBScriptClass::CheckDelete+0x00000028

7537bbb9 OLEAUT32!VariantClear+0x000000e9

60db19e2 IEShims!IEShims_SetRedirectRegistryForThread+0x00005472

5f43224e vbscript!AssignVar+0x0000013e

The Fix in July Security Patch

We reported the 2 new vulnerabilities to Microsoft and they addressed them in a single CVE (CVE-2018-8242) in July security update.

Quick analysis shows that this time they fixed the new issues like this:

Now for VBScript operations which will free a SafeArray’s internal buffer (erase, redim), before clearing elements in the array, it will first set the internal SafeArray descriptor to null. After this fix, you will not be able to access (read/write/free) the SafeArray inside the |Class_Terminate| again because the descriptor has already been cleared when the callback is invoked.

This patch perfectly fixed the new issues we reported.

BTW, it is not a security issue but, have you noticed that the above patch introduced a resource (memory) leak problem? Try to figure it out :)

Some thoughts

This case is an interesting adventure for me. Analyzing the poc/patch – thinking – finding a new way to crash – pop a calc, each step brings me a lot of fun.

What I learned (again) from this case is that security patch analysis is very important for a bug hunter. I have seen many cases that a security patch failed to address all the possible paths of a vulnerability and we can still find some way to trigger the vulnerability after the patch. And I have also seen cases that a security patch can expose new attack surfaces or introduced new bugs directly into the software. And I think maybe both developers and security researchers should spend more time on security patches.

作者:奇虎360技术博客
分享奇虎360公司的技术,与安全的互联网共同成长。
原文地址:From A Patched ITW 0day to Remote Code Execution (, 感谢原作者分享。

发表评论