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.
|