Designing Safe ActiveX Controls

Any Microsoft® ActiveX® control to be deployed and used with Microsoft® Internet Explorer should be conceived and designed with object safety in mind.

Safe design is important because many ActiveX controls are initialized with persistent data (either local or remote), and most ActiveX controls are scriptable (they support a set of methods, events, and properties). Both initialization with persistent data and scripting require safeguards to ensure that security is not violated.

Developers should mark their ActiveX controls safe for initialization and scripting only after thoroughly reviewing the control for security as outlined in this article. Developers should also digitally sign their ActiveX controls. Digital signing tells users where the control came from and verifies that the control hasn't been tampered with since its publication.

This article contains information about the following topics:

Types of Object Safety

There are two variations of object safety that usually, but don't always, go together:

"Safe for untrusted data" asserts that the control is safe for any possible arguments (PARAM tags of an OBJECT element).
"Safe for scripting" asserts that the control is safe for any possible use of its properties, methods, and events.

Most ActiveX controls for use on Web pages should be safe in both ways to avoid the security restrictions.

It is important to make the safety assessment accurately reflect the control's actual behavior. If a control is designed to do fundamentally unsafe things—such as expose private data or delete data—then the security restrictions for unsafe controls rightfully apply to it. These "unsafe" controls can be put on trusted Web pages in the "trusted sites zone" and run with the security appropriate to that zone. Forcing an unsafe control to be safe so it can run on less-than-trusted Web pages is an invitation to a security problem.

ActiveX Control Safety Checklist

Safety of the control is ultimately a subjective judgment, but as a general rule, "safe" means that none of the following undesirable effects will result from any conceivable use of the control.

Accessing information about the local computer or user.
Exposing private information on the local computer or network.
Modifying or destroying information on the local computer or network.
Faulting of the control and potentially crashing the browser.
Consuming excessive time or resources such as memory.
Executing potentially damaging system calls, including executing files.
Using the control in a deceptive manner and causing unexpected results.

Fulfilling Safety Requirements

Consider the following questions before marking a control as safe. The same questions apply to both untrusted data and scripting.

What files can the control potentially access?

The ability to create files can be used to put content into the trusted local computer file system, possibly overwriting valuable data.
Any arguments that allow arbitrary file paths to be specified are particularly suspect as potentially allowing access to private information.
Writing excessive amounts of data even to restricted sets of files can use up disk space.

Is registry access possible?

Access to even limited parts of the registry could reveal information that should be kept private.
Writing large amounts of data to the registry could waste resources or possibly corrupt the system.

What system calls can the control be made to do?

Executing code or arbitrary shell commands—such as FORMAT—is particularly dangerous.
Think about how any system calls might be used by a malicious page, especially those calls with arguments that can be influenced by an untrusted data PARAM tag or script invocation.

Using ActiveX Controls Safely in an Enterprise Intranet Environment

Using Internet Explorer 4.0 Security Zones, it is possible to configure the browser to only download or run ActiveX Controls located within the enterprise—in other words, the intranet. When a control is downloaded and installed on the local system, however, the location of the original download is no longer available, and the control is available for use on any page that might reference its CLSID. Thus, be aware of the possibility that an Internet page might reference a control intended only for the intranet. There are several approaches to handling this issue.

If the ActiveX controls are safe for untrusted data and for scripting, supporting IObjectSafety and requiring only safe controls is the simplest solution. Controls that are truly safe should not be usable to break security, even by an untrusted Internet page.

To prevent an ActiveX control from being used on pages other than the one on which it is intended to be used, the control can check the context in which it is instantiated. That is, a control can access the DHTML Object Model to get the URL of the page instantiating it. The location properties of the document object return the URL of the page in which the control is embedded. For instance, an ActiveX control could be designed to run only in the "http://admin" intranet area. When the URL of the containing document begins with a different protocol and host name, it could run with reduced functionality or otherwise completely disable itself.

Be aware that some important controls might be inherently unsafe for scripting. They include tools to aid system configuration or installation. To safely use these ActiveX Controls in the intranet environment, it is important to guarantee:

That these controls be used only by intranet pages and cannot be reused by other, untrusted security zones.
That any intranet pages that use these controls do so in the intended manner and with appropriate safeguards.

ActiveX Controls, by default, are not safe for scripting. A system administrator can configure a custom security policy to override object safety for a specific intranet zone. Controls that are not marked as safe will run only in pages from this zone. In fact, it is possible to restrict a control to run only in a designated secure zone by explicitly not marking the control as safe. Of course the Internet zone should never be set to override object safety.

Additional Safety Considerations

Because any control can be used by any page that happens to know its CLSID, think about how the control might be reused maliciously in a completely unrelated page. Would the user possibly be tricked by seeing the familiar control out of context?

Be sure the control won't loop infinitely or crash when given bad data or arguments.

Can the control be made to call other objects on the page, including Java applets? The Microsoft virtual machine (VM) called from native code in the control could attribute greater permissions to the control than script on the page has. If the script can manipulate the control to call the Microsoft VM for it, an indirect security attack is possible.

Can the control tunnel out of the frame in which it is hosted and access content in another frame? The data accessed could potentially violate the privacy of the user.

It is important for a safe ActiveX control to check all inputs and guard against buffer overrun. If an input string is copied into a fixed-length buffer without checking its length first, it is possible for a malicious caller to provide an overly long string that would go beyond the length of the allocated buffer, overwriting other information in an unintended way. In some cases, these bugs can be exploited to get the control to perform unsafe operations it was not designed to do. As the author of an ActiveX control, you need to be vigilant. Never assume that a certain input will conform to certain requirements. Always check the data to avoid these attacks. All inputs should have maximum sizes, and controls should be tested to perform safely, even with inputs that are beyond specifications.

Designing Safe ActiveX Controls

Types of Object Safety

ActiveX Control Safety Checklist

Fulfilling Safety Requirements

Using ActiveX Controls Safely in an Enterprise Intranet Environment

Additional Safety Considerations

Related Topics