Internet Security, ActiveX, and Java

By Herb Chong

In recent months, Microsoft has been in the spotlight for several major security holes in its Internet Explorer and Internet Information Server products. However, in a more technical arena, Microsoft's ActiveX technology has been receiving criticism for its security lapses. In this article, I will try to explain the issues in less technical terms, so that you can understand why the experts are not embracing ActiveX as a way to distribute smart Internet browser components but are preferring Sun's Java.

The first thing you need to know is: What is ActiveX?. The first time that Microsoft mentions something resembling ActiveX in Microsoft Developer Network News, a bimonthly newsletter for developers, is in the January/February 1996 issue, Volume 5, Number 1. That issue's leadoff article, entitled "What is Microsoft Up to on the Internet?", contains this paragraph:

Internet Extensibility in Software. Web documents today are largely static-they present information or provide a simple user interface for retrieving information from the user. How can we make Web pages more dynamic-more like Web applications, if you will? OLE Controls and OLE Scripting provide the infrastructure that lets you add behavior and scripting to your Web page, in a language-neutral and tool-neutral way. OLE Controls and OLE Scripting leverage the investment in tools and knowledge that developers already made in OLE.

Note three things in this statement. First: There is no mention of ActiveX yet; Microsoft hadn't coined the name at this time. Second: These controls are based on OLE controls. I will return to this key point time and time again in this piece. The third and final point is that at the time of the Microsoft article, the only tools that allowed you to build OLE controls without resorting to "to-the-bare-metal" C coding came from Microsoft.

In an accompanying article in the same issue, Microsoft describes a new feature of Microsoft Office for Windows 95 named OLE Document Objects. I don't know how many of you use Microsoft Office's Binder application, but it is a handy tool for grouping together disparate types of Office documents into in single bundle, called a Binder object, so that you can work on related documents and ensure that they stay together, without having to hide parts of them that are not meant to be seen by their readers. Binder uses OLE Document Objects to pull together documents into these bundles.

Again, a quote from Microsoft:

One obvious application for this technology is in Internet Browsers, where the adoption of binder technology will facilitate the presentation of Internet-based information, while enabling the browser to present documents from Office and Office-compatible applications as well. In short, a user need only go to one application tool to browse and view all documents, whether local- or network-based.

There are at least two important assumptions in this statement. One is that you want to directly view documents created by some other tool (specifically, Microsoft Office applications), using your Web browser. The other assumption is that information suppliers are willing to send this information to you in a form that you can copy and modify.

Although users might not care as much, information suppliers greatly care who receives information in a form that that can be copied freely and modified. Thus, the assumption that people want to supply information across the Internet or an intranet is suspect.

By the May/June 1996 issue of Microsoft Developer Network News, ActiveX had suddenly appeared. In this brief issue, of only eight pages, the lead-off article "Is your Client Being Served?" contains a broad-brush picture of what Microsoft planned for ActiveX and its Internet software strategy. As to be expected, most of the article is for the hard-core software developer, but several things are clear. The first is that ActiveX is the general name for almost all of Microsoft's Internet software designs and architecture. The second is that ActiveX is designed around the notion that there should be no need to know if a document is on the Internet, your intranet, or on your desktop. It all looks the same on the desktop.

Where, then, are all the worries by the security experts concentrated? As you can see by now, ActiveX covers so much that saying that ActiveX is the problem is too vague. The security experts are worried about ActiveX controls that you download through your browser onto your system. What makes them worry? The first and most important thing that they worry about is that an ActiveX control, at this time, is a Windows OLE control. This means that it is written in native code, as Internet developers call it. Java, on the other hand, is written in Java and converted to byte code before being sent to your Web browser. This is the one small difference that causes nightmares for security experts.

Java code and the applications they make up that you work with on the Internet are downloaded to your system via your Web browser. The byte code that is sent is a set of instructions for an imaginary machine that doesn't exist yet in hardware, although Sun has announced plans to ship a card to plug into a regular PC that understands Java byte codes. Because the byte codes are for a machine that has no hardware equivalent, it means that some software on your system has to translate those instructions into something that can run on your system. Sun Microsystems, the inventor of Java, has a document called "The Java Virtual Machine Specification" that describes exactly how these instructions are to be interpreted. It describes and limits exactly what Java code can or can't do and in particular describes in detail what operating system services it uses and how it can be used.

There are two advantages to this approach. One is that because the byte code instructions don't correspond to any hardware, all real systems are equally disadvantaged. The other is that one set of byte codes will work on any system that has a Java virtual machine. This includes nearly any system that can run a Web browser. Nothing comes for free, of course. The disadvantage of using a Java virtual machine is that it costs and can cost plenty to run Java code. A really good one will run only slightly more slowly than native code, but it will always be slower so long as a software-only virtual machine runs the code.

ActiveX controls, because they are native code, will run only on the system they are compiled for. At this time, it means only systems running Windows 95 and Windows NT. Intel machines running NT will run ActiveX faster than other types of hardware. The native code will run as fast as the hardware is designed to run, which is faster than Java byte codes. Also, because they are native code, they can take advantage of hardware and operating system features. One negative is that unless you are running Windows 95 or Windows NT, you can't use ActiveX. The Macintosh might be receiving ActiveX soon, but right now, there are no other platforms in sight. The most important negative is that the controls are native code and can access operating system services. Let me rephrase that: an ActiveX control can access all operating system services.

This, then, is the crucial difference you need to care about. A Java virtual machine places severe limits on what a Java applet you download from elsewhere can do. It is the responsibility of the Java virtual machine to make sure that all the ways in which an applet could potentially damage or alter your system without your knowledge are strictly controlled. ActiveX controls, on the other hand, are designed to take advantage of being able to do anything that the operating system knows. This includes searching for information on your hard drives and sending it back to the server, implanting a virus, or damaging your system. For instance, it is trivial to write an ActiveX control to shutdown your system as soon as it starts running. It is almost as trivial to write one that formats your hard disk without telling you.

Java and ActiveX controls differ greatly in their placement of responsibility for security and protection of your system. Because Java runs in a virtual machine on your system and has clearly described the responsibilities of it, the copy of Java you installed on your machine is what you must trust to protect your system. ActiveX, because it is native code and has nothing standing between it and the operating system, requires the server that delivers the controls to your browser to ensure that it is delivering safe code. Each and every source of ActiveX controls must individually ensure that its controls are safe.

In a perfect world, either of these models of control delivery are safe. However, we don't live in a perfect world. Hackers regularly break into Web sites and substitute HTML or other things on them. Doing so with a rogue ActiveX control would be nearly as easy to accomplish. Microsoft has offered a registration and secure authentication mechanism to ensure that an ActiveX control from a certain server really is from that server. A hacker would not only have to break into the server, but also break the authentication code. However, given enough time, and it's not a long time these days, any reasonably good programmer can reverse-engineer the authentication generator. As one wag put it, all authentication does is give you a name to sue when the control breaks something.

Substituting a malicious Java applet is not much harder than tampering with an ActiveX control. However, it's not the applet that runs on your system, but the Java virtual machine. The applet would have to subvert the virtual machine first before it could begin to do damage to your system. Since the Java virtual machine is designed expressly to prevent this subversion, the task is much more difficult. Such a Java applet would be relying on a bug in the virtual machine failing in a certain manner so as to let the applet do as it pleased. This is not impossible. The Internet attack in the late 1980's that crippled it for several days exploited a bug in the mail system, allowing it to break out and run amok. However, that is much harder to do than replacing an ActiveX control on a Web site.

Given how ActiveX is currently implemented, it is inherently as secure as the Internet as a whole is. You are relying on Web site administrators to protect their sites and periodically verify their security and content. I have a friend who is an IS auditor. One of her jobs is to break into her own company's computer systems to check their security. She has not yet failed to get into any system she has tried to access. She's been programming for about 4 years.

With Java, you are relying on the quality of the Java virtual machine in your browser. On the Windows platforms, there are only two vendors you care about: Microsoft and Netscape. If you are using either Internet Explorer or Netscape Navigator, you are using one of their Java virtual machines. A bug in either of them would expose millions of users at once to a malicious Java applet. This is the key point. It must be a bug in the virtual machine and it needs to be discovered and exploited. As you can imagine, both Netscape and Microsoft have programmers doing their best to make sure that never happens.

Until Microsoft sees fit to implement ActiveX controls for the Internet in a different programming language that is designed to be safe, ActiveX controls are more dangerous to use than Java applets. Microsoft has hinted that they are planning on doing ActiveX in Java. This would essentially be a way of running Java applets with an extra layer of software and none of the advantages of native code ActiveX.

The security flaws are inherent in the application model that ActiveX uses and in its current chosen implementation (using native code). Java is designed to be safe across an unprotected Internet, and it is possible to mathematically prove that it is safe.



About the Author:  Herb Chong is a Windows programmer of long standing. He has written for a number of Windows magazines, including Windows Sources, The Cobb Group's Inside Microsoft Windows, and WindoWatch.



JavaTM is a trademark of Sun Microsystems, Inc.
Other companies, products, and service names may be trademarks or service marks of others.

Copyright    Trademark



  Java Feature Java Education Java Home  
IBM HomeOrderEmployment