Plan security settings for ActiveX controls for Office 2010

About planning settings for ActiveX controls

Office 2010 provides several security settings that let you to control how ActiveX controls behave and how users are notified about potentially unsafe ActiveX controls. By configuring these settings, you can do the following:

• Disable ActiveX controls.

• Modify how ActiveX controls are initialized based on the safe mode parameters and the Safe for Initialization (SFI) and Unsafe for Initialization (UFI) parameters.

For information about how to configure security settings in the Office Customization Tool (OCT) and the Office 2010 Administrative Templates, see Configure security for Office 2010.

By default, trusted ActiveX controls are loaded in safe mode with persistent values and users are not notified that the ActiveX controls loaded. A trusted ActiveX control is any ActiveX control that is signed by a trusted publisher or contained in a document that is opened from a trusted location or considered to be a trusted document. Untrusted ActiveX controls load differently depending on how the ActiveX control is marked and whether a VBA project exists in the file together with the ActiveX control. The default behavior of untrusted ActiveX controls is as follows:

• If an ActiveX control is marked Safe for Initialization (SFI) and it is contained in a document that does not contain a VBA project, the ActiveX control is loaded in safe mode with persistent values. The Message Bar does not appear and users are not notified about the presence of the ActiveX control. All ActiveX controls in the document must be marked SFI for this behavior to occur.

• If an ActiveX control is marked Unsafe for Initialization (UFI) and it is contained in a document that does not contain a VBA project, users are notified in the Message Bar that ActiveX controls are disabled. However, users can click the Message Bar to enable ActiveX controls. If a user enables ActiveX controls, all ActiveX controls (those marked UFI and SFI) are loaded in safe mode with persistent values.

• If an ActiveX control marked UFI or SFI is contained in a document that also contains a VBA project, users are notified in the Message Bar that ActiveX controls are disabled. However, users can click the Message Bar to enable ActiveX controls. If a user enables ActiveX controls, all ActiveX controls (those marked SFI and UFI) are loaded in safe mode with persistent values.

Disable ActiveX controls

Office 2010 provides a setting that enables you to disable ActiveX controls. Disabling ActiveX controls prevents all ActiveX controls in a file from initializing (that is, loading) when a file is opened. It also prevents users from adding ActiveX controls to a document. In some cases, a disabled ActiveX control might appear in a file as a red x or some other symbol. However, the control is disabled and no action occurs if a user clicks the symbol. Also, when you disable ActiveX controls, users are not notified that ActiveX controls are disabled.

Use the following guidelines to determine whether to disable ActiveX controls.

Setting name: Disable all ActiveX

• 
  Description: This setting controls whether ActiveX controls are disabled in Office 2010. This is a global setting and cannot be configured on a per-application basis.

• 
  Impact: If you enable this setting, ActiveX controls do not initialize and users are not notified that the ActiveX controls are disabled. Also, users cannot insert ActiveX controls into documents. ActiveX controls can provide additional functionality in documents. Therefore, disabling them can reduce functionality for users. You should ensure that users are aware that this setting is enabled, because they are not notified by the application that ActiveX controls have been disabled. It is also important to determine whether ActiveX controls are used to provide business-critical functionality before you enable this setting.

• 
  Guidelines: Organizations that have a highly restrictive security environment typically enable this setting.

You can also use the Office COM kill bit, which was introduced in Office 2010, to prevent specific COM objects, including ActiveX controls, from running within Office 2010 applications. This capability was available in the 2007 Office system. However, it was dependent on the Internet Explorer ActiveX kill bit setting. Now, with Office 2010, you can independently control through the registry which COM objects will not be able to run by using Office 2010. If, for example, the kill bit is set for the same ActiveX control in both locations, Office and Internet Explorer, and there is a conflict between the two settings, the Office COM kill bit has precedence. A common scenario where you would see the Office COM kill bit set is when you apply an update that is included in a Microsoft Security Bulletin to address a specific Office 2010 security issue.

It is possible to add an AlternateCLSID (also known as a “Phoenix bit”) when you need to correlate the CLSID of a new ActiveX control, which was modified to mitigate the security threat, to the CLSID of the ActiveX control to which the Office COM kill bit was applied. Office 2010 supports using the AlternateCLSID only with ActiveX control COM objects. For more information about kill bit behavior, including AlternateCLSID, see How to stop an ActiveX control from running in Internet Explorer (https://go.microsoft.com/fwlink/p/?LinkId=183124).

Because the following procedure is highly technical, do not continue unless you are very comfortable with the procedure.

The location for setting the Office COM kill bit in the registry is HKLM/Software/Microsoft/Office/Common/COM Compatibility/{CLSID}, where CLSID is the class identifier of the COM object. To enable the Office COM kill bit, you need to add the registry key, including the CLSID of the ActiveX control, and add the value of 0x00000400 to the Compatibility Flags REG_DWORD.

Controls you may want to consider putting onto the Office deny list:

• 
  Microsoft HTA Document 6.0 - 3050F5C8-98B5-11CF-BB82-00AA00BDCE0B

• 
  htmlfile - 25336920-03F9-11CF-8FD0-00AA00686F13

• 
  htmlfile_FullWindowEmbed - 25336921-03F9-11CF-8FD0-00AA00686F13

• 
  mhtmlfile - 3050F3D9-98B5-11CF-BB82-00AA00BDCE0B

• 
  Web Browswer Control - 8856F961-340A-11D0-A96B-00C04FD705A2

• 
  DHTMLEdit - 2D360200-FFF5-11d1-8d03-00a0c959bc0a

Change the way ActiveX controls are initialized

Office 2010 provides a setting that enables you to control the way ActiveX controls are initialized based on SFI, UFI, and safe mode parameters. SFI, UFI, and safe mode are parameters that developers can configure when they create ActiveX controls. ActiveX controls that are marked SFI use safe data sources to initialize. A safe data source is one that is trusted, known, and does not cause a security breach. Controls that are not marked SFI are considered UFI.

Safe mode is another security mechanism that developers can use to help ensure the safety of ActiveX controls. When a developer creates an ActiveX control that implements safe mode, the control can be initialized in two ways: in safe mode and in unsafe mode. When an ActiveX control is initialized in safe mode, certain restrictions that limit functionality are imposed on the control. Conversely, when an ActiveX control is initialized in unsafe mode, there are no restrictions on its functionality. For example, an ActiveX control that reads and writes files might only be able to read files if it is initialized in safe mode, and it might be able to read and write files when it is initialized in unsafe mode. Only ActiveX controls that are SFI can be initialized in safe mode. ActiveX controls that are UFI are always initialized in unsafe mode.

If the default initialization for ActiveX controls is insufficient for your organization but you do not want to disable ActiveX controls, use the following guidelines to determine how you can change the way ActiveX controls are initialized.

Setting name: ActiveX control initialization

• 
  Description: This setting specifies how ActiveX controls are initialized for all Office 2010 applications. This is a global setting and cannot be configured on a per-application basis. You can select one of six possible initialization security levels for this setting:

• • Security level 1   Regardless of how the control is marked, load it and use persistent values (if any). This setting prevents users from being prompted.

  • Security level 2   If the control is marked SFI, load the control in safe mode and use persistent values (if any). If the control is not marked SFI, load in unsafe mode with persistent values (if any), or use the default (first-time initialization) settings. This level resembles the default configuration, but unlike the default configuration this setting prevents users from being notified.

  • Security level 3   If the control is marked SFI, load the control in unsafe mode and use persistent values (if any). If the control is not marked SFI, prompt the user and advise them that it is marked unsafe. If the user decides No at the prompt, do not load the control. Otherwise, load it with default (first-time initialization) settings.

  • Security level 4   If the control is marked SFI, load the control in safe mode and use persistent values (if any). If the control is not marked SFI, prompt the user and advise them that it is marked unsafe. If the user decides No at the prompt, do not load the control. Otherwise, load it with default (first-time initialization) settings.

  • Security level 5   If the control is marked SFI, load the control in unsafe mode and use persistent values (if any). If the control is not marked SFI, prompt the user and advise them that it is marked unsafe. If the user decides No at the prompt, do not load the control. Otherwise, load it with persistent values.

  • Security level 6   If the control is marked SFI, load the control in safe mode and use persistent values (if any). If the control is not marked SFI, prompt the user and advise them that it is marked unsafe. If the user decides No at the prompt, do not load the control. Otherwise, load it with persistent values.

• 
  Impact: If a control is not marked SFI, the control could adversely affect a computer — or it could mean that the developers did not test the control in all situations and cannot know for sure whether it might be compromised in the future. In addition, some ActiveX controls do not respect the safe mode registry setting, and therefore might load persistent data even though you configure this setting so that ActiveX controls initialize in safe mode. Enabling this setting and selecting security level 2, 4, or 6 only increases security for ActiveX controls that are accurately marked as SFI. In situations that involve malicious or poorly designed code, an ActiveX control might be inaccurately marked as SFI.

• 
  Guidelines: Most organizations enable this setting and select security level 2, which uses the same initialization criteria as the default configuration but does not notify users in the Message Bar. Organizations that have a highly restrictive security environment typically disable this setting, which is the default configuration.

Related ActiveX control settings

Several other settings affect how ActiveX controls behave in Office 2010 applications. If you are modifying ActiveX control settings because you have a special security environment, you might want to evaluate the following settings:

• 
  Load controls in Forms3   This setting determines how ActiveX controls are initialized in UserForms.

• 
  Disable all Trust Bar notifications for security issues   This setting prevents users from seeing Message Bar warnings, including warnings about unsafe ActiveX controls.

See Also

Concepts

Security overview for Office 2010
Configure security for Office 2010

Other Resources

Office 2010 Security Resource Center on TechNet