What Price Security?

By Charles F. Bowman

The power of Java is undeniable but so are the attendant security concerns.
Here's how to weigh the benefits and the risks.


These days, to say that the Internet is changing the way we live and work is to state the obvious. Even the most ardent cynic would agree that, in the not too distant future, the world will be at our fingertips--literally. However, as with most facets of life, this newfound freedom does not come without its costs. In this case, the price might be in the form of piece of mind. It's sad to say, but "security" has become a watchword for those of us who "surf the Net" and for corporations that conduct more and more of their business on the Web. It seems that with every door the Internet opens we have to find another lock to protect ourselves from some new kind of malicious attack. Here are but a few common examples:

  • A virus that destroys your hard disk.
  • A credit card number that gets into the wrong hands.
  • A pilfered customer list.

Adding to the welter of concerns are the new Internet execution models that have evolved: The age of the downloaded program has arrived. Yes, ostensibly sane individuals are downloading unseen programs, from unknown Web sites, and allowing them unquestioned access to their systems.

At the forefront of this new wave in computing is Java, a language built for the Web. Indeed, Java's meteoric success is easily demonstrated by the fact that it has already added a new term to the computer science lexicon: applet. A Java applet is just what it sounds like: a small program that is downloaded from a remote host and executes on your machine. The power of this new architecture is undeniable--but so are the attendant security concerns.

The fact is, anyone who uses a Web browser--and points it at a Web page containing an applet--is using Java. Moreover, applets subject you and your systems to more sophisticated forms of attacks. Here are two real examples:

  • A hacker managed to make an applet appear as if it was a local--and therefore trusted--piece of code. This breach required two "tricks": The hacker managed to get the malicious code onto the user's local disk (taking advantage of a common browser feature: file caching) and then "fooled" the browser into loading it as an applet.
  • A hacker exploited a weakness in Java's DNS translation processing. In this case, the hacker managed to "fool" the runtime environment into believing that his system was a "trusted host." After that, it was child's play to initiate a network connection that breached the victim's firewall.

Given that applet-based computing is becoming a fact of Internet life, the important questions one should ask are:

  • What constitutes good security?
  • How much can one rely on the execution environments themselves?
  • What does adequate security cost?

Let's start out by stating the obvious: The only truly secure system is the one that contains no external access capabilities (e.g., telephone lines, LAN connections, etc.) and remains locked and guarded in a sealed vault. Obviously, such a system would be of limited value to its potential users. Thus, security boils down to a risk analysis, weighing the benefits of Internet access versus the costs of a breach. However, to weigh the risks you must understand the underlying security models. This is of particular concern for downloaded environments: Because you really don't know what a given applet can do, you have little choice but to rely on Java's built-in security features. But can you?

Security Model

Java's security model is divided into three main areas of defense: the Byte-code Verifier, the Class Loader, and the Security Manager. Although we will discuss them separately, it is important to note that these components are an integral part of Java's runtime execution model. That is, they are an essential part of Java's design--not an afterthought.

When compiled, Java source code is converted into platform-independent byte codes. Applet security begins with the Byte-code Verifier, which:

  • Ensures that the compiled code is formatted correctly.
  • Applies a theorem-prover to each member function to ensure that its byte codes do not violate access type restrictions or pointer addressing rules (see below).

After the verifier pass, the following is guaranteed:

  • Internal stacks will not overflow or underflow. (When either of these events occurs, systems are unstable and hackers can "play in the confusion.") This type of attack has led the way to some of the most infamous security breaches.
  • No illegal data conversions will occur (i.e., the verifier will not allow integers to serve as pointers). This ensures that variables will not be granted access to restricted memory areas.
  • Byte-code instructions will have appropriately typed parameters (for the same reason as stated above).
  • Within an object, only public data and functions can be accessed. Access to all components is restricted. As a result, the proprietary data remains private.

The next area of defense, the Java Class Loader, determines how (and when) applets can load classes (code). One of its more important functions is to ensure that running applets do not replace system-level components within the runtime environment. This component is typically supplied by the browser vendor--although it is usually based on templates supplied by Sun Microsystems.

The third and most important component of Java's security model is the Security Manager. Its task is to perform runtime verification of all so-called "dangerous methods," that is, methods that request file I/O, network access, or want to define a new Class Loader. Some of its duties include:

  • Managing all socket operations.
  • Controlling the creation of, and all access to, operating system processes.
  • Preventing the installation of new Class Loaders.
  • Managing file access (obviously, we do not want applets reading files at will).

To ensure compliance, all methods that are part of the basic Java libraries (i.e., those supplied by Sun) consult the Security Manager prior to executing any dangerous operations. In all such cases, the Security Manager may exercise veto power over any request.

In the future, Java's security model will continue to evolve--both to plug holes as they are identified and to support new language features as they are introduced. Some features to look for include:

  • Digital Signatures, so you can be sure that the applet you are executing is the one you expected to run.
  • Certificates that will provide an authentication capability that will allow sites to "recognize" each other.
  • Secure Sockets, which will use encryption to ensure private and trusted communication among cooperating components.

Security Guidelines

Most of the problems experienced by Java users to date can be classified as implementation defects, rather than inherent flaws in the security model itself. (For example, the two breaches described previously have been rectified.) Nonetheless, users and system administrators should adhere to the following guidelines to enhance their Internet experience:

  • Use only the most current version of all networking software, particularly browser programs. Earlier versions are more likely to contain bugs.
  • Remain cognizant of your environment. For example, are you surfing the Net from your personal laptop or an enterprise system?
  • Remain vigilant and investigate even the smallest anomalies. A "missing file" might really be the result of "a hack."

This has been but a brief glimpse at the Java security model. There are many more issues and tactics that administrators (and users) should understand and address (e.g., firewalls, Intranets, etc.) Nonetheless, at this point, you should have two important questions in mind:

  • Are Java applets secure? They are as secure as any other Internet access method--more so than models that download native (binary) methods.
  • Should you use Java? Certainly--if you remain diligent, the benefits should far outweigh the risks. The secret is to stay one step ahead of the hackers.

About the Author: Charles F. Bowman is an independent consultant, author, and lecturer specializing in relational, GUI, and object-oriented technologies. He may be contacted at cfb@panix.com and 71700. 3570@compuserve.com.



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 Education Java Home
IBM HomeOrderEmployment