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:
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
63f0575b 94 xchg eax,esp
63f0575c 8b00 mov eax,dword ptr [eax]
63f0575e 890424 mov dword ptr [esp],eax
63f05761 c3 ret
When EMET is in place, this type of exploit will most likely fail. This is because of at least three mitigations:
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'
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.*