This documentation is archived and is not being maintained.
The ActiveX Installer Service in Windows Vista
Rob Campbell and Joel Yoker
At a Glance:
- Common challenges with ActiveX controls
- How ActiveX controls are installed
- Dangerous permissions
- A safer process in Windows Vista
It’s always the same story. To substantially enhance your security, you have to give up some freedom or flexibility. If your environment is like most organizations, you have a very strong desire to harden the desktop operating system in an effort to provide a more secure computing
environment for your end users. IT administrators typically approach the task of securing the desktop by employing a combination of security policy settings, user permissions, file and registry access control lists (ACLs), and system service restrictions.
One common hurdle in the development of a secure desktop environment is how to mitigate the threats surrounding malicious ActiveX® controls while still providing an appropriate level of application compatibility in your environment. This has been a challenge with desktop operating systems for many years. Fortunately, the new ActiveX control Installer Service (AxIS) in Windows Vista™ addresses concerns specific to the management of ActiveX controls in corporate environments. AxIS provides a simple and manageable way for standard users, who wouldn’t ordinarily be permitted to install ActiveX controls, to install them from approved Web sites. Group Policy control over AxIS allows IT administrators to determine which controls users can install, regardless of which permissions they have.
In this article, we take a look at the administrative challenges surrounding ActiveX controls, how these issues were addressed in previous versions of Windows®, and how AxIS in Windows Vista provides a unique and efficient way to manage the installation of ActiveX controls.
What Is an ActiveX Control?
An ActiveX control is a piece of executable code (typically an OCX file packaged within a Cabinet file) that is installed and invoked by the user via Internet Explorer®. Web developers create ActiveX controls to add functionality to their Web applications that they can’t easily achieve with standard HTML or a simple script.
A key feature of ActiveX controls is their simple "download and execute" deployment model. ActiveX controls are installed and invoked via the HTML object tag, which has an attribute called CODEBASE that tells Internet Explorer (using a URL) where to get the control if it isn’t already installed on the user’s machine. In that case, Internet Explorer downloads the associated installation package, performs trust verification on the object, and prompts the user for installation permission via the Internet Explorer Information Bar (shown in Figure 1). During the installation, the control is registered and invoked by the rendering page. Once installed, any standard user can invoke the control. This simple mechanism of distribution and execution is meant to provide developers with an easy way to distribute their components to users of their Web application. The problem with this distribution method is that standard users cannot directly install ActiveX controls because administrative privileges are required to complete the installation.
Figure 1 ActiveX Control installation information bar
When ActiveX controls were first introduced in Internet Explorer 4.0, the Internet seemed a much friendlier place. Today, executable code distributed over the Web can represent a significant threat, so Windows only allows users with local administrator rights to install ActiveX controls, and then only if the installation is approved according to policy settings. Once an ActiveX control is installed by an administrator, any user of the system can invoke it. This behavior is facilitated by a set of file and registry ACLs in Windows. While this prevents standard users from installing ActiveX controls, it does not mitigate the risks to the local administrators and standard users (with modified default permissions) who install them.
While the default protection in Windows—allowing only those with administrative privileges to perform installation—addresses ActiveX controls at the individual level, it does not address how to manage these across a large organization. A common challenge in corporate environments is how to permit the use of ActiveX controls trusted by the IT organization while mitigating potential threats delivered through external, non-trusted controls. At the end of the day, the decision to install a particular ActiveX control, good or bad, is often left up to an individual user, depending on their rights. To counteract threats, some organizations block all ActiveX controls, while others allow end-user installation but attempt to manage any malware that is installed.
Another way to prevent installation of bad controls is to enforce the restricted rights of the standard user and have the IT administrator preinstall all required controls on the desktop platform. This is effective if the ActiveX controls in use are relatively static in nature, are modified using a scheduled release process in conjunction with desktop updates, or if the organization uses a software distribution mechanism such as Systems Management Server. However, ongoing management, the ever-changing needs of internal application developers, and dependencies on external controls will continue to be a challenge with these approaches.
In instances where users have administrative privileges, the problem is different; it involves keeping these users from installing controls that are not approved. In these cases, the right of the end user to install ActiveX controls is assumed since the user has administrative privileges. (Note that having end users run as local administrators is a posture that represents high risk to the organization and is not recommended for most corporate environments.)
One solution is to have an internal Internet Component Download Server that hosts the approved controls. This solution requires the modification of the CodeBaseSearchPath string in the client’s registry. Normally, when an object tag containing the CODEBASE attribute is found in the requested HTML page, Windows clients are directed to the locations specified in the CodeBaseSearchPath data. By default, this registry string contains the CODEBASE keyword and Internet URLs for the ActiveX control gallery. To implement an Internet Component Download Server, you need to replace the default data in the CodeBaseSearchPath with the URL of the internal server where you’ll host controls approved by your organization. Like the previous approach, this solution requires ongoing management and carries the cost and complexity of hosting an internal server for ActiveX controls.
There are other solutions, such as modifying Internet Explorer zone URLActions, specifying administrator-approved controls through Group Policy, and blocking the installation of all controls at the perimeter through firewall rules. But, as you can see, all these approaches have their problems and many are eventually abandoned due to lack of flexibility. What’s worse, some of these solutions still require the user to have administrative rights. In the end, these modifications attempt to address portions of the problem, such as controlling (or blocking) where ActiveX controls come from, where they can be invoked from, and so on; however, these solutions do not mitigate the fundamental problem that users without administrator rights cannot install ActiveX controls.
What Can AxIS Do for You?
AxIS in Windows Vista allows the corporate administrator to manage ActiveX controls while maintaining a strong security posture by having users run as standard user with default file system settings. AxIS provides Group Policy options to configure trusted sources of ActiveX controls and a broker process to install controls from those trusted sources on behalf of standard users. The key benefit is that you can maintain a non-administrative security posture on user workstations along with centralized administrative control. AxIS relies on the IT administrator to identify trusted sources (typically Internet or intranet URLs) of ActiveX controls. When an object tag directs Internet Explorer to invoke a control, AxIS takes the following steps:
- Checks that the control is installed. If not, it must be installed prior to use.
- Checks the AxIS policy setting to verify if the control is from a trusted source. The specific check matches the host name of the URL specified in the CODEBASE attribute of the object tag against the list of trusted locations specified in policy.
- Downloads and installs the control on the user’s behalf.
If the host name of the source URL is not listed in the AxIS policy setting, the normal User Account Control (UAC) prompt will be invoked, requiring administrative rights to complete the installation. In addition, AxIS will log an event with ID 4097 in the Application event log from source AxInstallService outlining the attempted ActiveX control installation, along with the specific download path to the control. An example of the 4097 event is illustrated in Figure 2. The data from this event log entry can be used by the corporate administrator to modify Group Policy, allowing the control to be installed by AxIS on subsequent visits to the Web site.
Figure 2 4097 AxInstallService event
AxIS is an optional component that comes with the Business, Enterprise, and Ultimate SKUs of Windows Vista, and can be enabled through an unattended option or through the Control Panel dialog box (Programs | Programs and Features | Turn Windows features on or off), as shown in Figure 3. Once enabled, AxIS walks through the steps outlined above each time a control is requested by Internet Explorer.
Figure 3 Enabling AxIS in Control Panel
The ability to attach tasks to events in Windows Vista provides an easy way for an administrator to receive a notification from the AxIS service, such as when the installation of an ActiveX control is blocked. It is important to note that it cannot always be assumed that the ActiveX control will be installed from the same URL host name that the end user is accessing from his Web site. For this reason, the information provided by the AxInstallService 4097 (attempted installation) event can prove incredibly useful in identifying the host from which the control is attempting to be installed.
With the information you get from the event, you can configure the trusted location in Group Policy. AxIS settings in Local or Group Policy can be found in the Computer Configuration settings (as you can see in Figure 4). The Approved Installation Sites for ActiveX Controls policy setting allows you to specify host URLs of trusted locations (see Figure 5). The approved site setting requires two pieces of information—where the ActiveX control may be installed from and the behavior of the installation.
Figure 4 Settings in Group Policy Object Editor
Figure 5 AxIS-approved installation sites
First, as mentioned before, a host URL is required to indicate the trusted location of the control. Unlike previous solutions, which required knowing the CLSID of the control (which often changes when controls are revised by their developers), AxIS allows for any control to be installed from the trusted location, reducing the overall administrative burden. The second piece of information is a comma-delimited string of four values, each dictating the behavior of the ActiveX control download experience. The values specify four properties: TPSSignedControl, SignedControl, UnsignedControl, and ServerCertificatePolicy. The first two properties (TPSSignedControl and SignedControl) can have one of three values: 0, 1, or 2. These values are similar to the values found in URLAction settings. A value of 0 prevents the control from being installed, a value of 1 causes the user to be prompted for permission to install, and a value of 2 causes the control to be silently installed on the user’s behalf. Unsigned controls cannot be installed silently and therefore the UnsignedControl value can only be 0 or 1. Note that if no policy is specified, the default values of 2, 1, and 0 are used.
The final property specifies the behavior of the installation based upon the certificate settings of the signed settings control. Like most SSL sites, certificates must pass a set of security tests to ensure that the certificate is valid. Invalid certificate properties are sometimes the reality of real-world signed ActiveX control implementation. Through its configuration, AxIS allows administrators to mitigate invalid information that is sometimes presented by certificates on a URL-by-URL basis. The final property is represented as a bitmasked combination of the values shown in Figure 6.
|0x00001000||Ignore an invalid canonical name (CN) in the certificate.|
|0x00000100||Ignore unknown certificate authorities.|
|0x00002000||Ignore an invalid certificate date.|
|0x00000200||Ignore wrong certificate usage.|
The default setting is 0, meaning all security checks must pass before AxIS completes the installation. The combination of the host setting and these four values are specified in the policy setting, as seen in Figure 7.
Figure 7 Approved AxIS host URLs
AxIS allows you to configure Group Policy to control which ActiveX controls users can install without requiring administrative privileges or complex configurations. Control at this level could be challenging in previous versions of Windows, and previously available solutions often came with serious limitations or increased management overhead. AxIS provides organizations with another tool toward taking a least-privilege approach to end user rights on desktop systems, allowing the implementation of a standard user model where end users do not require administrative privileges. Windows Vista places the IT administrator back in the driver’s seat by having the choice of which ActiveX controls are trusted within the corporate environment determined the organization, not the end user.