Web Security and Commerce

ActiveX and Authenticode

ActiveX is a collection of technologies, protocols, and APIs developed by Microsoft that are used for downloading executable code over the Internet. The code is bundled into a single file called an ActiveX control. The file has the extension OCX.

Microsoft has confusingly positioned ActiveX as an alternative to Java. ActiveX is more properly thought of as an alternative to Netscape’s plug-ins. ActiveX controls are plug-ins that are automatically downloaded and installed as needed, then automatically deleted when no longer required. Adding to the confusion is the fact that ActiveX controls can be written in Java!

Despite the similarities between ActiveX controls and Netscape plug-ins, there are a few significant differences:

• Whereas plug-ins usually extend a web browser so that it can accommodate a new document type, most ActiveX controls used to date have brought a new functionality to a specific region of a web page.

• Traditionally, ActiveX controls are downloaded and run automatically, while plug-ins need to be manually installed.

• ActiveX controls can be digitally signed using Microsoft’s Authenticode technology. Internet Explorer can be programmed to disregard any ActiveX control that isn’t signed, to run only ActiveX controls that have been signed by specific publishers, or to accept ActiveX controls signed by any registered software publisher. Netscape Navigator 3.0 has no provisions for digitally signing plug-ins, although this capability should be in Navigator 4.0.

Kinds of ActiveX Controls

ActiveX controls can perform simple animations, or they can be exceedingly complex, implementing databases or spreadsheets. They can add menu items to the web browser, access information on the pasteboard, scan the user’s hard drive, or even turn off the user’s computer.

Fundamentally, there are two kinds of ActiveX controls:

• ActiveX controls that contain native machine code. These controls are written in languages such as C, C++, or Visual Basic. The control’s source code is compiled into an executable that is downloaded to the web browser and executed on the client machine.

• ActiveX controls that contain Java bytecode. These are controls that are written in Java or another language that can be compiled into Java bytecode. These controls are downloaded to the web browser and executed on a virtual machine.

These two different kinds of ActiveX controls have fundamentally different security implications. In the first case, ActiveX is simply a means to quickly download and run a native machine code program. It is the programmer’s choice whether to follow the ActiveX APIs, to use the native operating system APIs, or to attempt direct manipulation of the computer’s hardware. There is no way to easily audit the ActiveX control’s functions on most PC operating systems.

ActiveX controls that are downloaded as Java bytecode, on the other hand, can be subject to all of the same restrictions that normally apply to Java programs. These controls can be run by the browser within a Java sandbox. Alternatively, a web browser can grant these controls specific privileges, such as the ability to write within a specific directory or to initiate network connections to a specific computer on the Internet. Perhaps most importantly, the actions of an ActiveX control written in Java can be audited—provided, of course, that the Java run-time environment being used allows such auditing.

Although ActiveX support has been ported to a variety of platforms, ActiveX controls that are downloaded as machine code fundamentally are processor and operating system dependent. These ActiveX controls are compiled for a particular process and with a particular set of APIs. ActiveX controls that are written in Java, on the other hand, can be operating system and processor independent—provided that the web browser being used has support for both Java and ActiveX.

The <OBJECT> Tag

ActiveX controls can be automatically downloaded and run within web pages by using the <OBJECT> tag. The parameters to the tag specify where the ActiveX control is downloaded from and the Class ID that is to be run. Following the <OBJECT> tag are named parameters that are passed to the ActiveX control once it starts executing.

For example:

<OBJECT ID="Exploder1" WIDTH=86 HEIGHT=31
 CODEBASE="http://simson.vineyard.net/activex/Exploder.ocx"
 CLASSID="CLSID:DE70D9E3-C55A-11CF-8E43-780C02C10128">
<PARAM NAME="_Version" VALUE="65536">
<PARAM NAME="_ExtentX" VALUE="2646">
<PARAM NAME="_ExtentY" VALUE="1323">
<PARAM NAME="_StockProps" VALUE="0">
</OBJECT>

When the <OBJECT> tag is encountered by a web browser that implements the ActiveX protocol, the browser downloads the control, optionally verifies the control using a digital signature mechanism, loads it into the browser’s address space, and executes the code. The process is depicted in Figure 4.2.

Figure 4-2. ActiveX controls are composed of executable code that is downloaded from a web server and run on a local computer

Authenticode

Authenticode is a technology developed by Microsoft that lets users discover the author of a particular piece of code and determine that the program has not been modified since the time it was distributed.

Authenticode relies on digital signatures and the public key infrastructure, described in Part III. The process of creating signed programs and verifying the signatures is described in Chapter 9.

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

For ActiveX controls distributed in machine code

Authenticode can be used to enforce a simple decision: either download the control or do not download the control. These Authenticode signatures are only verified when a control is downloaded from the Internet. If the control is resident on the computer’s hard disk, it is assumed to be safe to run.

For ActiveX controls distributed in Java bytecode

Authenticode can be used to enforce a simple decision: either download the control or do not download the control. Under Internet Explorer 4.0, Authenticode signatures can also be used to determine what access permissions are given to the Java bytecode when it is running.

If a control mixes machine code and Java, or if both Java and machine code controls are resident on the same page, the capabilities-controlled access permitted by the Java system is rendered irrelevant.

Authenticode signatures are only checked when a control is downloaded from the network. If a control is installed, it is given unrestricted access.

Internet Exploder

In the fall of 1996, a Seattle area programmer named Fred McLain decided to show that ActiveX poses significant security risks. He wrote an ActiveX control called Internet Exploder. The control started a 10-second timer, after which it performed a clean shutdown of Windows 95 and then powered off the computer (if it was running on a system with advanced power management). McLain then obtained a VeriSign personal software publisher’s digital certificate, signed his Exploder control, and placed the signed control on his web site.

McLain said that he was being restrained: his Exploder control could have done real damage to a user’s computer. For example, it could have planted viruses, or reformatted a user’s hard disk, or scrambled data. McLain said that ActiveX was a fundamentally unsafe technology, and people should stay clear of the technology and instead use Netscape Navigator.

Neither Microsoft nor VeriSign were pleased by McLain’s actions. McLain said that the reason they were angry was that he was showing the security problems in their technologies. Representatives from Microsoft and VeriSign, on the other hand, said that they were angry because he had violated the Software Publisher’s Pledge by signing a malicious ActiveX control. Exploder wasn’t a demonstration, they said: it was an actual denial-of-service attack.

After several weeks of back-and-forth arguments, VeriSign revoked McLain’s software publisher’s certificate. It was the first digital certificate ever revoked by VeriSign without the permission of the certificate holder.

For people using Internet Explorer 3.0, the revocation of McLain’s digital ID didn’t have much effect. That’s because Explorer 3.0 didn’t have the ability to query VeriSign’s database and determine if a digital certificate was valid or had been revoked. For these people, clicking on McLain’s web page still allowed them to enjoy the full effects of the Exploder.

Soon after McLain’s digital ID was revoked Microsoft released Internet Explorer Version 3.0.1. This version implemented the real-time checking of revoked certificates. People using Explorer 3.0.1 who clicked on McLain’s web page were told that the ActiveX Control was invalid, because it was not signed with a valid digital ID. . . assuming that they had the security level of their browser set to check certificates and notify the user.

Proponents of ActiveX said the Exploder incident showed how Authenticode worked in practice: an individual had signed a hostile control and that individual’s digital ID had been revoked. The damage was contained.

But opponents of ActiveX said that McLain had shown that ActiveX is flawed. Exploder didn’t have to be so obvious about what it was doing. It could have tried to attack other computers on the user’s network, compromise critical system programs, or plant viruses. It was only because of McLain’s openness and honesty that people didn’t encounter something more malicious.