ActiveX: An Overview
by Phil Cox
<pcc@ntsinc.com>
Phil is a member of the Computer Incident Advisory Capability (CIAC) for the Department of Energy. He also consults and writes on issues bridging the gap between UNIX and Windows NT.
Recently, while describing the security model of downloaded Java applets and the Virtual Machine implementation in various clients, I was asked if the ActiveX model was similar. I realized at that point that I knew little about the model, except to say "don't allow it from untrusted sources." I was motivated to get a better understanding of the technology referred to as ActiveX. This article is a brief of what I have learned and is an attempt to give you a basic understanding of ActiveX technology and how it is used on the Internet.
What ActiveX Is
ActiveX is not an individual tool or set of packages; it is a technology. An extension to Microsoft's Object Linking and Embedding (OLE) technology, it was originally called OCX (OLE control extension) [1]. It includes a wide range of components: ActiveX Controls, ActiveScripts, ActiveMovies, ActiveVRML, and more to come. ActiveX is often compared to Java. Although there are similarities, the overall methodology is quite different. The actual portion of ActiveX that is similar (but not identical) to the Java content over the Internet (Java Applets) is the ActiveX Control. This article covers the utilization of ActiveX Controls for Internet content delivery.
Comparing Java and ActiveX Controls
Java (and writing applets) is relatively straightforward for Internet delivery purposes. You write some code, compile it to bytecode (a class file), and reference that class file in an HTML document. The client then "hits" the Web page, and the browser automatically [2] downloads the class file. The Virtual Machine implementation in the client will then execute the applet in a "sandbox" [3]. Unlike Java applets, ActiveX Controls do not run in a sandbox after download. The ActiveX Control runs in the user context and has complete access to any resource the user has access to. Remember that these controls are an evolved form of OLE, thus allowing the same programming functionality across the network as you have on the local machine.
Thus, when you enable ActiveX Controls, you allow full access to the machine and network to which it is attached. Contrast this with Java, which provides only a limited set of functionality for downloaded bytecode. The functionality is tremendous, but the security ramifications are severe. Another obvious (yet needs to be mentioned) point is the development platform used for the different technologies. Java applets are written in the Java language, whereas ActiveX Controls are written in many different languages (Visual Basic and Visual C++ seem to be the most popular). I can foresee an ActiveX Control written in the Java language.
How You Get the Controls
ActiveX Controls are embedded in HTML documents with the <OBJECT> tag like this:
<HTML><HEAD> <TITLE>Page with ActiveX Control</TITLE> </HEAD><BODY>
<OBJECT ID="filename[.{ocx,cab,inf}]" width=50
height=25
CODEBASE="http://example.microsoft.com/circ3.cab#Version=1,0,0,
0"
CLASSID="CLSID:9DBAFCCF-592F-101B-85CE-00608CEC297B">
<PARAM NAME="_Version" VALUE="12345">
<PARAM NAME="_ExtentX" VALUE="2646">
<PARAM NAME="_ExtentY" VALUE="1323">
<PARAM NAME="_StockProps" VALUE="15">
<PARAM NAME="name" VALUE="value">
....
<PARAM NAME="name" VALUE="value"> </OBJECT>
</BODY></HEAD>
The attributes in the <OBJECT> tag define the specific Control to be used. The extension on the ID attribute tells us the type of Control we are using. It is a filename or URL; it defaults to OCX if no extension is listed.
OCX is the "portable executable" format, which sends the Control to the client in its executable format. The INF extension is used for interactive installs over the network and allows selective installation of one or more of the desired Controls.
When you hit a page with an INF file, some type of install screen is presented to you (probably something similar to a Microsoft setup screen). The CAB (component download file) enables packaging of multiple Controls in a single download file. They are larger, but compressible, and require real time to unpack and set up on the client. Creating CABs is complex and can cause "perception delay" from a user's point of view while waiting for the unpack and setup to complete.
The advantage of the INF type file is that the downloading of the actual Controls occurs only if selected during the setup routine. The CAB file downloads all the Controls and the INF file as a "packaged" file and then installs only the ones you select. The <PARAM> tags determine the Control configuration when it is displayed to the user. The CODEBASE attribute specifies the location of the listed control. The CLASSID is a unique identifier for the control listed. It describes the version and other information about the control listed in the ID attribute.
How It Works
The client application (currently certain WWW browsers that support ActiveX Controls [4]) uses the WinAPI call CoGetClassObjectFromURL. When the browser sees an <OBJECT> tag, it parses out the CLASSID, CODEBASE, and _Version parameters. It passes these parameters to the CoGetClassObjectFromURL system call, which downloads, verifies, and installs the control if necessary. The API determines if the CLASSID just parsed is currently in the registry (HKEY_CLASSES_ROOT\CLSID). If installed, the version number is checked, and the local copy is loaded if the version numbers match. If the version is not current or the control is not installed, the object is downloaded from the CODEBASE location and then loaded. Once the control is loaded, control is passed back to the client application.
The Download
Once the client completes the download and (if needed) decompresses the file, the client calls the Windows Trust Provider Service function, WinVerifyTrust. This service looks for a "certificate" (pkcs#7 and X.509) inside the Control. The certificate contains the author's name, public key, and encrypted digest of the Control's contents. WinVerifyTrust then validates the certificate (in one of two ways), if it exists.
If the certificate is in the "trusted list," then the Control is accepted with no user intervention. If not, the WinVerifyTrust will traverse the certificate hierarchical tree to the root certificate or first certificate on the "trusted list" that is in that tree. It then verifies the root certificate and the certificate on the Control itself. If the certificate is legitimate and on the "trusted list," the Control is automatically loaded. Otherwise the user is prompted [5] with a message asking if they want to accept the "untrusted" Control or not. The user chooses whether to install the Control (and optionally add the newly accepted certificate to the "trusted list"). This would enable future Controls signed with that key to be installed with no user intervention. The actual Control files are then installed in a folder named OCCACHE, which is located on the local computer.
Security Issues
The are several security issues with ActiveX Controls. First is the issue of complete resource access by the downloaded Control. Although this is run in the user context, there is still potential for significant damage to be wrought by a malicious Control, especially on Windows95. The other issue is the fact that a major portion of the security is based on the "intent" of the Control's author/signer. Along with "intent" is the issue of untrusted code. Microsoft touts certificates as the total solution for these issues. The problem with that stance is that it does not scale in a nontechnical user base. A nontechnical user would be required to understand the technology well enough to accept code from a specific source as trusted. Some tools are coming out that will allow admins to assist in this effort, but they are still subvertable by the user. The security solutions for ActiveX Controls are not complete by any means, but they are a start. With proper client configuration and user training, you can utilize this technology in a secure manner.
Conclusion
ActiveX is a technology that seems to be here for the long run. It has some very useful features and is a stable platform for development. Although the technology is very appealing, the security issues associated with it are significant. The solutions to these problems, regardless of what Microsoft would have us believe, are not straightforward (this applies to Java as well). With ActiveX, and all new technology, first understand it, then implement it if you deem it a necessity; otherwise wait for it to mature.
Notes:
[1] More information on ActiveX controls can be found in the OLE Control and Control Container Guidelines version 2.0 under the InetSDK\Specs folder of the ActiveX SDK installation.
[2] This is, of course, all dependent on the settings in the browser.
[3] A sandbox is a restricted area in which a program runs. It limits the resources that a given program can access. This is to prevent malicious or inadvertent applet access to system resources that could cause a security problem. The enforcement of this is completely dependent on the vendor's Virtual Machine implementation, and not the actual Java language itself.
[4] These now are Microsoft Internet Explorer natively and Netscape with the ScriptActive plugin from <www.ncompasslabs.com>.
[5] There are different security settings (and thus different promptings), as well. If you have selected no security, then it considers all controls as trusted and automatically installs them.
Need help? 
Issue index