ActiveX is a collection of technologies, protocols, and APIs developed by Microsoft that are used for automatically downloading executable machine code over the Internet. The code is bundled into a single file called an ActiveX control and the file has the extension OCX. You can think of an ActiveX control as a self-installing plug-in.
ActiveX controls are automatically downloaded when Internet Explorer encounters a web page containing an <OBJECT> tag that references an ActiveX control. Depending on the current setting for Internet Explorer, these tags either are ignored or cause software to be downloaded. If the control is downloaded (again depending on the security setting of Internet Explorer), the control may be run directly, or the user may be prompted as to whether the control should or should not be run. This process is shown in Figure 12-4.
Figure 12-4. Internet Explorer’s security settings determine whether ActiveX controls will be downloaded and how they will be run.
ActiveX is an extraordinarily powerful technology. Because raw machine code is downloaded and run, the ActiveX controls can do anything—from displaying a new file type to upgrading your computer’s operating system!
Despite the similarities between ActiveX controls and plug-ins, there are a few significant differences:
ActiveX applets have been used for much more than plug-ins. Whereas plug-ins are primarily used to extend a web browser so that it can accommodate a new document type, ActiveX controls have also been used for:
Upgrading systems (e.g., Microsoft’s Windows Update)
Performing flash upgrades to ROM BIOS chips
Providing conventional Windows applications within a “browser” interface (e.g., Siebel’s ActiveX Data Control Interface)
Every ActiveX control is given a unique Class Identifier (CLSID). This key is assigned by the developer’s computer when the control is first created. For example, the Microsoft Calendar control has the key {B196B288-BAB4-101A-B69C-00AA00341D07}.
ActiveX controls are downloaded and run automatically, while plug-ins need to be manually installed, even when they are “automatically” downloaded.
By default, Internet Explorer will not run an ActiveX control that is not digitally signed with a public key that has a matching "software publisher’s certificate.”
For a control to be invokable from a web page, the ActiveX control must be marked “safe for scripting.” Authors of controls that are marked “safe for scripting” promise that they have implemented a “sandbox” architecture in which the control takes extra care to do things such as checking its arguments. A control that is not marked “safe for scripting” cannot be invoked from a web page.
ActiveX’s history has been somewhat colored by Microsoft’s attempt to position it as an alternative to Java during the “browser wars” of the late 1990s. At the time, much of the developer and academic community’s attention was focused on the alleged portability and security that was provided by the trendy Java language (see Chapter 13). These people attacked ActiveX, correctly pointing out that it was neither portable nor secure, nor could it be.
Today it is clear that ActiveX really isn’t an alternative to Java, nor was it a weapon against Netscape. ActiveX is instead a tool for making the client-side applications written for the Windows API a more integral part of the World Wide Web—and in the process making the Web somewhat less useful for computers running other operating systems. And ActiveX certainly isn’t a weapon against Navigator, as there are now plug-ins that allow ActiveX controls to be run directly on Navigator itself.[125]
Indeed, ActiveX controls can even be written in Java! Controls written in Java can have restricted access to your computer system, based on Java’s access control model, or they can have the same unrestricted access to your computer as controls written in C++.
ActiveX controls are invoked by web pages that contain 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, here is an <OBJECT> tag that displays a movie using the Macromedia’s Flash ActiveX applet:
<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://active.macromedia.com/flash2/cabs/swflash.cab#version=4,0,0,0"
ID=master_ie WIDTH=100% HEIGHT=100%>
<PARAM NAME=movie VALUE="master_ie.swf">
<PARAM NAME=loop VALUE=false>
<PARAM NAME=menu VALUE=false>
<PARAM NAME=quality VALUE=high>
<PARAM NAME=bgcolor VALUE=#000000>
<EMBED src="master_ie.swf" loop=false menu=false quality=high bgcolor=#000000
WIDTH=100% HEIGHT=100% TYPE="application/x-shockwave-flash"
PLUGINSPAGE="http://www.macromedia.com/shockwave/download/index.
cgi?P1_Prod_Version=ShockwaveFlash">
</EMBED>
</OBJECT>When the <OBJECT> tag is encountered by a web browser that implements the ActiveX protocol, the browser first checks the class ID to determine if the control is already present on the system. If so, it is run with the given parameters. If not, the browser downloads the control, optionally verifies the control using a digital signature mechanism, loads it into the browser’s address space, sets up the parameters provided by the HTML page, and finally executes the code. The process is depicted in Figure 12-5.
Figure 12-5. ActiveX controls are composed of executable code that is downloaded from a web server and run on a local computer
Netscape Navigator 4.0 and above use the same <OBJECT> tags for downloading plug-ins. With the exception of Authenticode validation, described in the next section, Netscape plug-ins are now essentially ActiveX controls.
The power and the danger of ActiveX is that downloaded applets basically have the run of your system. Microsoft’s engineers didn’t think that this was a problem, because consumers routinely run programs that arrive preinstalled with their computer or that are purchased in stores.
But there is a fundamental difference between a program that you buy in the store and ones that you download over the Internet. The key difference between such programs, the engineers reasoned, is that when you buy a program in the store, you know who sold it to you—and you know who made the program. If the program contains hostile code or a Trojan horse, you know who to sue. That’s not the case with code downloaded over the Internet. A program represented as from Microsoft might actually come from some data thief or even a spy for a foreign government.
Instead of trying to develop a fundamentally new system for downloading code that would be “safe,” a la Java, Microsoft decided that it would be easier to simply bring the assurances of the physical world to the online world. The obvious way to do this was to build a public key infrastructure (PKI) system for Windows executables. Microsoft calls the system Authenticode.
The Authenticode system defines a standard for digitally signing Windows executables and CAB files. The signature consists of a digitally signed cryptographic checksum for the signed objects and a public key certificate that contains a key that will validate the signature. The certificate itself is supposed to be signed by a certification authority that has a “software publisher’s certificate” in the Microsoft Internet Explorer certificate store.
The Authenticode technology makes it possible to examine a signed ActiveX control and determine who signed it, and validate that the control has been unmodified since the time it was signed. The process of creating signed programs and verifying the signatures is described in Chapter 22.
Authenticode signatures can be used for different purposes depending on what precisely is being signed:
- Windows executables
Authenticode allows Windows users to see the name of the organization (or individual) that signed the executable. It also allows the user to verify that the executable hasn’t been damaged, tampered with, or infected with a virus since the time it was signed. The Windows operating system allows programs to be run whether they have been signed or not, but it will issue a warning if the user attempts to run a downloaded program that does not contain a valid Authenticode signature.
- ActiveX controls distributed in machine code
Authenticode is the basis of the ActiveX security model. The standard security policy for Internet Explorer is that ActiveX applets that have valid Authenticode signatures can be run with the user’s permission, while ActiveX applets that do not have valid signatures will simply be ignored. Users can also click a check box that tells Internet Explorer to “trust all content” from a particular signer—for example, to trust all content from Microsoft. This is not the default.
- ActiveX controls distributed in Java bytecode
Under Internet Explorer 4.0 and later, Authenticode signatures can also be used as the basis for determining what access permissions are granted to a particular Java program while the program 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.
Internet Explorer only checks Authenticode signatures when the control is downloaded from the network. Downloaded controls are installed in a special Internet Explorer directory. Any control placed in this directory is implicitly trusted, whether it is signed or not. In the past, security problems have been discovered with controls that were preloaded by computer vendors (see The Bogus Microsoft Certificates).
With Windows 2000, Microsoft introduced the use of Authenticode technology for signing critical components of the Windows operating system itself. This technology is also present in Windows ME. It is likely that the use of Authenticode technology in the operating system will make it easier to detect and diagnose computer viruses and other kinds of hostile code in the operating system.
Chapter 22 discusses how to digitally sign executables using Microsoft’s Authenticode tools. The remainder of this chapter discusses Authenticode from the user’s perspective.
From its very introduction, Authenticode has been an extraordinarily controversial technology—not because of what it does, but because of what it does not do. When Microsoft introduced Authenticode, it positioned it as a technology that could bring the safety of Java to downloaded ActiveX applets.
Of course, Authenticode doesn’t provide safety for ActiveX. Authenticode provides limited accountability. Authenticode allows you to determine the key that was used to sign an ActiveX control—nothing more and nothing less. If an ActiveX control is signed, and if it is signed by the same organization that created the control, and if that organization took great pains to ensure that there would be no hostile functionality in the applet, then Authenticode really does provide an added measure of protection against downloaded mobile code. But there are many potential problems with the Authenticode security model:
The ActiveX control might contain malicious code that was put there without the knowledge of the individual or organization responsible for signing the ActiveX control.
The ActiveX control might not contain any intentionally malicious code, but there may be a way to make the ActiveX control do something malicious nevertheless, thanks to a buffer overflow or some other coding problem.
The organization that codes and signs the ActiveX control might be malicious in nature and not care if you identify them after the fact. For instance, it could be a front company for a terrorist group or organized crime. By the time that the bad things have been traced back to them, the guilty parties have disappeared or moved to countries with no extradition treaties.
A signed ActiveX control that is intentionally hostile might erase its digital signature after it starts execution, and there will be no record that a signed control was responsible for the damage.
If a computer is damaged, it’s likely that there will be many signed ActiveX controls resident on the system. It can be extremely difficult, and perhaps impossible, to determine which ActiveX control was responsible for the damage.
Fred McLain, the author of the Internet Exploder applet (see the next section, Section 12.3.4), explains that the security Authenticode provides to computers is similar to the security provided to the users of valet parking. Imagine that you are a frequent user of valet parking at a variety of fine restaurants in the Seattle, Redmond, and Bothel areas. Now imagine that after a month of heavy restaurant binging, you notice that your car is driving strangely, so you take the car to a mechanic. The mechanic looks at the undercarriage for a few moments, then pulls out a big stick, some straw, and a fist-full of dirt. “Looks like somebody was driving off-road with your car,” he says. “Your gas tank is punctured, and there are other problems as well. Who did this?” You shake your head. You know it was one of the valet parking attendants. But which one? There is no way to know for sure.
It’s important to understand that critics of the Authenticode technology are not opposed to code signing on principle. Using digital signatures to authenticate executables is a great way to detect viruses and accidentally corrupted programs. The objections are to the promotion of Authenticode as a technology that could provide safety for downloaded programs.
To prove that Authenticode could not provide safety, in 1996 a Seattle area programmer named Fred McLain created a demonstration “hostile applet” called Internet Exploder. The control would run a 10-second countdown, after which time it would perform a clean shutdown of Windows 95 and power 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 his demonstration was a very restrained one: 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 that people should stay clear of the technology and instead use Netscape Navigator.
These statements made McLain the darling of executives at Microsoft’s rivals Netscape and Sun. Executives at Microsoft and VeriSign, meanwhile, said that McLain had violated the license agreement, called the Software Publisher’s Pledge, under which he had obtained his VeriSign certificate. He had violated the pledge, they said, by willfully signing a program that was certifiably hostile—a program that launched a denial-of-service attack against a user’s own computer. 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 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. 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.
Somewhat surprisingly, in the years since ActiveX was first introduced by Microsoft, there have been no other significant cases of a hostile ActiveX control that was digitally signed with an Authenticode certificate and then distributed.[126] As there have been a large number of viruses and other Trojan horses distributed during the same time period, it seems somewhat surprising that Microsoft’s position on the deterrent effect of digital signatures has apparently had some merit. On the whole, writers of viruses and Trojan horses have not been willing to digitally sign their wares. Of course, to date it has been so easy to spread hostile code via Outlook and Word documents that there has been little reason to go to the additional trouble of doing it via ActiveX controls.
This is not to say that ActiveX is a safe technology. On the contrary, a number of problems have been found with ActiveX controls that were created by legitimate software companies, digitally signed, and distributed. These problems include the following:
Microsoft marked the “Microsoft Office UA Control” as “safe for scripting” in Office 2000. The control implemented the “show me” feature in Microsoft’s interactive help system. Because the control was marked “safe for scripting,” a hostile web site could use the control to activate and select any dialog box on a Windows-based computer that had both Internet Explorer and Office 2000 installed. This vulnerability was discovered in March 2000 by L0pht Research Labs and @Stake. The CERT/CC advisory can be found at http://www.cert.org/advisories/CA-2000-07.html.
The ActiveX components associated with Microsoft Access contained a programming bug that caused Microsoft Access documents to be loaded and executed when referenced on any web page—without first prompting the user that the content was about to be executed. This bug allowed a web site operator to run any command on any computer that visited the web site, provided that the computer was running Internet Explorer and contained a copy of Microsoft Access. This vulnerability was discovered in July 2000 by Georgi Guninski and was published by Jesper Johansson, editor of the SANS Windows Security Digest, who called the vulnerability “probably the most dangerous programming error in Windows workstation that Microsoft has made.” The SANS advisory can be found at http://www.sans.org/newlook/resources/win_flaw.htm.
More information about risky ActiveX controls can be found in CERT/CC’s 53-page report, Results of the Security in ActiveX Workshop, which can be downloaded from http://www.cert.org/reports/activeX_report.pdf.
[126] More accurately, there have been no significant cases widely reported. We don’t know of any cases that have occurred, but we can’t be sure that some haven’t occurred and been kept quiet—or gone undetected.