Protection strategies for the Security Advisory 2963983 IE 0day

We’ve received a number of customer inquiries about the workaround steps documented in Security Advisory 2963983 published on Saturday evening. We hope this blog post answers those questions.

Steps you can take to stay safe

The security advisory lists several options customers can take to stay safe. Those options are (in summary):

• • Deploy the Enhanced Mitigation Experience Toolkit (EMET)
• Block access to VGX.DLL
• Enable Enhanced Protected Mode
• Use built-in Internet Explorer configuration options to disable active scripting

We’ll address the questions we have heard from customers in relation to each of those options.

Update on Enhanced Mitigation Experience Toolkit (EMET) protections

The original security advisory and the SRD blog post from this past week both listed EMET 4.1 as effective in helping to block attacks. In our deeper analysis of the two exploit samples we have, we found that EMET 4.0 is also effective in helping to block attacks. The advisory and blog have both been updated to point out that both EMET 4.0 and EMET 4.1 are effective. Our technical preview of EMET version 5.0 also is effective in this regard; however, we do not recommend a technical preview for production deployment. Several customers asked which specific EMET mitigations were effective in helping to block attacks. We’ve prepared the following table to answer those questions:

EMET 4.0 / EMET 4.1

EMET 5 Tech Preview

Heapspray Protection

Effective

Effective

StackPivot ROP Mitigation

Effective with Deep Hooks enabled

Effective

Caller ROP Mitigation

Effective with Deep Hooks enabled

Effective

MemProt ROP Mitigation

Effective with Deep Hooks enabled

Effective

EAF+

Not present. EMET 4.x EAF does not block this attack.

Effective

Attack Surface Reduction

Not present

Effective because it blocks VGX.DLL and FLASH.ocx in Internet Zone

As you can see, three of the four EMET 4.x mitigations capable of blocking this attack required the Deep Hooks feature to be enabled. The attackers in this case leveraged ZwProtectVirtualMemory which is not protected unless Deep Hooks is enabled. Deep Hooks is not enabled in the default configuration for EMET 4.0 or EMET 4.1. The default EMET 4.x install was effective in helping to block attacks due to the Heapspray mitigation alone; however, the ROP mitigations are more robust and less likely to be bypassed than the Heapspray mitigation so we recommend enabling Deep Hooks to get the full protection of the ROP mitigations.

We have a planned update for EMET 4.1 scheduled for release on the Microsoft Download Center today. EMET 4.1 Update 1 was primarily released to address minor bug fixes. However, the update also will be enabling Deep Hooks for EMET 4.1 by default. We will post an additional SRD blog post when the EMET 4.1 Update 1 bits are live with a link to the KB describing the new release.

Clarifying the VGX.DLL workaround

The exploits we have seen have relied on Vector Markup Language (VML) to trigger the use-after-free vulnerability. As we analyzed different ways to trigger this vulnerability, we concluded that additional attacker research would be required to develop an exploit that did not rely on the presence of VML. Therefore, we recommended in the original security advisory that customers disable VGX.dll, the library that provides VML functionality. Customers can choose to either ACL the file or unregister the DLL. Unregistering the DLL can be accomplished with a single command line, silently, with no user interaction, and may be scripted to run via Microsoft System Center Configuration Manager or other infrastructure management solutions. VML is not natively supported by most web browsers today, so this remediation option may have the least impact on enterprise web app compatibility.

However, we’d like to clarify that VGX.DLL does not contain the vulnerable code leveraged in this exploit. Disabling VGX.DLL is an exploit-specific workaround that provides an immediate, effective workaround to help block known attacks.

Clarifying the IE Enhanced Protected Mode workaround

We also received questions about the Internet Explorer Enhanced Protected Mode workaround. Enhanced Protected Mode will help protect 64-bit Internet Explorer users from this attack. There is a difference between Internet Explorer 10 and Internet Explorer 11 that led to some confusion. Internet Explorer 10 has one setting to enable and Internet Explorer 11 has two settings to enable. The 64-bit aspect of Internet Explorer is a key element of this workaround as the heap spray attack is not effective in 64-bit address space, leading to a failed exploit. Enhanced Protected Mode alone on 32-bit Internet Explorer 11 is not effective in blocking the attack. The screenshots below illustrate the Internet Explorer 10 versus Internet Explorer 11 “checkbox” differences:

IE10 64bit EPM (one setting to mitigate)

IE11 64bit EPM (two settings to mitigate)

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/epm1.png)

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/epm2.png)

Choosing the best workaround for your environment

The security advisory provides several different recommended workarounds because each customer environment is different and there might be a different “best” workaround for different customers. Each workaround has different pros and cons, described below.

• Option 1: Deploy the Enhanced Mitigation Experience Toolkit

  • Pro: As described above, helps block exploits leveraging this vulnerability by adding several different hardening mechanisms to Windows.
  • Pro: Even after the eventual security update is applied, continues providing protection against other potential security vulnerabilities in Microsoft’s and third party products.
  • Con: Microsoft recommends testing before deploying widely across enterprise network as previous versions of EMET have introduced application compatibility issues.

• Option 2: Block access to VGX.dll

  • Pro: Very simple workaround. Easy and quick to deploy across enterprise network.
  • Con: May not protect against future or new exploits that may emerge to exploit this vulnerability.

• Option 3: Enable Enhanced Protected Mode on 64-bit Internet Explorer

  • • Pro: Helps block exploits leveraging this vulnerability and potentially other vulnerabilities that may be discovered in the future.
  • Con: Requires 64-bit Windows and requires running 64-bit version of Internet Explorer.

In general, for customers that already have EMET 4.x deployed, enabling Deep Hooks is likely to be the best workaround option. For customers who have not yet deployed EMET 4.x, the priority should be on immediate, quick protection which is likely to be blocking access to VGX.dll. Deploying EMET is the best long-term protection but doing so without first testing in your environment is unlikely to be the best option. As always, we recommend staying up-to-date with the latest version of Internet Explorer for improved security features such as Enhanced Protected Mode, better backward compatibility through Enterprise Mode, increased performance, and support for the modern web standards that run today’s websites and services.

Conclusion

We hope that this blog post helps guide you in choosing the best mitigation strategy for your environment. The Internet Explorer team is hard at work preparing a security update that will be released as soon as it is ready for broad deployment. Stay tuned to the Microsoft Security Response Center (MSRC) blog [link] for any news about the availability of an update.

- Elia Florio and Jonathan Ness, MSRC Engineering