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.