ActiveX Controls and Office Security


Microsoft ActiveX controls can pose a security risk in some situations because the controls can be used to distribute malicious code or viruses, especially on computers where appropriate security-related settings are not in place.

For instance, if an ActiveX control that is not signed is downloaded from a Web page to a computer where High or Medium security is not enabled through Microsoft Internet Explorer, the control will run without warning. If that control contains malicious code capable of introducing a virus or some other form of attack, the computer and data could be damaged.

The following information describes what an ActiveX control is and how to help defend against some of the problems that might be introduced when a control is installed or used without appropriate examination.

What is an ActiveX control?

An ActiveX control is essentially an OLE or Component Object Model (COM) object. It is a self-registering program or control; that is, it adds registry entries for itself automatically the first time it is run.

An ActiveX control can be as simple as a text box, as complex as an entire dialog, and in some cases as complex as a small application. ActiveX controls are used as controls or dialogs for Internet Web sites, as add-ins to major applications from third-party vendors, and as plug-in utilities. Therefore, ActiveX is synonymous with Java, Netscape plug-ins, and scripting. However, the advantage of ActiveX over these other programming options is that ActiveX controls can also be used in applications written in different programming languages, including all of the Microsoft programming and database languages.

ActiveX controls are not standalone solutions. They can only be run from within host applications, such as Internet Explorer, a Microsoft Visual Basic application, Visual C++ development system, Visual Basic for Applications, and so on. ActiveX controls facilitate the distribution of specialized controls over networks and the integration of those controls within Web browsers. This includes the ability of the control to identify itself to applications that use ActiveX controls.

ActiveX controls can be scripted from Web pages. This means you can create (or buy) an ActiveX control to provide a control for a user interface or graphics device interface (GDI) element. Once created, you can use a scripting language such as Visual Basic Scripting Edition (VBScript) or JavaScript™ to use the control. Your script instructs the control how to work.

Security settings related to unsafe ActiveX initialization

Four security settings are available for use with ActiveX controls within the Custom Installation Wizard and Custom Maintenance Wizard. These settings are found on the Specify Office Security Settings of each wizard:

  • Do not configure The transform or configuration maintenance file does not modify the setting specified on the user’s computer. New applications are installed with the default setting, which is Prompt user to use persisted data.

  • Prompt user to use control defaults The user is warned before an application initiates ActiveX controls that might be unsafe. If the user trusts the source of the document, the control is initialized using its default settings. This setting disables the ability of the control to use and save persisted data. It forces the control to start up using its default settings. This reduces the possibility of an errant setting or deliberate attack from causing a problem on the computer. When this setting is enabled, the user is warned when the control is started but the user has the option of ignoring the setting.

  • Prompt user to use persisted data The user is warned before an application initiates ActiveX controls that might be unsafe. If the user trusts the source of the document, the control is initialized using the previously stored data associated with the control. Potentially, the ActiveX control could be used to introduce a virus if this setting is used.

  • Do not prompt This allows the control to run in its default configuration. If this setting is used, it allows the ActiveX control to use stored information between sessions and does not present a dialog to the user prompting them for how the control should be activated.

Use of these settings in the Custom Installation Wizard or Custom Maintenance Wizard provides administrators extra control over how potentially unsafe ActiveX controls run on users’ computers. More information about the registry entry for this security feature is available in “How Policies Work” in Chapter 26, “Using Security-related Policies.”

Code signing

Because an ActiveX control allows access to root operating system services, it needs something to assure that it is not a malicious program. This assurance is provided by Microsoft Authenticode, which allows an ActiveX developer the option to digitally vouch for his or her code—also known as code signing. Code signing, when used, allows users the ability to identify the author of any program before allowing it to either be installed or executed on their computer.

If you have used unsigned or unmarked ActiveX controls with Internet Explorer, you may have seen dialog boxes declaring the:

  • Control is not signed

  • Control is not safe for initializing

  • Control is not safe for scripting

ActiveX controls downloaded automatically over the Internet can do anything a regular program can do—such as deleting files or registry entries. Java addresses this problem by limiting what a Java applet can do to files and the registry. Java cannot, for instance, gain direct access to the computer’s file system. ActiveX controls take a different approach: they demand positive identification of the author of the control, verification that the control was not modified since it was code signed, and confirmation that it is a safe control. Because of this approach, ActiveX controls can use the full power of the operating system but rely on the strict method of obtaining a certificate of trust from a certificate authority to assure whether the control is safe to install and use.

Installing an ActiveX control

If a user attempts to install and run an unregistered ActiveX control from the Internet, Internet Explorer checks to see if the control was digitally signed. If the ActiveX (OCX) file has a certificate of trust that is already trusted on the user’s computer, it is accepted, installed, and registered. Depending on the security level set for use by Internet Explorer, if the certificate of trust is unknown to the system, the user is presented with the option to install the control. If the user accepts the option to install the control, the certificate of trust associated with the control is noted in the registry.

If the ActiveX (OCX) file is installed as part of an application from a CD or other locally opened resource, there is no examination of the certificate (if there is one) associated with the OCX file. It is assumed the file is associated with an application that has been deemed safe to install by the user, and it is installed and registered without challenge.

Once the control is installed on a user’s system, the control no longer invokes code-signing dialog boxes when started. After a control is installed, it is considered safe even if it was not digitally signed originally.

Signing an ActiveX control

To digitally sign a control, you will need to obtain a certificate from a certificate authority, which can be located by using the term “certificate authority” in a search engine. Follow the directions for signing controls from the certificate authority you decide to use.

Certificate authorities provide different levels of trust certificates, ranging from individual certificates to corporate-wide certificates. Check each certificate authority’s Web site to determine if they have one that is right for you.

Determining if an ActiveX control is safe

Since the digital signature of an ActiveX control stays with the file it was attached to, there is a permanent evidence of the designed intent of the control by the developers. However, this evidence does not account for all possible conditions the control may be used in but were never tested for.

ActiveX controls marked as safe are supposed to be safe in all possible conditions. So a control marked as safe for scripting (SFS) or safe for initialization (SFI) must be written to protect itself from any unpredictable results a script author might unintentionally create when scripting the control. While it is relatively easy for a programmer to create a control with adequate guards to avoid misuse, it is impossible to guarantee that the control is always safe when used with scripting created by another author or programmer.

If a control is marked safe for initializing or safe for scripting, the developers are claiming that no matter what values are used to initialize the control, it will not do anything to damage a user’s system or compromise the user’s security when the control is initialized in any way.

The developer of an ActiveX control should take extra care to ensure that a control is in fact safe before it is marked as safe. For example, each ActiveX control, at a minimum, should be evaluated for the following issues:

  • It does not over-index arrays or otherwise manipulate memory incorrectly, thereby causing a memory leak or corrupt memory region.

  • It validates and corrects all input, including initialization, method parameters, and property setting functions (implements acceptable I/O validation and defense methods).

  • It does not misuse any data about, or provided by, the user.

  • It was tested in a variety of circumstances.




Microsoft Office 2003 Resource Kit 2003
Microsoft Office 2003 Editions Resource Kit (Pro-Resource Kit)
ISBN: 0735618801
EAN: 2147483647
Year: 2004
Pages: 196

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net