New Flaw in Internet Explorer

Microsoft has issued a new Security Advisory (2488013) concerning a previously unreported flaw in all supported versions (8, 7, and 6) of its Internet Explorer browser, on all supported Windows versions.  This is a potentially very serious vulnerability that might allow an attacker to execute code on your machine if you visit a malicious Web page.  Microsoft says, in the Advisory:

The vulnerability exists due to the creation of uninitialized memory during a CSS function within Internet Explorer. It is possible under certain conditions for the memory to be leveraged by an attacker using a specially crafted Web page to gain remote code execution.

Microsoft has also acknowledged, in a post on its Security Research and Defense blog, that a working exploit of this vulnerability has been published on the Internet, although there are no reports of active exploits so far.   (That is likely to change.)    The exploit uses a previously discovered technique to evade two of the security features Microsoft introduced with Windows versions Vista and 7: Address Space Layout Randomization [ASLR], which randomizes the address at which Dynamic Link Libraries [DLLs] are loaded; and Data Execution Prevention [DEP], which prevents execution of code located in memory segments marked as containing data.  It loads a DLL, used by Internet Explorer to process certain HTML tags, that was compiled in such a way that it will not use ASLR, and is thus loaded at a fixed, predictable location in memory, allowing the attacker to inject executable code.

Microsoft suggests that the risk to users’ systems can be reduced by using its Enhanced Mitigation Experience Toolkit [EMET].  ( I talked briefly about EMET in an earlier post about a vulnerability in Adobe’s software.)  Essentially, the EMET allows you to force the use of ASLR and DEP, regardless of how the executable modules were compiled.  This mitigation is not without its own potential problems.  Some applications may not be compatible with the EMET.  I recommend that you enable it only on an application-by-application basis, not on a system-wide basis.  The latter option has been reported to cause system stability problems in some cases.  You should test each application carefully before using it with EMET in a production environment.

Another issue with EMET is that, although it can be installed on Windows XP/SP3 and Server 2003, provided you have the .NET framework 2.0 installed, you cannot use the ASLR protection, because those versions of Windows don’t support it.

I will post further information as it becomes available.  Brian Krebs has an article on this problem at his Krebs on Security blog; the SANS Internet Storm Center also has a diary entry.