Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

November, 2010

  • DEP, EMET protect against attacks on the latest Internet Explorer vulnerability

    Today we released Security Advisory 2458511 notifying customers of limited attacks leveraging an Internet Explorer vulnerability. The beta version of Internet Explorer 9 is not affected while Internet Explorer 6, 7, and 8 are affected. So far the attacks we have seen only target Internet Explorer versions 6 and 7 on Windows XP.  Attacks would not have been successful against Internet Explorer 8. In this post we will explain the vulnerability, describe why Internet Explorer 8 users are at reduced risk, and cover how to protect yourself from future attacks leveraging this vulnerability.

    The vulnerability

    Internet Explorer incorrectly under-allocates memory to store a certain combination of Cascading Style Sheets (CSS) tags when parsing HTML. This could result in an overwrite of the least significant byte of a vtable pointer. An attacker able to spray memory with a specific pattern could potentially execute code in the context of the process parsing the HTML. The defense against heap spray style attacks is Data Execution Prevention (DEP).

    DEP blocks current attacks

    The attacks we’ve seen are all blocked by DEP. DEP is enabled by default on IE8 and can be enabled for earlier versions of IE as well. Refer to the advisory for details on how to do this. Because this is a not a typical use-after-free vulnerability, we anticipate exploit writers having a difficult time bypassing DEP. The current techniques for bypassing DEP cannot be directly applied because the memory corruption is a partial vtable pointer overwrite. We anticipate that any exploit that attempts to bypass DEP will be highly unreliable (i.e. causing IE to crash), especially on systems that support Address Space Layout Randomization (ASLR).

    How can I add more protection?

    As discussed above, this vulnerability is in the processing of a specific combination of Cascading Style Sheets (CSS) tags. In addition to making sure DEP is enabled, the best workaround option is to override the CSS supplied by the website using a user-defined .CSS file for a small subset of the CSS language. This will prevent all versions of Internet Explorer from going down the vulnerable code path and has been found to have a very limited application compatibility risk. The advisory describes the procedure to apply user-defined CSS in the HKEY_CURRENT_USER registry hive.

    Staying protected with EMET

    Earlier this year, we released version 2.0 of the Enhanced Mitigation Experience Toolkit (EMET). This toolkit helps to prevent software vulnerabilities from being exploited through the use of a number of different security mitigation technologies.

    Among other things, EMET enables DEP on a target process. Using EMET on a version of Internet Explorer that does not enable DEP by default will block the attacks we have analyzed. Beyond this, EMET includes several other mitigations such as Mandatory ASLR and EAT Access filtering (EAF) that can help block future attacks.

    Please note that if you install EMET, you will also need to configure it to protect a specific application. Instructions on how to do this can be found in the advisory as well as in the user’s guide that is installed with EMET.

    Thanks to Fermin J. Serna for his work on the issue as well as on EMET.

    -Andrew Roths, Jonathan Ness, and Chengyun Chu, MSRC Engineering

  • Updated EMET Version Released

    It’s recently come to our attention that some Enhanced Mitigation Experience Toolkit (EMET) v2.0 users may have potential issues with the update functionality of specific applications from Adobe and Google.  As a result, today we released a new version of EMET that will help ensure these updaters work as expected when EMET is in place for added protection. No other behavior is being changed with this release. You can download version of EMET here.


    The affected applications of which we are aware are Adobe Reader/Acrobat and Google Chrome.


    • Adobe Reader / Acrobat.  Due to this issue, the updater may require Reader and Acrobat users to reboot in order to complete an upgrade when they otherwise would only have been required to close and restart the application.


    • Google Chrome.  This issue may affect machines with multiple users running Chrome at the same time with each instance configured for use with EMET.  If one of those instances is running as an admin, it will block the other running instances from self-updating.  Please note that on Vista, Server 2008, Windows 7, and Server 2008 R2, users must explicitly right click on Chrome and select “run as administrator” to be affected.


    Depending on your environment, which applications you opt into EMET, and how you handle updates, you may not need to update your deployment of EMET.  If you do decide to update your deployment and have the previous MSI installed on your machines, you can roll out the new MSI as an upgrade.  Alternately, if you configured the machines with EMET_Conf running from a central share, you can simply replace the binaries on that share and run “EMET_Conf --list" on each of the machines.  EMET_Conf will update the necessary files.


    - Andrew Roths and Fermin J. Serna from MSRC Engineering