Hackers have released exploit code that can be used to compromise Windows PCs through a previously unknown security flaw present in all versions Internet Explorer, Microsoft warned today.
Dave Forstrom, director of trustworthy computing at Microsoft, said although the software giant is not aware of any attacks wielding this flaw against Windows users, “given the public disclosure of this vulnerability, the likelihood of criminals using this information to actively attack our customers may increase.”
Microsoft’s security advisory says the problem has to do with the way IE handles CSS style sheets. A posting on Microsoft’s Security Research & Defense blog notes that the Metasploit Project recently published an exploit for this flaw that evades two of the key security defenses built into Windows Vista and Windows 7 — Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP).
Sophos’ Paul Ducklin just published a note on the situation, including a crash course on ASLR and DEP, and why IE is vulnerable even on newer versions:
“DEP is designed to prevent you from sending data packets containing code and assuming that you can run that code if you manage to crash the application which processes it. Areas of memory in which the application stores its run-time data – including the stack and the heap – are marked non-executable. So even if you do cram them full of malware and trick the computer into jumping to the offending code, the operating system will prevent it from running.”
“If, due to DEP, you can’t simply supply and run your own code, then your exploit needs to make use of code which is already loaded into memory and marked executable. That means you need to predict exactly where in memory it is going to be.”
“And ASLR is specifically intended to stop you from doing so. By loading programs and DLLs in a different, random location every time, you can’t predict where you will find useful stuff in memory. That means you to need to locate it first – but you can’t do that either, because the code you need to perform the search is blocked by DEP.”
“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 the content which IE downloads. So, by sending IE otherwise innocent files, 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.”
Microsoft says it is mulling a security update to fix the flaw, but that in the meantime Windows Vista and Windows 7 users can block most attacks of this kind using a free Microsoft offering called the Enhanced Mitigation Experience Toolkit, or EMET.
I’ll have more on EMET in an upcoming post, but this is a pretty handy tool that can help Windows users beef up the security of commonly used applications, whether they are made by a third-party vendor or by Microsoft. If you install EMET, you can force individual applications to perform ASLR on every DLL they load, whether the DLL wants it or not.
One tip about EMET: Go slow with it. Changing system defaults across the board – such as changing ASLR and DEP settings using the “configure system” tab – may cause stability and bootup problems. I’ve been using it on a 64-bit Windows 7 system and phasing in some of my most-used applications on-by-one with the “configure apps” button just to make sure the added security doesn’t crash the programs (see screen shot below). So far, the only problem I’ve run up against was Skype, which didn’t seem to like being forced into using the six different protection mechanisms that EMET employs by default when you manually add application: It simply would crash upon startup.
The other thing I should note about EMET is that it requires you to have Microsoft’s .NET platform installed. And while it does technically work on Windows XP (Service Pack 3 only), XP users cannot take advantage of mandatory ASLR and some of the other notable protections included in this tool.
