Re: Workarounds that kill Active-X controls.

View Full Version : Re: Workarounds that kill Active-X controls.

Jim Nugent

10-04-2006, 02:10 PM

I'm reposting this, crossposting and with f/u set to,
microsoft.public.win2000.registry...

In news:uIbsKeL5GHA.2288@TK2MSFTNGP05.phx.gbl,
Jim Nugent <njim2k-nntp@yahoo.com> wrote:
> So far, I believe we've been advised of two security workarounds the
> involve setting the kill bit for 3 controls. After the patch comes
> out, presumably these controls could be re-enabled. If I apply the
> .reg file printed in the article, it "slam dunks" 0x400 into the
> appropriate values for Compatibility Flags. My question is what if
> some bits were already set? Should I be checking before hand and
> or'ing the 0x400 bit into the DWORD?
>
> ISTR an article that explains what each bit does, but I can't seem to
> find it now.
>
> Any help would be appreciated. I'm collecting .reg files that have
> been applied, but their reversal would appear to be removing the key
> for that control. Does that make sense?
> --
> Thank you
> Jim

Mark V

10-04-2006, 11:17 PM

In microsoft.public.win2000.registry Jim Nugent wrote:

> I'm reposting this, crossposting and with f/u set to,
> microsoft.public.win2000.registry...
>
> In news:uIbsKeL5GHA.2288@TK2MSFTNGP05.phx.gbl,
> Jim Nugent <njim2k-nntp@yahoo.com> wrote:
>> So far, I believe we've been advised of two security
>> workarounds the involve setting the kill bit for 3 controls.
>> After the patch comes out, presumably these controls could be
>> re-enabled. If I apply the .reg file printed in the article, it
>> "slam dunks" 0x400 into the appropriate values for
>> Compatibility Flags. My question is what if some bits were
>> already set? Should I be checking before hand and or'ing the
>> 0x400 bit into the DWORD?

Making a Full Registry Backup in advance would be *good*!
Short of that an Export saved for reference would be also be
useful.

Both the REG files I have seen and I believe the dedicated EXE
tools for this "set a kill bit" ignore the possibility of an
existing Compatibility Flag value might be present. Not so good.

>>
>> ISTR an article that explains what each bit does, but I can't
>> seem to find it now.

I don't have that one, but may have seen it once. Let's see if
another posts a link.

>> Any help would be appreciated. I'm collecting .reg files that
>> have been applied, but their reversal would appear to be
>> removing the key for that control. Does that make sense?

Not necessary. Just remove the "Compatibility Flags" Value. OR,
revert the value's data to the preexisting one, if appropriate.
The key itself can be removed in the case it did not previously
exist of course. Not entirely certain if "empty" Keys there
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\
serve a purpose so tread lightly.

One might write a batch file using REG.EXE to accomplish
search for existing value and save it
create/apply "kill bit" changes
==== demo data only ==(wrapped)=====
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{D7A7D7C3-D47F-11D0-89
D3-00A0C90833E6}
Compatibility Flags REG_DWORD 0x400
_oldValue REG_DWORD 0x20
========================

I should mention a GUI tool: Nirsoft's ACM (ActiveX Compatibility
Manager) (free) nirsoft.net
This tool does _not_ save existing Compatibility Flags data when
"disable" is selected. Also has a limited CLI usage.

I feel it necessary to mention also that this and the recent
"unregister vgx.dll" need to be undertaken using Administrator
Group authority as do most system administration actions. Yes,
some have tried from a "limited account", and failed.

Jim Nugent

10-05-2006, 05:56 PM

In news:Xns9852BA1714263z9zzaQ2btw@msnews.microsoft.com,
Mark V <notvalid@nul.invalid> wrote:

> Making a Full Registry Backup in advance would be *good*!
> Short of that an Export saved for reference would be also be
> useful.

I make a lot of registry back ups but in this case I also export the key, if
it exists, as a workaround "undo" file before replacing the Compatibility
Flags value with 0x400.

> Both the REG files I have seen and I believe the dedicated EXE
> tools for this "set a kill bit" ignore the possibility of an
> existing Compatibility Flag value might be present. Not so good.

Hmmm... Here's one: killWebView(926043)_undo.reg
------------------------
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{E5DF9D10-3B52-11D1-83E8-00A0C90DC849}]
"Compatibility Flags"=dword:00020000
-----------------------

>>> ISTR an article that explains what each bit does, but I can't
>>> seem to find it now.
>
> I don't have that one, but may have seen it once. Let's see if
> another posts a link.
>
>>> Any help would be appreciated. I'm collecting .reg files that
>>> have been applied, but their reversal would appear to be
>>> removing the key for that control. Does that make sense?
>
> Not necessary. Just remove the "Compatibility Flags" Value. OR,
> revert the value's data to the preexisting one, if appropriate.
> The key itself can be removed in the case it did not previously
> exist of course. Not entirely certain if "empty" Keys there

Yes, there are some empty keys in there. Exporting them before adding
Compatibility Flags would create a undo.reg file that would restore their
"empty" status.

> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
> Compatibility\
> serve a purpose so tread lightly.

Yup. I tracked down the keys for the two outstanding workarounds on machines
without the w/a's. For the published workarounds, the key above is the only
key I found
present, complete with flags. But somebody should check my work.

> One might write a batch file using REG.EXE to accomplish
> search for existing value and save it
> create/apply "kill bit" changes
> ==== demo data only ==(wrapped)=====
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
> Compatibility\{D7A7D7C3-D47F-11D0-89
> D3-00A0C90833E6}
> Compatibility Flags REG_DWORD 0x400
> _oldValue REG_DWORD 0x20
> ========================
>
> I should mention a GUI tool: Nirsoft's ACM (ActiveX Compatibility
> Manager) (free) nirsoft.net
> This tool does _not_ save existing Compatibility Flags data when
> "disable" is selected. Also has a limited CLI usage.

Also for anyone interested, their other tool, Active X Helper, "disables" a
control not with the kill bit but by munging the value name for the
control's path, e.g.

[HKEY_CLASSES_ROOT\CLSID\{D7A7D7C3-D47F-11D0-89D3-00A0C90833E6}\InprocServer
32]
"ThreadingModel"="Apartment"
@="C:\\WINNT\\system32\\daxctle.ocx"

becomes

[HKEY_CLASSES_ROOT\CLSID\{D7A7D7C3-D47F-11D0-89D3-00A0C90833E6}\InprocServer
32]
"ThreadingModel"="Apartment"
"~~Disabled~~"="C:\\WINNT\\system32\\daxctle.ocx"

Enabling returns it the former. I guess that would disable
the control for ANY use, including IE scripting.

Hope all this makes sense,
--
Jim

Mark V

10-05-2006, 07:25 PM

In microsoft.public.win2000.registry Jim Nugent wrote:

> In news:Xns9852BA1714263z9zzaQ2btw@msnews.microsoft.com,
> Mark V <notvalid@nul.invalid> wrote:
>
>> Making a Full Registry Backup in advance would be *good*!
>> Short of that an Export saved for reference would be also be
>> useful.
>
> I make a lot of registry back ups but in this case I also export
> the key, if it exists, as a workaround "undo" file before
> replacing the Compatibility Flags value with 0x400.

Good technique, but many typical user are no where near so savvy.
Unfortunately.

>> Both the REG files I have seen and I believe the dedicated EXE
>> tools for this "set a kill bit" ignore the possibility of an
>> existing Compatibility Flag value might be present. Not so
>> good.
>
> Hmmm... Here's one: killWebView(926043)_undo.reg
> ------------------------
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
> Compatibility\{E5DF9D10-3B52-11D1-83E8-00A0C90DC849}]
> "Compatibility Flags"=dword:00020000
> -----------------------

Which is "handy" for some but again there is an assumption that in
fact that _was_ the existing value.
[ ]

> Yes, there are some empty keys in there. Exporting them before
> adding Compatibility Flags would create a undo.reg file that
> would restore their "empty" status.

Unless they did not exist previously...

> Yup. I tracked down the keys for the two outstanding workarounds
> on machines without the w/a's. For the published workarounds,
> the key above is the only key I found
> present, complete with flags. But somebody should check my work.

In the recent WebViewFoldrIcon (.1 and .2) case
(ref: http://isc.sans.org/diary.php?date=2006-10-01 )

I had only one key present here at the outset. So to really
"undo" I will have to remove the entire key at a future date. Any
future undo REG file for example may do just that and that could be
the wrong thing altogether in some cases. <sigh>

I'd prefer to see (for typical users) small executables (from
trustworthy sources) for such emergency killbit operations that are
responsible and store in the registry any former value and be
capable of restoring same on the second run.

[ ]
>> I should mention a GUI tool: Nirsoft's ACM (ActiveX
>> Compatibility Manager) (free) nirsoft.net
>> This tool does _not_ save existing Compatibility Flags data
>> when "disable" is selected. Also has a limited CLI usage.
>
> Also for anyone interested, their other tool, Active X Helper,
> "disables" a control not with the kill bit but by munging the
> value name for the control's path, e.g.
[ ]

Absolutely! And the fact that both tools use "Disable" for action
is bad along with ACM not being very in-your-face about it is
actually dealing with "kill bits" and probably _adding_ new keys in
some cases. These two also suffer from a look-a-like (too much)
problem in my opinion. "Active X Helper" is also a misnomer since
all registered objects, not just ActiveX controls, are initially
displayed.

> Enabling returns it the former. I guess that would disable
> the control for ANY use, including IE scripting.

Right, but that action is at least reversible.

> Hope all this makes sense,

It does. But the naming of and displays in several of Nir's tools
does not! Gotta remember to write him one of these days.

Some users may find ERUNT to be a great way to easily make Full
Registry Backups that can serve (for a while) as historical
references.

Think I saw you over at GRC recently? I hang out there often
enough.

Jim Nugent

10-06-2006, 10:25 PM

In news:Xns9852BA1714263z9zzaQ2btw@msnews.microsoft.com,
Mark V <notvalid@nul.invalid> wrote:
> In microsoft.public.win2000.registry Jim Nugent wrote:
>
>> In news:uIbsKeL5GHA.2288@TK2MSFTNGP05.phx.gbl,
>> Jim Nugent <njim2k-nntp@yahoo.com> wrote:

>>> ISTR an article that explains what each bit does, but I can't
>>> seem to find it now.
>
> I don't have that one, but may have seen it once. Let's see if
> another posts a link.

Found it. Watch out for wrap.

COMPAT

http://msdn.microsoft.com/library/default.asp?url=/workshop/components/com/reference/enum/compat.asp

--
Jim

Mark V

10-10-2006, 03:22 PM

In microsoft.public.win2000.registry Jim Nugent wrote:

> In news:Xns9852BA1714263z9zzaQ2btw@msnews.microsoft.com,
> Mark V <notvalid@nul.invalid> wrote:
>> In microsoft.public.win2000.registry Jim Nugent wrote:
>>
>>> In news:uIbsKeL5GHA.2288@TK2MSFTNGP05.phx.gbl,
>>> Jim Nugent <njim2k-nntp@yahoo.com> wrote:
>
>>>> ISTR an article that explains what each bit does, but I can't
>>>> seem to find it now.
>>
>> I don't have that one, but may have seen it once. Let's see if
>> another posts a link.
>
> Found it. Watch out for wrap.
>
> COMPAT
>
> http://msdn.microsoft.com/library/default.asp?url=/workshop/compo
> nents/com/reference/enum/compat.asp

Excellent! Thanks Jim.

Mark V

10-10-2006, 08:41 PM