Microsoft Office 2003 Editions Resource Kit (Pro-Resource Kit)

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:

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:

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:

Related

Категории