Internet Explorer CSS 0day

Vulnerabilities, malwares and exploits have been out there since the existence of software themselves. Running with malicious intentions, these programs have always been a thorn in application developers’ sides, and keep ongoing a continuous game of cat and mouse between developers and attackers.

Being the most popular OS in the world, Windows and its associated applications have been the most frequent target of malicious exploits, and Internet Explorer is no exception. Back in December 2010, a new vulnerability affecting IE 6, 7 and 8, running Windows Vista and above was published on a full-disclosure security list, labeled IE CSS 0-day vulnerability and was later addressed in Microsoft’s Security Advisory 2488013.

This exploit reportedly targeted users of IE 6 through 8, allowing the execution of a malicious code on an affected user’s computer through the currently logged in account just by visiting a website containing a malicious CSS script. Microsoft currently believes the attack hasn’t affected many users, and while it can be easily circumvented, it is a serious threat that can be used at a much larger scale causing massive damage.

Let’s try to understand how this whole thing works. As the name suggests, this vulnerability relies on a loophole within Internet Explorer’s processing of Cascading Style Sheets (CSS). Normally, a CSS file (which dictates the look and feel of an HTML file) would already be loaded when you visit a website, but if the style sheet imports itself, it wreaks havoc on IE’s memory management, allowing any unauthorized code to execute while bypassing the usual IE downloads’ security checks, including the new Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).

DEP is designed to perform additional checks on memory to help prevent malicious code from running on a system. Specifically, if a remote attacker manages to crash a running application on your system, the areas of memory where the application stored its run-time data, including stack and heap, are marked un-executable, so even if malicious code makes it into memory bytes, the operating system would prevent it from running. Hence, DEP will prevent any unauthorized code execution unless the attack targets those memory sectors where code has already been marked executable, which is where ASLR comes in.

ASLR loads programs and DLLs in a different, random location each time they are executed, and since bypassing DEP requires you to know exactly where executable code is going to be, the randomization offered by ASLR ensures that the attacker can never accurately predict which memory blocks to target. He may opt to perform a search operation, but the code required to perform the search would be blocked by DEP in the first place. Hence, from the outside, it would seem that Microsoft has created the perfect security barrier.

Hats off to Microsoft, though, for they have, most unfortunately, allowed each DLL to decide for itself whether it supports ASLR or not. The Internet Explorer is a huge collection of DLLs itself, some of which execute at run-time to render the content that IE downloads. Now, with a malicious CSS code causing a memory heap to go berserk, the attacker would send otherwise-safe files to IE causing it to load the known DLLs. And, if any of these DLLs does not support ASLR (which they don’t), then their location in the memory is already known, and DEP simply goes out the window. One specially designed web-page is all a malicious attacker needs to gain execution access on your machine, without your knowledge at all.

While most modern browsers have entirely switched to the newer, safer versions of CSS handling, Microsoft’s prized internet browser still utilizes the same old DLLs to handle CSS rendering, and with the still-very-large user base of IE, such exploits can become disastrous should someone decide to take advantage of it. Microsoft’s security advisory suggests that the exploit is public knowledge, but neither used on a mass level yet nor critical enough to merit an out-of-band security release.

While Microsoft figures out a patch, one easy workaround could be to use Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). This would allow you to force named applications to perform ASLR on every DLL that is loaded, irrespective of whether the DLL supports it or not. That way, DEP again comes into effect for every code that depends on a memory overload, and would at least bypass this particular vulnerability.