A better, more reliable, work-around for the Microsoft Video Control Vulnerability

For the past few days I've been following the Microsoft Video Control Vulnerability with interest. Basically, it's another vulnerable ActiveX control that needs killbitted. Last night, Microsoft posted a work-around which involves using a Group Policy ADM template (ADM is the template format that was deprecated in Vista and Windows Server 2008). Unfortunately, the template tattoos the registry, which is not really recommended.

I contemplated for a while writing a work-around for this issue, but then remembered that I actually did; almost three years ago. The workaround I wrote then, for another ActiveX vulnerability will not tattoo the registry, and will be much simpler to deploy with an Enterprise Management System. Just take the CLSIDs from the advisory (there are 45 of them) and run my script that many times with the -k switch. If you wish to revert the change, run the same script with the -r switch.

Published Thu, Jul 9 2009 11:09 PM by jesper
Filed under: , , ,

Comments

# Andrew from Vancouver said on 10 July, 2009 11:27 AM

I did use the SlayOCX.vbs script, Jesper and have two comments for you.

The first is that the script is very careful to only toggle the killbit while leaving the rest of the Compatibility Flags value. It is also careful to make no changes if the key does not exist...

This second safety is a problem because the vulnerability is exploited despite this key not existing. Going back to the previous CLASSIDs that have been killbitted like the Yahoo! media grid or Aurigma controls also showed me that SlayOCX.vbs would balk.

I made some small modifications to the script for my own purpose, and now it will create the key and set the killbit and write a new value.

The second comment is, I want to be clear, not an argument but a comment. Using SlayOCX.vbs as a GPO for a computer startup script is very different from the tattooing ADM file solution, such as the one Microsoft supplies here:

blogs.msdn.com/.../quick-and-dirty-group-policy-adm-template-to-implement-the-workaround-from-kb972890.aspx

In order to gain the benefit of the precise killbit-only change with SlayOCX.vbs, one has to give up a) the computer must be rebooted, b) one must wait for that reboot to happen in an environment that doesn't force the reboot, and c) the computer must be able to reach a Domain Controller at the time it is rebooted.

By comparison, the ADM method happens at the next Group Policy Refresh for that computer, whether it can reach a DC or not.

And after checking that link I supplied to the ADM, I can offer a bonus comment, which is that SlayOCX.vbs does not change the Wow6432 node in the registry.

# jack wilson said on 10 July, 2009 12:54 PM

Have you or can you update your slayocx.vbs to support 64bit OS?

# Aaron Margosis said on 11 July, 2009 11:06 PM

What's the problem with this setting "tattooing" the registry?  When would you want it to be undone?  (Also, there's no way not to tattoo the registry with this, since the killbit setting isn't something that you can do in the "Policies" areas of the registry.

Just to be clear, "tattooing" is what happens when you use Group Policy (or anything else) to set registry settings outside of the "Policies" keys.  With true policies, the preferences or defaults become active again if the policy is removed.  Outside of the "Policies" keys, the same kind of "undo" doesn't exist.

Unless I'm misunderstanding you here...

# jesper said on 21 July, 2009 12:33 AM

Good comments. Andrew, you are right that it is safer to killbit the control, whether it exists or not. It is not hard to modify the script to do that. Most organizations, including my own, actually run the script with an EMS though, so we get the changes applied exactly when we want, not at reboot.

Jack, I probably could, but at the moment, I don't have a 64-bit box to test on. If someone else does, and feels like doing it, that would be great. If not, it will be a couple of months before I get a box to do the testing on.

Aaron, yes, in this case, I can't think of a reason to roll it back, so tattooing the registry is probably OK. However, I've said "I can't think of a reason..." before, and subsequently been offered one that I couldn't think of. One of these days, I may write something on tattooing and what it is and why it is there, but in this post, all I wanted to point out was that there is a work-around that is easy to manage with an EMS or with logon scripts.

# Aaron Margosis said on 21 July, 2009 03:35 PM

... and that also tattooes the registry.