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.
| Workaround | A | B | C |
| 1. Set Internet and Local intranet security zone settings to "High" to
prompt before running ActiveX Controls and Active Scripting in these zones |
| X | X |
| 2. Configure Internet Explorer to prompt before running Active Scripting or
to disable Active Scripting in the Internet and Local intranet security
zone |
| X | X |
| 3. Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level
ACL | X |
|
|
| 4. Disable Row Position functionality of OLEDB32.dll | X |
|
|
| 5. Unregister OLEDB32.DLL | X |
|
|
| 6. Use ACL to disable OLEDB32.DLL | X |
|
|
| 7. Enable DEP for Internet Explorer 7 on Windows Vista and on Windows Server
2008 |
|
| X |
| 8. Disable Data Binding support in Internet Explorer 8 | X | X |
|
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
Network Security & Hardware 
/ 7 
