Today, we are making available a “Microsoft Fix it” solution to block attacks leveraging the Internet Explorer 8 (IE8) vulnerability described in Security Advisory 2847140. This code-signed, easily downloadable and install-able Fix it package uses the Windows application compatibility toolkit to make a small change at runtime to mshtml.dll every time IE is loaded. Here are the links to both apply and uninstall the Fix it solution:
| Apply Fix it | Uninstall Fix it |
|---|---|
Microsoft Fix it 50992 |
Microsoft Fix it 50991 |
In this blog post, we’d like to describe the following:
- More information about the progress toward a comprehensive security update
- More information about workaround options to disrupt exploits leveraging this vulnerability
- More information about how the Fix it solution works
Comprehensive update in testing now
We have built a comprehensive security update that addresses this vulnerability and it is currently being tested around-the-clock. We will release it as soon as testing confirms it is ready for broad release to all customers. Tomorrow, please visit our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle.
Workaround options
As listed in Security Advisory 2847140 and confirmed externally, Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is a good workaround option for the in-the-wild attacks and public pentest framework that we have seen. The exploit version in the pentest framework that target Windows Vista and Windows 7 leverages a DLL module installed by Java 6 to bypass ASLR. EMET’s Mandatory ASLR feature blocks this exploit by enforcing ASLR randomization for this DLL when it gets loaded by IE8. At the moment, we are aware of a limited number of attacks in the wild and they target IE8 on Windows XP only. These exploits currently used by attackers are also blocked both by EMET’s EAF mitigation and by the EMET 3.5 TP and 4.0 Beta anti-ROP mitigations. The first ROP stage triggers EMET’s StackPointer, CallerCheck and SimExecFlow checks. Enterprises already using EMET can anlyze their machine logs to investigate possible exploitation events for this exploit reported by EMET mitigations.
For a stronger level of protection, we recommend installing the Fix it solution until the comprehensive security update is available. The Fix it applies changes to the mshtml loaded binary, similar to the changes applied by the IE team’s comprehensive security update. More information about the vulnerability, and how it is blocked by the Fix it, can be found in the next section.
How the Fix it “fixes” the vulnerable code
The vulnerability is exposed due to a page layout issue, triggered when Internet Explorer 8 is trying to calculate layout information for nodes no longer in the DOM tree. The issue is caused by layout structures that are not properly cleaned up and contain dangling pointers to page elements. When the layout is updated, the browser crashes due to accessing the freed memory. The code that cleans up the dead links already exists, but it runs after the layout structures are accessed. The solution is to move the cleanup logic before the layout structure access.
The appcompat shim-based “Fix it” protection tool does the exact same thing as the fix provided by the Internet Explorer team. This is still a workaround, but more surgical as compared to other workarounds because it blocks the root cause of the vulnerability. The shim modifies in memory the mshtml!CBlockContainerBlock::BuildBlockContainer function in order to force the code flow change that results in the layout structures being properly cleaned up before access:
InjectLoopHere: CODE XREF: CBlockContainerBlock::BuildBlockContainer+103
match:74CC08DC 8B 45 08 mov eax, [ebp+arg_0] Inject code here!!
match:74CC08DF 8B 40 08 mov eax, [eax+8]
patch:74CC08DC E9 ?? ?? ?? ?? jmp WhilepNextExistingBlock2
patch:74CC08E1 90 nop
ResumeExecution:
.text:74CC08E2 C1 E8 0A shr eax, 0Ah
.text:74CC08E5 A8 01 test al, 1
.text:74CC08E7 0F 85 FB 8E FD FF jnz loc_74C997E8
WhilepNextExistingBlock: CODE XREF: CBlockContainerBlock::BuildBlockContainer-6C6CE
.text:74CC094E 39 7D F4 cmp [ebp+pNextExistingBlock], edi
.text:74CC0951 0F 85 38 36 F9 FF jnz LoopToRelocate
LoopToRelocate: CODE XREF: CBlockContainerBlock::BuildBlockContainer+2DF
.text:74C53F8F FF 75 F4 push [ebp+pNextExistingBlock]
.text:74C53F92 8B 4D 0C mov ecx, [ebp+arg_4]
.text:74C53F95 FF 75 08 push [ebp+arg_0]
.text:74C53F98 8D 55 F4 lea edx, [ebp+pNextExistingBlock]
.text:74C53F9B E8 2B 64 0A 00 call CLayoutBlock::RemoveChild ; layout structure cleanup
.text:74C53FA0 8B F0 mov esi, eax
.text:74C53FA2 3B F7 cmp esi, edi
match:74C53FA4 0F 8D A4 C9 06 00 jge WhilepNextExistingBlock
patch:74C53FA4 E9 ?? ?? ?? ?? jmp CLOBBER_NOPS_PATCH_BYTES
patch:74C53FA9 90 nop
.text:74C53FAA E9 25 58 04 00 jmp CHK_FAIL
.text:74C53FAA END OF FUNCTION CHUNK CBlockContainerBlock::BuildBlockContainer
CLOBBER_NOPS_PATCH_BYTES:
patch:???????? 7D 07 jge WhilepNextExistingBlock3
patch:???????? E9 ?? ?? ?? ?? jmp CHK_FAIL
WhilepNextExistingBlock2:
patch:???????? 33 FF xor edi, edi
WhilepNextExistingBlock3:
patch:???????? 39 7D F4 cmp [ebp+pNextExistingBlock], edi
patch:???????? 0F 85 ?? ?? ?? ?? jnz LoopToRelocate
patch:???????? 8B 45 08 mov eax, [ebp+arg_0]
patch:???????? 8B 40 08 mov eax, [eax+8]
patch:???????? E9 ?? ?? ?? ?? jmp ResumeExecution
The “Fix it” solution will apply only for the x86 versions of Internet Explorer 8 that have applied MS13-028: Cumulative Security Update for Internet Explorer: April 9, 2013. Applying this workaround will not interfere with the installation of the final security update that will address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, after you apply the yet-to-be-released final security update, you should uninstall the Fix it workaround as it will no longer be needed.
Conclusion
We want to reiterate that only IE8 is vulnerable to this issue and we currently see only limited attacks. We are hard at work developing a comprehensive security update. Tomorrow, please review our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle. In the meantime, feel free to reach out to us with any questions on the above. You can contact us at switech@microsoft.com or secure@microsoft.com.
Special thanks to Elia Florio for his work analyzing exploits for this vulnerability.
- Cristian Craioveanu and Jonathan Ness, MSRC Engineering