Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

3.141592654 — Fri, 15 Aug 2008 18:47:55 GMT

e5df9d10-3b52-11d1-83e8-00a0c90dc849

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

dickcarl@dickcarlson.com — Wed, 04 Oct 2006 15:28:28 GMT

It's really great (for those of us at the user level) to be able to follow along in these discussions and learn. Thanks to Jesper and all of you for sharing.

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

Magnus Lööf — Tue, 03 Oct 2006 06:51:37 GMT

There are some discussions regarding the killbit and wether it will prevent an ActiveX control from installing, or just prevent it from running - http://tinyurl.com/zrcnv . It seems that the killbit is only effective *after* an ActiveX control is installed. It could be possible to set the killbit beforehand, but since the killbit does not prevent (it seems) the control from being installed, a smart (from the perspective of the malware author) ActiveX installer would reset the killbit to allow it to be run. And we know that most our users are "Curious Georges" that will happily "OK" an installation of an ActiveX control, if the content of the website is interesting enough. What I would like MS to do, is to create an Enterprise grade management facility (GPOs par example) for *whitelisting* what AX controls can be installed and used. Just my SEK 0.50

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

jesper — Mon, 02 Oct 2006 16:35:01 GMT

Malyn and John, I took a very conservative approach to the script in that if the registry key for the particular control does not exist under the Internet Explorer\ActiveX Compatibility key then do not make any changes. That was based on the assumption that if there is no key there, the control probably was not designed to be used in IE at all, and IE may have undefined behavior if I killbit a non-existent control. As it were, I have no idea if those assumptions are correct or not. I have been unable to find any documentation on the behavior of the flags or that key at all. If anyone feels like educating me, I would appreciate it.

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

malynj — Mon, 02 Oct 2006 10:19:13 GMT

This script is programmed to bail out if the registry key for the ActiveX doesn't exist. Shouldn't the script create the missing key and set the killbit? KB article 240797 indicates that typically the key will need to be created in order to kill an ActiveX control, seeming to indicate the key won't always exist. For my use I modified the script to create the key if missing, but I wanted to see if there were any specific reasons for not creating the key with the script, or if it was only the risk of not knowing enough for non-existent keys.

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

John Smitg — Mon, 02 Oct 2006 07:51:37 GMT

I get the following message: The specified ActiveX control: 844F4806-E8A8-11d2-9652-00C04FC30871 does not exist on this system For the other GUID it works ok. Is that normal or is there someting I have to worry about? It also doesnt work for the DACTL vulnerability.

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

Yakov Shafranovich — Sun, 01 Oct 2006 13:53:53 GMT

We deployed this script without any issues in our organization. However, we did modify it to log to the event log as opposed to the file using WshShell.LogEvent method. We even consider logging to a remote computer, but that probably would be a management nightmare. Thanks!

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

HiltonT — Sat, 30 Sep 2006 21:31:18 GMT

Hi Jesper, This vulnerability seems to be actively exploited. I have some updated information in my blog: http://hiltont.blogspot.com/ I just wish the term "responsible disclosure" was a lot more widely used, accepted and practiced. I also wish Microsoft would release critical fixes when they are ready, not wait for the next Black Tuesday to meander around, ESPECIALLY for actively exploited vulnerabilities. We currently have to hound them to get critical issues addressed, and that is not a good thing.

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

jesper — Sat, 30 Sep 2006 03:42:04 GMT

Roger, I do not know what happens if you lose the COMPAT_NEVERFOCUSSABLE flag in this case. However, the fact that there may be other flags is one of the major reasons I decided to write the script the way I did.

I was actually struggling to find any documentation at all on what the Compatibility Flags were. Apparently you have found them, and now I did too:

http://windowssdk.msdn.microsoft.com/en-gb/library/ms688755.aspx. I understand that it means the control cannot receive focus, but what that means I do not get. It sounds like it simply puts up an Icon, and that might not need mouse focus I suppose.

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

jesper — Fri, 29 Sep 2006 17:47:48 GMT

Actually, the script works either with or without the braces. At the beginning of the script it checks for them and removes them if they are there.

I did not think to point out that you have to be an admin to log the action since the whole script will fail if you are not an admin as you would not have the right to killbit any ActiveX controls in that case. In hindsight, I could have actually checked for that, but I did not think about it. Maybe in v.2...

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

Roger Heim — Fri, 29 Sep 2006 17:46:57 GMT

Jesper, I was trying to create an ADM template for this control like Romeo did for the DAXCTL vuln. In one of my systems there is already an entry in ActiveX Compatiblity for this control with setting 0x00020000 (COMPAT_NEVERFOCUSSABLE). Your script handles this but an ADM template will nuke the NEVERFOCUSSABLE flag. Do you know what the ramifications are of losing this existing flag?

re: Set KillBit on Arbitrary ActiveX Controls with GPO or an EMS

Andrew from Vancouver — Fri, 29 Sep 2006 17:21:44 GMT

Jesper, your script requires the braces around the CLASSID, but your example doesn't use the braces! Checking for the presence of the braces would make sense, and the lack would be logged if the -l option was chosen. You might also point out that the logging option only works when the user who executes it is an administrator equivalent; if your script is called from the user's login script, they won't have the privilege write to the %systemdrive% location.