Today we released Security Advisory 2488013 to notify customers of a new publicly-disclosed vulnerability in Internet Explorer (IE). This vulnerability affects all versions of IE. Exploiting this vulnerability could lead to unauthorized remote code execution inside the iexplore.exe process.
Proof-of-concept exploit bypasses ASLR and DEP
The Metasploit project recently published an exploit for this vulnerability using a known technique to evade ASLR (Address Space Layout Randomization) and bypass DEP (Data Execution Prevention).
In a few words, Internet Explorer loads mscorie.dll, a library that was not compiled with /DYNAMICBASE (thus not supporting ASLR and being located always at the same base) when processing some html tags. Attackers use these predictable mappings to evade ASLR and bypass DEP by using ROP (return oriented programming) gadgets from these DLLs in order to allocate executable memory, copying their shellcode and jumping into it. Note that without that predictable mapping, the only public ways to evade ASLR and DEP is through:
- Use of this (in case the current vulnerability allows) or another vulnerability as an information leak.
- Using techniques such as JIT-spraying or similar ones. Please note IE only JITs IE9’s javascript and there are security mitigations in place. But third party plugins could JIT in an insecure manner.
We have recently blogged on the effectiveness of ASLR and DEP here.
Recommendation: Use Enhanced Mitigation Experience Toolkit (EMET) to dynamically rebase all loaded DLLs
In order to minimize the risk of exploitation, users could install EMET and proceed to protect the iexplore.exe process as shown in the BlueHat video.
Exploits that attempt to bypass ASLR and DEP would use several ROP gadgets for several purposes. To understand why EMET is an effective workaround for these exploits, let’s focus on the stack pivot gadgets which set the stack pointer to the attacker controlled data (heap spray in our case):
0:000> u 63f0575b L4
mscorie!_chkstk+0x1b:
63f0575b 94 xchg eax,esp
63f0575c 8b00 mov eax,dword ptr [eax]
63f0575e 890424 mov dword ptr [esp],eax
63f05761 c3 ret
0:000>
When EMET is in place, this type of exploit will most likely fail. This is because of at least three mitigations:
- Mandatory ASLR: This mitigation will force the mscorie.dll to be located on random addresses each time.
- Heap Spray pre-allocation: Some of these exploits use some common used heap pages for placing ROP data such as 0x0c0c0c0c.
- EAT Filtering: Running shellcode can potentially be blocked by this mitigation.
Although the later two mitigations in the list above are not bullet proof and can be evaded, Mandatory ASLR is a solid one for closing the mscorie.dll exploitation vector. When the exploit attempts to jump into the ROP gadget that it believes to be at a predictable memory address, it will hit an access violation and crash the process:
0:000> u 63f0575b L4
63f0575b ?? ???
^ Memory access error in 'u 63f0575b l4'
0:000>
And the exploit will fail.
Thanks to Richard van Eeden, Bruce Dang, and Jonathan Ness from the MSRC Engineering team for the help investigating this issue.
--
Fermin J. Serna, Security Software Engineer
*Posting is provided “AS IS” with no warranties, and confers no rights.*