Microsoft “Fix it” available to mitigate Internet Explorer 8 vulnerability

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

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

.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

patch:???????? 7D 07             jge     WhilepNextExistingBlock3
patch:???????? E9 ?? ?? ?? ??    jmp     CHK_FAIL
patch:???????? 33 FF             xor     edi, edi
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.


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 or

Special thanks to Elia Florio for his work analyzing exploits for this vulnerability.

– Cristian Craioveanu and Jonathan Ness, MSRC Engineering