Microsoft Gets More Detailed About IE Vulnerability and Workarounds

By Larry Seltzer  |  Posted 2008-12-13 Print this article Print

You have a Chinese menu of options for blocking attacks on this scary bug, and it's a safe bet that a patch will come out before too long.

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.
1. Set Internet and Local intranet security zone settings to "High" to prompt before running ActiveX Controls and Active Scripting in these zones
2. Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone
3. Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACLX

4. Disable Row Position functionality of OLEDB32.dllX

5. Unregister OLEDB32.DLLX

6. Use ACL to disable OLEDB32.DLLX

7. Enable DEP for Internet Explorer 7 on Windows Vista and on Windows Server 2008

8. Disable Data Binding support in Internet Explorer 8XX
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 Security Center Editor Larry Seltzer's blog Cheap Hack

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel