Microsoft Gets More Detailed About IE Vulnerability and Workarounds

I've never seen Microsoft get so elaborate and comprehensive about workarounds for a vulnerability. They must be getting a lot of interest, or should I say pressure, from customers. I'm speaking, of course, of the new IE zero-day attack.

A Friday night entry on the Security Vulnerability Research & Defense blog goes into a little more detail about the exact nature of the vulnerability. It also has a lot of detail on the various workarounds and their relative advantages.

The vulnerability itself is a memory corruption error in the handling of DHTML data bindings. The attacker does a "heap spray" and then an invalid pointer dereference in an array of data binding objects. They don't exactly give proof of concept code, but this is more than they usually say.

The workarounds fall into three classes, those that:

(A) block access to the vulnerable code in MSHTML.dll via OLEDB, protecting against current attacks
(B) apply the most secure configuration against this specific vulnerability.
(C) make it much harder to heap spray.

The (A) workarounds, are more desirable because they disable the least functionality, and some of them are very targeted. The (B) workarounds, if you ask me, may be necessary but are undesirable. Breaking scripting breaks a lot of software and prompting for it is of dubious value because users won't know which prompts to say yes to. The only (C) entry that's really interesting is to enable DEP and you should do that irrespective of this issue. Microsoft recommends one from column (A) and, to be really comprehensive, one from column (B). I guess they have to say this.

They are particularly proud of one of the (A) workarounds, Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACL, because it is so specifically targeted to the vulnerability. This capability is only available on Windows Vista and Server 2008 when running IE7 or IE8 in protected mode and UAC (User Account Control). In protected mode ACLs (Access Control Lists) have ILs (Integrity Lists) and it's possible to prevent one object from accessing another by changing the IL of the latter object. Another workaround, Disable Data Binding support, is only available on IE8.

The blog entry has an attached ZIP file with two files in it, one for 32-bit and one for 64-bit systems. There are instructions for how to implement this workaround at the command line, but it could really do with at least a single consolidated script that detected if the system is an appropriate level (protected mode), whether it's 32-bit or 64-bit, and then runs the appropriate commands and returns errors. Perhaps in the next blog entry.

And don't forget that anti-virus and IPS products can play a role in blocking these attacks by looking for specific known attacks. So this is also the time to look for new signatures on a frequent basis.

The data binding bug is of a type that you'll find in any reasonably complex software. You can argue that it's a sign that IE is overly complex and there's some merit to that argument. The data binding facilities are an old feature of the type that I suspect Microsoft would not create now, given their attitude about security over the last few years. But the cat's out of that bag. Withdrawing features like this after Microsoft spent some time convincing customers to use them would be too much.

Some of the workarounds, on the other hand, show the value of the security that Microsoft has been working into the infrastructure since some time before Vista. The Integrity List trick really is cool, especially if they could make it more easily distributable through network management techniques, as are many of the other workarounds.

This episode is also an interesting test of how quickly Microsoft can get an out-of-band patch together. I think it's safe to say that Microsoft found out about this around the same time the rest of us did, meaning this past Tuesday. Officially they may say that they're looking to do what is appropriate and that an out-of-band patch may be the right option, but of course it is. And since they seem to know exactly where the bug is now they probably already have a prospective patch and its probably just a matter of testing time.

Every version of IE currently supported touches on a whole lot of configurations, so there's a non-trivial amount of testing to do. Let's start a pool: My guess is that they try to come up with a Christmas present, so that MS08-078: Vulnerability in Internet Explorer Data Binding Components Could Allow Remote Code Execution (Critical) (that's a dead link for now, but not for long) will be released Monday, December 22.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack