IE SafeMode Bypass
Sunday, November 16, 2014 | Author: Deep Flash
Recently, there was a vulnerability (CVE-2014-6332) disclosed in OLE component of Windows Operating System which could be used to exploit Browser Applications like MSIE. The vulnerability in OLE SafeArray Resizing allows one to do arbitrary read/write in the memory address space of the process. While this vulnerability alone cannot be used to exploit an application and gain code execution. It gets even more interesting when combined with the IE SafeMode bypass.

Often referred to as "God Mode", this technique was first documented by yuange (https://twitter.com/yuange75). He explained how one could execute any system code using only VBScript embedded in an HTML page. To be more specific, the SafeMode setting in Internet Explorer prevents system code to be run using VBScript. So if an attacker can disable the SafeMode setting in Internet Explorer, they will directly get remote code execution on the machine.

To see this in more detail, let us attach windbg with Internet Explorer. We would also need to load a web page in Internet Explorer which would trigger it to load vbscript.dll. So, we use the below code snippet as an example:



This HTML page will attempt to execute calc.exe on the machine using only VBScript. However, MSIE SafeMode would prevent this.

I will use Win XP SP3 and MSIE 6 to check the SafeMode settings in VBScript. After attaching MSIE with windbg, we see that vbscript.dll is not loaded by default. So, let us set a breakpoint on module load for vbscript.dll.

0:000> sxe ld vbscript.dll

Now, run MSIE with windbg attached.

Load the above HTML page. We now break into the debugger. Let us view the assembly code specific to the function: COleScript::InSafeMode

The disassembly is as shown below:

0:000> u vbscript!COleScript::InSafeMode
vbscript!COleScript::InSafeMode:
7330624b 8b8174010000    mov     eax,dword ptr [ecx+174h]
73306251 83e00b          and     eax,0Bh
73306254 f6d8            neg     al
73306256 1bc0            sbb     eax,eax
73306258 f7d8            neg     eax
7330625a c3              ret
7330625b 90              nop
vbscript!DexCaller::`vftable':
7330625c a84c            test    al,4Ch

Let us set a breakpoint at InSafeMode() function and run the application:

0:000> bp 7330624b

0:000> g
Breakpoint 0 hit
eax=7755620d ebx=00000000 ecx=0003be90 edx=7c97b178 esi=0003ab80 edi=00000000
eip=7330624b esp=0013e1cc ebp=0013e254 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
vbscript!COleScript::InSafeMode:
7330624b 8b8174010000    mov     eax,dword ptr [ecx+174h] ds:0023:0003c004=0000000e

We now hit the breakpoint.

The value at address referenced by ecx+0x174 is 0xe

It has been documented already on Internet that the default value of SafeMode flag is 0xe. To disable the safe mode, we need to set this value to 0x0

Let us modify the value at address: 0x0003c004 in memory. We can run the following windbg command for that:

0:000> ed 0003c004 0;g
Breakpoint 0 hit
eax=00000001 ebx=00000000 ecx=0003be90 edx=0013e180 esi=00000000 edi=00000000
eip=7330624b esp=0013e1cc ebp=0013e254 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
vbscript!COleScript::InSafeMode:
7330624b 8b8174010000    mov     eax,dword ptr [ecx+174h] ds:0023:0003c004=00000000

Now, let us run the application and we can see that calculator was started successfully.

However, in this case, we have manually modified the value of SafeMode flag by editing the memory address, 0x0003c004 (@ecx+0x174). In real world, the attacker would need to use another vulnerability which would allow arbitrary memory read/write that can modify the SafeMode flag.

Also, this SafeMode bypass technique can be reused in other exploits as well. Since now an arbitrary memory read/write would directly result in code execution on the machine, these type of MSIE vulnerabilities will become more common in near future.

c0d3inj3cT