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.
Been reading on here for a long time now, very nice site, well informed material. I’ll be checking this program out when I build my new system in a few months. More security cant hurt 🙂
-Scott
thanks for the caution on this one. not being an IT person, i will pass on doing this.
In their list of Workarounds, Microsoft says “Set Internet and Local Intranet security zone settings to “High” to block ActiveX Controls and Active Scripting in these zones” so you can at least do this.
I’ve been using EMET for for several months on Windows 7 64-bit and new hardware with no problems.EMET 2.0 comes with a fairly good user manual, and I suggest reading it before attempting installation.
Skype on 64bit Windows 7 works if you enable all checks except for EAF (Export Address Table Access Filtering). I figured it out by process of elimination 🙂
– http://community.websense.com/blogs/securitylabs/archive/2010/12/23/zero-day-different-exploit-in-internet-explorer.aspx
23 Dec 2010 – “… Two different new zero-day exploits were published on December 22…
1) … The use of built-in protections of DEP and ASLR on the Windows platform and Internet Explorer doesn’t guarantee to stop the exploit. It stems from the fact that the affected DLL mscorie.dll used by Internet Explorer wasn’t compiled to support ASLR – this fact allows an attacker to also bypass DEP by using ROP (return to oriented programming) and successfully exploit the system…
2) … The second vulnerability takes advantage of the Microsoft WMI Administrative Tools ActiveX Control. Internet Explorer is vulnerable only if Microsoft WMI administrative tools is installed…”
.
From the EMET guide p16 — this is a serious caveat emptor!
“Configuring the system setting for DEP changes a boot option for Windows. For systems using BitLocker, this will cause BitLocker to detect that “system boot information has changed” and you will be forced to enter your recovery key the next time you boot Windows. It is highly recommended that you have your recovery key ready before changing the system configuration setting for DEP on a system with BitLocker enabled.”
So when securing your fully encrypted disks this would cause it to fail closed till you reopen it up with your recovery key.
At least the MS encryption piece works — if the operating system changes “unexpectedly”, it fails into a closed mode.
You got hard copy of safety copies of your keys right at hand — course you do!
Like I said, read the manual first.
how many more ‘patches’ and ‘tools’ do we need to ‘fix’ the broken Windows ship?
Microsoft doesn’t mention IE9 beta in the bulletin. Anybody know if it is also vulnerable? Looking at IE9 in procexp it says virtualized (in the virtualized column). Does this sandbox protect it?
Doesnt work on people running as non-admin. Its alot easier to switch to a non-admin account, especially in vista/7,than to deal with EMET.
@drzaiusapelord
I will have to runt he exploit to validate, but wow wouldn’t that be nice and easy. Wonder why MSFT doesn’t’ post that as a potential fix?
I always try to not run as an administrator, get friendly with the runas command.
Flash can be used to exploit this as well?
http://www.youtube.com/watch?v=iHM9d16zWmg
I just was watching that there. I don’t exactly get it but from what I read here and saw there this is bad and could give hackers access to your computer right?