Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
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.
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
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 22.214.171.124 of EMET here.
The affected applications of which we are aware are Adobe Reader/Acrobat and Google Chrome.
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