Microsoft produces workaround for IE zero-day vulnerability

News

Microsoft produces workaround for IE zero-day vulnerability

Ron Condon, UK Bureau Chief

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, could be used by attackers in drive-by attacks. According to Microsoft, it exists due to the creation of uninitialized memory during a Cascading Style Sheet (CSS) function within Internet Explorer. Under certain conditions, it says, the memory could be used by an attacker using a malicious Web page to execute code remotely and gain control of a victim's machine.

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

To continue reading for free, register below or login

Requires Membership to View

To gain access to this and all member only content, please provide the following information:

By submitting your registration information to searchSecurity.in you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here

  • Your use of searchSecurity.in is governed by our Terms of Use
  • We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
  • If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.

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."