Protecting Cyberspace:
The Java Dimension

by Arosha K. Bandara


The arrival of Java has opened a multitude of new possibilities for the Internet with users now able to access remote programs that will run on their own machines. However, the concept of allowing remote code to execute on local machines raises very serious security implications. Sun claims that Java addresses these issues, but recent research efforts have highlighted a number of problems that contradict this.

This article looks at Java's security mechanisms and then describes some of the flaws that have been reported. It is concluded that there are some inherent problems in the Java system that must be addressed before it can be deemed secure.


As the World Wide Web (WWW) continues to grow, an increasing number of content providers are experiencing great frustration at being unable to express their ideas using HTML alone. As a result, the past year has seen the arrival of executable content on the web. Sun's offering, Java, is a language that allows programmers to develop code that can be downloaded across the internet and executed within the user's WWW browser. Although, the concept of downloadable code is not an entirely new one, Java has the unique characteristic of being supported by Netscape's world-leading Navigator 2.0 browser, giving it a huge potential user-base. This is in contrast to languages like Telescript[1], Phantom[2] and Safe-Tcl[3] all of which remain non-commercial products.

The notion of allowing downloaded code to execute on a user's machine, although a very attractive proposition, has very serious security implications. For programs to be useful they must be allowed to access the user's local resources (CPU, Memory, File System etc.) but it is also essential to prevent the abuse of such privileges. Such abuse could be either accidental or malicious, but is guaranteed to cause headaches for the user. By looking at the ways in which rogue programs manifest themselves on a user's system, this article discusses the mechanisms used by Java to minimise the threat.

Hostile programs can cause problems is many ways. Often they can cause a system to crash by violating a type convention or modifying pointers to refer to unreachable sections of memory. Forging of pointers can also be used to make the system execute some illegal code fragment (e.g. virus code, file system procedures). Other attack strategies include replacing valid code in a friendly program with hostile code that either causes the machine to become unusable (e.g. deleting files, disabling screen etc.) or steals some information from the user (e.g. password file, bank details etc.).

Figure 1. The Java Run-time Environment

Java attempts to prevent these attacks by implementing a tiered security policy[4].

At each stage of this security mechanism, the access control is refined to allow maximum funtionality in a secure environment. However, efforts of various researchers have highlighted flaws in the implementation of the security policy that make the measures described ineffectual[5]. The potential damage that these bugs could inflict has been investigated by creating various hostile programs[6].

It is possible for a Java program to initiate a dead-lock on the user's system by failing to release a critical resource (e.g. the browser's status bar). This type of attack, known as a Denial of Service attack, could be caused either accidentally or maliciously. Other manisfestations of this type of attack often cause a degredation of performance which makes them quite hard to detect. Because a malicious programmer cannot really profit from this type of attack, Sun considers it to be a low-priority problem[7].

The other bugs allow hostile programs to access the local file system without the user's knowledge. This is done by fooling the AppletSecurityManager into thinking that a program is accessing data from its originating machine (a permitted operation) when in fact the data is coming from the local file system. Also, it has been shown that a program can create its own ClassLoader that will allow local file access procedures to be replaced by the hacker's own. If these flaws are fully exploited, it is possible to circumvent much of the security infrastructure of the user's machine, including a firewall[8].

Although Sun and Netscape have responded to these reports by releasing updated software and patches[7,9], the regularity with which new attacks[10] are being announced begs the question: Are there any inherent security flaws in Java? The answer to is unknown, and is likely to remain so for several reasons.

For a system to be secure it must have a well defined security policy that is enforced to be omnipotent, tamper proof and verifiable. Also, it is important that the integrity of the run-time environment is protected and that any breach of security can be properly audited [11].

Unfortunately, Java is unable to satisfy any of these requirements. Because of Java's flexibility, Sun has had some difficulties in providing a clear definition of the security policy. In addition, the implementation leaves a lot to be desired. The AppletSecurityManager, a key component in the implementation of the security policy, is not invoked by default. It is the responsibility of the programmer writing the security-relevant portions of the run-time environment to explicitly invoke the SecurityManager. Also, because Java lacks precisely defined sematics, it is impossible to formally verify the correctness of the SecurityManager. Researchers at Princeton[5] have also shown that Java programs are able to obtain information about the run-time environment (e.g. memory mapping) thus breaching the integrity of the system. Finally, there is no implementation of the Java run-time that is capable of producing an audit trail that would allow the source of an attack to be traced.

Because of these problems, it is difficult to say whether Java, in its current form, can be made secure. In order to provide a higher security system, Sun should consider formulating a clear definition of Java's security policy such that providers of the run-time environment can create a reliable implementation that is both tamper proof and verifiable.

Also, it should be noted that as Java gains greater user support, programs will be developed by relativley inexperienced individuals who could inadvertently produce code that instigates denial of service attacks. For this reason, Sun should give higher priority to preventing these attacks.

The speed with which Java's weaknesses are being highlighted is a direct consequence of Sun's policy of making all Java source code publicly accessible[12]. Without this freedom, it is more than likely that the security flaws would have only been discovered after some major hacking operation. Now, Sun can draw on the expertise of programmers from around the world to identify and fix the problems quickly, which should mean that Java will soon be able to fulfill its potential as the liberator of cyberspace.

© Arosha K. Bandara, 1996

The author acknowledges Sun and Java as registered trademarks of Sun Microsystems Inc.,
and Netscape and Navigator 2.0 as trademarks of Netscape Communications Corp.


1. Title: The Telescript Language Reference
Author(s): Anon., General Magic, Inc.
Source: <>
Complete documentation for the Telescript language. Further information regarding security implications of Telescript can be found at:


2. Title: Phantom: An interpreted language for distributed programming
Author(s): Courtney A.
Source: Usenix Conference on Object Oriented Technologies, June 1995
Exact content is unknown since the article could not be found.

3. Title: Email with a mind of its own: The Safe-Tcl language for enabled mail
Author(s): Borenstein N. S.
Source: IFIP International Working Conference on Upper Layer Protocols, Architectures and Applications, 1994.
Exact content is unknown since the article could not be found.

4. Title: Yes, Java's Secure, Here's Why
Author(s): Lemay L., Perkins C.
Source: Datamation, 42(5):47-49, March 1, 1996.
Describes the built-in security features of Java in a clear and concise manner.

5. Title: Java Security: From HotJava to Netscape and Beyond
Author(s): Dean D., Felten E. W., Wallach D. S.
Source: IEEE Symposium on Security and Privacy, Oakland, CA, USA, May 1996..
The definitive article - describes the bugs in Java and the implementations of the run-time system. Produced as part of the on-going efforts of the Princeton Safe Internet Programming (SIP) Team to make Java a secure language.

6. Title: Hostile Applets on the Horizon
Author(s): LaDue M. D.
Source: <>
Examples of hostile programs written in Java.

BEWARE: Disable Java before visiting this site

7. Title: Regarding Java Security
Author(s): Mueller M.
Source: RISKS Forum, 17(45), November 1995
Newgroup posting to the Risks Forum in reponse to initial warnings from the Princeton team regarding security bugs in Java.

Complete text can be seen at:


8. Title: Firewalls & Internet Security: Repelling the Wily Hacker
Author(s): Cheswick W. R., Bellovin S. M.
Source: 1st Edition, Addison-Wesley, 1994.
A very useful introduction to internet security with examples of firewall architectures. Also contains a description of how hackers operate, from system probes to complete system violations.

9. Title: Netscape's Java Security Architecture
Author(s): Anon., Netscape Communications Corp.
Source: <>
An outline of how Netscape's implementation of the Java run-time system has been changed to address the recently discovered security flaws. Also has a brief summary of the direction in which future refinements are going to be added.

10. Title: Safe Internet Programming: News
Author(s): Felten E. W., Safe Internet Programming (SIP) Team, Princeton University, USA
Source: <>
Latest news releases regarding Java security flaws.

11. Title: Department of Defense Trusted Computer System Evaluation Criteria
(Orange Book)
Author(s): Anon., National Computer Security Center, USA
Source: National Computer Security Center, 1985
Sets out the requirements of a secure computer system. This is used as the definitive guideline for computer security by the majority of manufacturers.

12. Title: Low Level Security in Java
Author(s): Yellin F.
Source: <>
Presents details of the lowest level security mechanisms in Java and documents Sun's decision to make all Java source code public.

Top Surprise Home

Please e-mail suggestions to Arosha K. Bandara <>