Microsoft has issued a workaround to help mitigate a zero-day vulnerability in Internet Explorer which could expose an infected machine to remote control by a hacker.
The vulnerability, which was originally discovered on Dec. 9 by French security firm VUPEN,
Internet Explorer 6, 7 and 8 are confirmed to be affected; it is not clear if the Internet Explorer 9 beta is similarly affected as well.
Microsoft issued an urgent security advisory late Dec. 22, saying that it was investigating reports of the IE zero-day vulnerability. It advised users to apply security features, such as Protected Mode in Windows Vista and Windows 7, and Enhanced Security Configuration in Windows Server 2003 and 2008.
The company then followed up with more detailed advice and help, and acknowledged that the Metasploit Project had produced a proof-of-concept exploit for the vulnerability using a known technique to evade Address Space Layout Randomization (ASLR) and bypass Data Execution Prevention (DEP), both of which are intended to limit the damage done by unwanted code.
Microsoft is urging its customers to use the Enhanced Mitigation Experience Toolkit as a workaround for the exploit, mainly because it enforces ASLR and will raise an access violation alert when the exploit tries to access the area of memory it needs, and will crash the process.
Microsoft says engineers are working on the vulnerability and a patch will be issued when available. But as long as users follow the advice, they should be in good shape, according to Paul Ducklin, head of technology for Sophos PLC in Asia. Writing in his blog, Ducklin makes the point that the IE vulnerability depends on an unlikely sequence of events.
"The vulnerability relies on a memory-usage bug when Internet Explorer processes a Cascading Style Sheet file. If the style sheet imports itself - something which would not normally be useful, since the CSS file is already loaded - then IE makes a mess of memory," he says.
He blames the flaw on the way Microsoft handles Dynamic-Link Library (DLL) files.
"Unfortunately, Microsoft allows each DLL to decide whether it supports ASLR or not. And IE is implemented as a whole raft of DLLs - some of which are loaded at run-time, as needed, to render content which IE downloads. So, by sending otherwise-innocent files to IE, you can trick it into loading known DLLs. If any of those DLLs do not support ASLR, then they are loaded at a known place in memory."