Disable The Use Of This Activex Control From Within Internet Explorer By Setting Its Kill Bit

[Jule Kue]

Issuinga Kill-Bit for the control marks that particular control as forbidden to instantiate in the browser. Issue a Kill-Bit by setting the Compatibility Flags value to 0x400 for a control in the registry as described in KB Article 240797.

Warning - Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Modify the registry at your own risk.

(3/11/2009 Update: HTAs do currently respect the Kill-Bit for objects instantiated via the OBJECT tag. The Kill-Bit is not respected when HTAs instantiate objects in script. Thanks to Nicolas Noakes for reporting this. The Kill-Bit behavior within HTAs may change in the future to become more consistent.)

If an application or platform hosts controls and allows those controls to effectively be driven by untrusted data, that environment should respect Safe for Scripting, Safe for Initialization and Kill-Bit logic. Otherwise, the environment should provide some other equivalently or more restrictive policy, such as an allow-list of known-good scriptable objects.

Kill-Bits must be issued to prevent old / vulnerable signed versions of controls from being effectively foisted on users. Even if a user has a fixed version of the control on their system, a renamed / signed DLL or OCX served from a malicious web page could revert their machine to an insecure state.

Kill-Bits are effective regardless of their origin but obviously wider distribution of a Kill-Bit ensures more comprehensive protection. If you would like Microsoft to distribute a Kill-Bit in Windows on your behalf, contact the MSRC and include details on the CLSID(s) in question.

Important This article contains information that shows you how to help lower security settings or how to turn off security features on a computer. You can make these changes to work around a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.

This article contains pre-release documentation and is subject to change in future releases.

This security update lets users control if and how ActiveX controls and OLE objects load with a Microsoft Office kill-bit list. For more information about the Windows Internet Explorer kill-bit behavior that this feature is based on, and this includes how to set AlternateCLSIDs that allow updated ActiveX controls to load, see How to stop an ActiveX control from running in Internet Explorer.

The following advisory article discusses vulnerabilities in the Active Template Library (ATL) that could allow remote code execution.

973882 Microsoft Security Advisory: Vulnerabilities in Microsoft Active Template Library (ATL) could allow remote code execution

All the features in the advisory article can be used to help reduce these ATL vulnerabilities. Additionally, specific ATL mitigations are discussed in this security update.

This security update applies to Microsoft Word, Microsoft Excel, Microsoft PowerPoint, Microsoft Publisher, and Microsoft Visio.

You can also use the Office COM kill bit that was introduced in the security update in MS10-036 to prevent specific COM objects from running within Office applications. These specific COM objects include ActiveX controls and OLE objects. Now, through the registry, you can independently control which ActiveX and OLE objects are blocked from running when you use Office.

Important notes

ImportantThis section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

The Override IE kill-bit list option lets you specifically list which OLE objects on the Internet Explorer kill-bit list are permitted to be loaded within Office. Use the Override IE kill-bit list only if you know that the OLE object is safe to load in Office. Be aware that when Office checks the Override IE kill-bit list setting, Office also checks whether the Office COM kill bit is enabled. If the Office COM kill bit is enabled, the OLE object is not loaded.

To enable the Override IE kill-bit list option, you must correctly categorize the OLE object. In the registry, if the subkey does not already exist, add a subkey that is called Implemented Categories to the CLSID of the COM object. Then, add a subkey that contains the Category ID (CATID) for OLE objects, F3E0281E-C257-444E-87E7-F3DC29B62BBD, to the Implemented Categories key.

For example, Internet Explorer may be set up to kill an OLE object, but you still want to use this object in Office. In this case, you must first look up the CLSID for that OLE object in the following location in the registry:

When the ATL mitigations are enabled, controls that use OleLoadFromStreamsuch are prevented from functioning and control information is lost. For example, VB6/Windows common controls are affected by this issue.

Warning This workaround may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk.

We do not recommend that you disable the ATL mitigations unless it is absolutely necessary because these ATL mitigations cover a broad scope. If you disable the ATL mitigations, you might create security vulnerabilities. If you do disable the ATL mitigations, we recommend that you do not open Microsoft Office files that you receive from untrusted sources or that you unexpectedly receive from trusted sources.

To disable the mitigations that reference the ATL vulnerabilities, set the NoOLELoadFromStreamChecks REG_DWORD to a value of 00000001 in the following registry subkey:

After this security update is installed, you can disable scriptlets for Office applications and the Internet Explorer behavior is not changed.

To disable scriptlets for Office applications, set the Compatibility Flag's REG_DWORD value to 00000400 in the following registry subkey:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\3A2B370C-BA0A-11D1-B137-0000F8753F5D]

"Compatibility Flags"=dword:00800000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\1E216240-1B7D-11CF-9D53-00AA003C9CB6]

"Compatibility Flags"=dword:00800000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\248DD896-BB45-11CF-9ABC-0080C7E7B78D]

"Compatibility Flags"=dword:00800000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\B09DE715-87C1-11D1-8BE3-0000F8754DA1]

"Compatibility Flags"=dword:00800000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\C932BA85-4374-101B-A56C-00AA003668DC]

"Compatibility Flags"=dword:00800000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CDE57A43-8B86-11D0-B3C6-00A0C90AEA82]

"Compatibility Flags"=dword:00800000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\0ECD9B64-23AA-11D0-B351-00A0C9055D8E]

"Compatibility Flags"=dword:00800000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\6262D3A0-531B-11CF-91F6-C2863C385E30]

"Compatibility Flags"=dword:00800000

Dik Hogeweide wrote:Word 2003 crashes or fails to run macros after Windows Update last night

10-Mar-09Word fails to excecute the winsck.ocx. It does not even show up in the file anymore, attempting to put it back generates the error that it is not registered correctly.All changes in the security to allow activex components did not help.

Uninstall the kb960715 patch just restores as it was before.Probably one of these patches the world did not asked for.DikPrevious Posts In This Thread:On Wednesday, February 11, 2009 1:14 PM

Brian Knittel wrote:Word 2003 crashes or fails to run macros after Windows Update last night

On two different systems that installed a Windows Update last night, Word

2003 no longer runs macros that worked yesterday.On Vista SP1 64-bit, Word 2003 faults and quits. The exact statement that

causes the crash varies.

On XP Pro SP3, the same macro package just stops with run-time error 361,

"Can't load or unload

this object." loading a form.On Vista, the macro application worked again after rolling back to the

system restore point taken at 3AM today.

I haven't rolled XP back yet. I can see only three updates installed last

night: Security Update for Windows XP (KB960715)

Security Update for Windows Internet Explorer 7 (KB961260)

Update for Outlook 2003: Junk E-mail Filter (KB959614)

Anyone else seeing issues with Word 2003 today?BrianOn Wednesday, February 11, 2009 2:15 PM

Brian Knittel wrote:The macro application uses an MSFlexGrid control in a form, and it looks like

The macro application uses an MSFlexGrid control in a form, and it looks

like one of last night's updates included a kill bit for the FlexGrid

control. That may explain part of the problem. But Word shouldn't be

crashing outright.On Thursday, February 12, 2009 5:50 AM

Terry Farrell wrote:If this was due to the updates, you should call Microsoft and make a support

If this was due to the updates, you should call Microsoft and make a support

call. All support calls for update bugs are free of charge.--

Terry Farrell - MSWord MVPOn Friday, February 13, 2009 3:12 PM

Brian Knittel wrote:I don't know if they'd be interested in hearing about it.

I don't know if they'd be interested in hearing about it. Technically

speaking, the update didn't directly cause the problem. The update installed

a kill bit (disabled) an old version of the MSFlexGrid ActiveX control. With

the control disabled, Word crashed when it tried to instantiate the ActiveX

object in a form. The bug is in Word or VBA, and it's a generic problem

(handling of controls with kill bits) as opposed to something specific about

this particular update.And, again technically speaking, it's my responsibility to have known that

the MSFlexGrid control was updated last October, and I should have

downloaded it and installed it before this kill bit came along.Much worse things happened yesterday in the aftermath. I had a *heck* of a

time getting the application going again even after installing the updated

version of msflxgrd.ocx (obtained finally via a FoxPro hotfix. Microsoft

won't give this updated control away easily). Word simply refused to run the

form, saying that there was a missing object reference. I got the error

"Object library invalid or contains references to object definitions that

could not be found." In the References dialog, though, nothing said

"MISSING".What it turned out to be was that the FlexGiid object had been registered

both machine-wide and specifically for my user account (that is, both under

HKEY_CLASSES_ROOT and in HKEY_CURRENT_USER\Software\Classes). I'm not sure

how this came to be, whether I ran regsvr32 under my own account before or

after installing the hotfix, or if the hotfix installer did it, or what, but

the upshot was that the damn thing would not instantiate until I deleted the

entries for the flexgrid control under HKEY_CURRENT_USER\Software\Classes.

It was just chance that I tried running the application as Administrator and

found that it worked; otherwise I would never have thought to look there.Anyway -- one lesson here is that when you can't get an ActiveX control to

work in VBA or a Word or Excel macro form, check the registry to see if

HKEY_CURRENT_USER\Software\Classes has a definition for the control. It

probably should not. Controls should be registered by Administrator only,

and the definitions should be in HKEY_CLASSES_ROOT.On Wednesday, February 18, 2009 2:49 PM

VenkatatCincy wrote:Right now I am on your shoe and not only me many of my users having sameissue,

Right now I am on your shoe and not only me many of my users having same

issue, helpdesk doesn't want to change the registry file, is there any

workaround to solve this issue.

We are using MSFlexGrid ActiveX Control in Excel, when I try to debug we are

getting Compile Error, variable not defined at MSFlexGrid. Could you please

help me if you find solution.

Thanks in Advance,

V

Brian Knittel wrote:On Wednesday, February 18, 2009 5:19 PM

Terry Farrell wrote:The current solution is to uninstall update KB 960715.

The current solution is to uninstall update KB 960715.--

Terry Farrell - MSWord MVPOn Tuesday, March 10, 2009 12:13 PM

Dik Hogeweide wrote:Word 2003 crashes or fails to run macros after Windows Update last night

Word fails to excecute the winsck.ocx. It does not even show up in the file anymore, attempting to put it back generates the error that it is not registered correctly.All changes in the security to allow activex components did not help.

Uninstall the kb960715 patch just restores as it was before.Probably one of these patches the world did not asked for.Dik

Submitted via EggHeadCafe - Software Developer Portal of Choice

WPF Custom Validation Using the Enterprise Library

-d7f3-4e00-9aec-33ef1ec7d1a3/wpf-custom-validation-usi.aspx

3a8082e126