10.6 ActiveX controls

Unlike Java, which is a programming language of its own, the term ActiveX was coined by Microsoft to refer to a repackaging of some existing technologies. More specifically , ActiveX is a stripped-down version of Microsoft s object linking and embedding (OLE) and component object model (COM) architectures, two highly successful Windows programming components that allow multiple programs to interact, exchange data, and share each other s windows . As such, ActiveX is a system and a corresponding API for downloading executable code over the Internet. The code is bundled into a single file called ActiveX control . In general, a file carrying an ActiveX control has the extension .ocx.

ActiveX controls are small programs that can be written in any programming language, including, for example, C, C++, Visual Basic, or Java. They are automatically downloaded and installed as needed, then automatically deleted when no longer needed. Consequently, an ActiveX control is conceptually similar to a plug-in (as discussed in Section 10.3). In spite of the conceptual similarities, there are, however, also two fundamental differences between ActiveX controls and plug-ins:

Plug-ins are usually used to extend a browser so that it can accommodate a new document type, whereas most ActiveX controls used to date have brought a new functionality to a specific Web site.
Plug-ins must be manually installed, whereas ActiveX controls are downloaded and run automatically.

Both differences lead to a situation in which ActiveX controls behave like Java applets from a user s point of view (although the technologies are completely different).

The syntax for incorporating an ActiveX control into an HTML document is similar to that for incorporating a Java applet. In fact, the < OBJECT > tag is used to identify the name of the ActiveX control, the URL of the directory that contains it, an ID attribute that contains a unique hexadecimal serial number, and some other parameters. The serial number allows an ActiveX control to be downloaded automatically from one of several ActiveX control archives and repositories that are located anywhere on the Internet. Like inline images and Java applets, ActiveX controls developed and maintained at one site can be incorporated into HTML documents on another site. Also like Java applets, the ActiveX control is passed as runtime information in a series of < PARAM > tags. This allows the developer to customize the behavior of an ActiveX control.

In general, there are two kinds of ActiveX controls: the ones that contain native machine code and the ones that contain Java bytecode. The first kind are written in programming languages, such as C, C++, or Visual Basic. The control s source code is compiled into an executable that is downloaded to the browser and executed on the client machine. Contrary to that, the second kind are written in Java or any other programming language that can be compiled into Java bytecode. These controls are downloaded to the browser and executed in the browser s JVM. Note that the two different kinds of ActiveX controls have fundamentally different security implications.

The ActiveX technology is simply a means to download and run native machine code on the client machine. It is up to the programmer to decide whether to follow the ActiveX APIs, whether to use the operating system APIs, or whether to attempt direct manipulation of the computer system s resources. In general, there is no way to properly audit the ActiveX control functions on contemporary operating systems.
ActiveX controls that are downloaded as Java bytecode can be subject to all of the same restrictions that normally apply to Java applets. Consequently, these controls can be run by the browser within a sandbox. Alternatively, a browser can grant these controls specific privileges, such as the ability to read and write within a specific directory or to initiate network connections to specific IP addresses. Perhaps most importantly, the actions of such an ActiveX control can be properly audited (if the Java runtime environment allows such auditing).

In spite of the fact that ActiveX support has been ported to a variety of platforms (in addition to Microsoft Windows), ActiveX controls that are downloaded as machine code are processor and operating system dependent. These controls are typically compiled for a particular processor and with a particular set of APIs. Contrary to that, ActiveX controls that are written in Java can be processor and operating system independent.

In practice, ActiveX controls that are downloaded as machine code are predominant. From the point of view of software developers and Web users, they have three important advantages:

Developers can use the programming languages and compilers with which they are familiar.
Developers can draw on their existing repository of application programs, OLE components, and libraries, allowing them to bring ActiveX controls to market faster.
ActiveX controls can do anything (meaning that they are not restricted by a sandbox).

Obviously, the third point illustrates that ActiveX controls are risky from a security point of view. If the ActiveX controls can do anything, they can also trash files (or entire file systems), reformat hard disks, probe firewalls, install viruses, or do anything an attacker may dream of. Once an ActiveX control is running on a system, it has the ability to do anything that any other full-fledged program can do. While this makes ActiveX controls powerful, it also makes them potentially very dangerous. An ActiveX control written for malicious purposes may compromise the users privacy or damage computer systems in overt or subtle ways.

The inherent risks of ActiveX controls have been demonstrated on several occasions. The most prominent demonstration occurred in February 1997, when Lutz Donnerhacke, a member the German Chaos Computer Club (CCC), demonstrated an ActiveX control that could initiate electronic funds transfers using the European version of the Quicken software for home banking. With this version of Quicken, it is possible to initiate a transfer directly from one bank account to another. Donnerhacke s ActiveX control started up a copy of Quicken on the user s computer and recorded an electronic funds transfer in the user s checking account ledger. Written in Visual Basic as a demonstration tool for a German television station, the ActiveX control did not attempt to hide its actions. Consequently, it is possible and very likely that sooner or later similar ActiveX controls will occur that are made more stealthy. Again, it will be important to decide whether an ActiveX control is authentic and has not been tampered with. And again, this is where code signing technologies and systems come into play.

As mentioned above, Authenticode is a code signing technology and system developed and marketed by Microsoft. The system can be used to let users verify the identity of the author of a particular ActiveX control, and to let them determine whether the control has been modified since the first time it was distributed. ActiveX controls can be digitally signed and controlled using Authenticode. Microsoft Internet Explorer, for example, can be configured to disregard any ActiveX control that isn t properly signed, to run only ActiveX controls that have been signed by specific software publishers, or to accept ActiveX controls signed by any registered software publisher.

Authenticode signatures can be used for different purposes depending on whether the ActiveX control is distributed in binary machine code or JVM bytecode:

For ActiveX controls distributed in binary machine code, an Authenticode signature can be used to enforce a simple decision: either download the control or not.
For ActiveX controls distributed in JVM bytecode, an Authenticode signature can additionally be used to determine which access permissions are given to the Java bytecode when it is running in the JVM.

If an ActiveX control mixes binary machine code and JVM bytecode, or if both binary machine code and JVM bytecode controls are resident on the same Web page, the capabilities-controlled access permitted by the Java system is disabled. Also, Authenticode signatures are only verified when a control is downloaded from the Internet. If the control resides on the local file system, it is assumed to be trustworthy and safe to run. In this case, the ActiveX control is given unrestricted access to the system.

Obviously, code signing as implemented by the Authenticode technology-is an important tool for certifying the authenticity and integrity of an ActiveX control. However, code signing does not provide safety as is implied by Microsoft Internet Explorer s control panel (see Figure 10.2). It is important to note that code signing does not provide users with a safe environment where they can run their program code. Instead, it provides users with some audit trail, so that if a program misbehaves, it should be possible to interrogate the signed program code and decide whom to sue. Unfortunately, security through code signing is not that simple and has three shortcomings.

The damage that an ActiveX control does may not be immediately visible. In fact, an ActiveX control may be used to install a trapdoor (a hidden access to secret data or services).
The Authenticode technology does not protect a user against bugs and malicious software (e.g., computer viruses and Trojan horses).
The Authenticode software (and its validation routines), as well as the audit trails, are vulnerable in the sense that once a signed ActiveX control is running, it may erase the audit trail that would allow the user to identify the author (unless the prompt option had been chosen , where the user would be told beforehand who had signed it).

Earlier in this chapter, we said that the aim of code signing technologies is to trace back a malicious piece of software downloaded into a browser to its original publisher, who may be held accountable and be subject to litigation. We should mention that the degree to which a user of maliciously signed code can litigate against a software vendor heavily depends on the supporting legal structure, the type of certificate the vendor used to digitally sign the code, and a number of other factors. For example, on June 17, 1997, Fred McLain released an ActiveX control called Exploder Control on one of his personal Web pages. ^[21] When downloaded to a computer that has a power conservation BIOS, the Exploder Control shuts down Windows 95, and turns off the computer. Later, McLain obtained an Individual Software Publisher Digital ID from VeriSign, signed his ActiveX control, and reposted it on the Web page. McLain was soon to lose his certificate. Because he violated his contractual agreements associated with his software publisher certificate when he used it to sign malicious code, VeriSign unilaterally revoked the software publisher certificate. Note, however, that this was a futile act since very few people bother to retrieve and actually check CRLs at all. Consequently, hardly anyone knew that McLain s software publisher certificate was revoked. Also note that McLain s Exploder Control incited a flurry of controversy about the usefulness and effectiveness of code and object signing technologies and systems. In either case, it showed that without certificate revocation checking, these technologies and systems are almost always without any value.

^[21] Netscape Communications uses the term object signing certificate to refer to a software publisher certificate.