Udostępnij za pośrednictwem

Plan security settings for ActiveX controls for Office 2013

  • Artykuł

 

Applies to: Office 365 ProPlus

Summary: Explains how to change settings to make Microsoft ActiveX controls safer in Office 2013 and how to Use Office 2013 Telemetry Dashboard to investigate ActiveX control warnings.

Audience: IT Professionals

Active content threats are common security threats. Typical threat risks include ActiveX controls, add-ins, and VBA macros. These threat vulnerabilities can be exploited by programmers who write malicious code or create malicious programs that then run on users' computers. Active content threats pose a potential risk to any size organization. This article describes ways that Office 2013 can help you make ActiveX controls safer. Add-in and VBA macro safety are covered in other articles.

Office 2013 provides several security settings that let you change the way ActiveX controls behave and change how users are notified about potentially unsafe ActiveX controls. By configuring these settings, you can:

  • Disable ActiveX controls

  • Change 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 2013 Administrative Templates, see Configure security by using OCT or Group Policy for Office 2013.

Roadmap arrow for guide to Office security.

This article is part of the Guide to Office 2013 security. Use the roadmap as a starting point for articles, downloads, posters, and videos that help you assess Office 2013 security.

Are you looking for security information about individual Office 2013 applications? You can find this information by searching for “2013 security” on Office.com.

In this article:

  • Plan settings for ActiveX controls in Office 2013

  • Disable ActiveX controls in Office 2013

  • Change the way ActiveX controls are initialized in Office 2013

  • Related ActiveX control settings for Office 2013

Plan settings for ActiveX controls in Office 2013

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 a trusted document. By default, trusted ActiveX controls are loaded in safe mode with persistent values and users aren’t notified that the ActiveX controls are loaded. 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 doesn’t contain a VBA project, the ActiveX control is loaded in safe mode with persistent values. The Message Bar doesn’t appear and users aren’t 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 doesn’t contain a VBA project, users are notified in the Message Bar that ActiveX controls are disabled. But, users can click or tap 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. But, users can select 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.

Important

If a kill bit is set in the registry for an ActiveX control, the control isn’t loaded and can’t be loaded under any circumstance. In addition, the Message Bar doesn’t appear and users aren’t notified about the presence of the ActiveX control.

Use Office 2013 Telemetry Dashboard to see ActiveX control data

You can easily get some visibility into ActiveX control usage in your organization by reviewing data in Office 2013 Telemetry Dashboard. There is a built-in report named “Inventory” that collects and displays unique instance data about each Office solution that is monitored. This includes use of ActiveX controls in Office documents.

The following procedure assumes that you have already deployed and configured Office Telemetry Dashboard. For information about Office Telemetry Dashboard in general, see Overview of Office Telemetry. For details about how to deploy Office Telemetry, see Deploy Telemetry Dashboard.

To view ActiveX control usage in an Office 2013 Telemetry Dashboard report

  1. Open Telemetry Dashboard and connect to your telemetry database.

  2. In the navigation pane of Telemetry Dashboard, select Custom report.

  3. When the Custom report page opens, choose Create custom report.

  4. In the PivotTable Fields list, Inventory section, find and select Has ActiveX. Review the report for any ActiveX related warnings. If you need to investigate further, select additional fields in the Inventory table.

  5. Save the data if you’d like, then close the Telemetry Dashboard.

Disable ActiveX controls in Office 2013

Office 2013 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. But, the control is disabled and no action occurs if a user selects the symbol. When you disable ActiveX controls, users aren’t notified that the controls are disabled.

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

Group Policy setting name: Disable All ActiveX

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

  • Impact: If you enable this setting, ActiveX controls do not initialize and users aren’t notified that the ActiveX controls are disabled. Also, users can’t insert ActiveX controls into documents. ActiveX controls can provide additional functionality in documents. Therefore, disabling them can reduce functionality for users. You should make sure that users are aware that this setting is enabled, because they aren’t notified by the application that ActiveX controls are 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.

Note

If you enable this setting, ActiveX controls are disabled in files that are saved in trusted locations.

You can also use the Office COM kill bit, which was introduced in Office 2013, to prevent specific COM objects from running within Office 2013 applications. . This includes ActiveX controls. This capability was available in the 2007 Office system. But, it was dependent on the Internet Explorer ActiveX kill bit setting. Now, in Office 2013, you can use the registry to independently control which COM objects won’t be able to run when they use Office 2013. If, for example, the kill bit is set for the same ActiveX control in both 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 2013 security issue.

Warning

We do not recommend unkilling a COM object. If you undo the kill action, you might create security vulnerabilities. The kill bit is typically set for a reason that might be critical, and because of this, you must use extreme care when you unkill an ActiveX control.

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. This is necessary when an Office COM kill bit has been applied to the CLSID of an ActiveX control to mitigate a security threat. Office 2013 supports using the AlternateCLSID only together 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.

Important

Don’t change registry settings unless you are highly experienced and understand the ramifications. Serious problems might occur if you change the registry incorrectly. For added protection, back up the registry before you change it. Then, you can restore the registry if a problem occurs.

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 must add the registry key, including the CLSID of the ActiveX control, and add the value of 0x00000400 to the Compatibility Flags REG_DWORD.

Note

The behavior of the kill bit (both Internet Explorer and Office COM) can be affected by enabling COM categorization in Office 2013. For more information, see Plan COM object categorization settings for Office 2013.

Controls that 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 in Office 2013

Office 2013 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 when they are initialized. A safe data source is one that is trusted, known, and doesn’t cause a security breach. Controls that aren’t 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 or 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.

Group Policy setting name: ActiveX Control Initialization

  • Description: This setting specifies how ActiveX controls are initialized for all Office 2013 applications. This is a global setting and can’t 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 isn’t 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 isn’t 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 isn’t 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 isn’t 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 isn’t 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 isn’t marked SFI, the control could adversely affect a computer, or it could mean that the developers didn’t test the control in all situations and can’t 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 might load persistent data even though you configure this setting. In such cases, ActiveX controls initialize in safe mode. If you enable this setting and select security level 2, 4, or 6, security is increased only 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 doesn’t notify users in the Message Bar. Organizations that have a highly restrictive security environment typically disable this setting. Disabled is the default configuration.

Several other settings affect how ActiveX controls behave in Office 2013 applications. If you are changing 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.

Note

For the latest information about policy settings, refer to the Excel 2013 workbook, Office2013GroupPolicyAndOCTSettings_Reference.xls, which is included in the Office 2013 Administrative Template files. For more information, see the Office 2013 Administrative Template files (ADMX/ADML) and Office Customization Tool TechNet article.

See also

Guide to Office 2013 security
Overview of security in Office 2013
Configure security by using OCT or Group Policy for Office 2013
Understand security threats and countermeasures for Office 2013
Plan security settings for add-ins for Office 2013
Plan security settings for VBA macros for Office 2013