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

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

Aaron Margosis — Tue, 21 Jul 2009 20:35:28 GMT

... and that also tattooes the registry.

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

jesper — Tue, 21 Jul 2009 05:33:36 GMT

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.

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

Aaron Margosis — Sun, 12 Jul 2009 04:06:00 GMT

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...

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

jack wilson — Fri, 10 Jul 2009 17:54:48 GMT

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

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

Andrew from Vancouver — Fri, 10 Jul 2009 16:27:01 GMT

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.