1. Introduction
5. Conclusion
Sun Microsystems’ Java technology has added significant value to the World Wide Web. It has allowed programs to be transmitted over networks in a portable fashion. For example, Java has allowed Internet web browsers to download applets and run them locally. This has caused some serious security issues – an applet with malicious code could destroy data on the user’s hard drive or it may transmit sensitive data off the user’s hard drive to an unknown location.
In order to combat these security threats, several security features have been built into the language itself, the Java Virtual Machine (JVM) and its application program interface (API). For added security, the creators of web browsers, such as Microsoft, have put security features to protect their users. This essay seeks to evaluate the above-implemented security features of Java with some supporting code for clarification.
The actual Java language has been given some restrictive features for security reasons. The MageLang Institute (1998) states, for instance, that raw pointer arithmetic, which was common in C and C++, has been removed. It has been replaced by type-safe references. Wang and Yang (1993) emphasise that in Java, pointers do not exist and therefore it is not possible to manipulate memory directly. In addition methods and classes can be declared as final to prevent them from being sub-classed or overridden. Furthermore Java contains a feature known as automated garbage collection, which de-allocates unused memory. All of the said security features have been implemented to ensure that the programs are more stable, and run in a predictable manner.
Compiled Java programs are not run directly by the processor as is common with languages such as C++. Instead, the compiled byte code is run by a Java Virtual Machine (JVM) and this JVM can control the way the program operates. The diagram on the following page, from Sun Microsystems (1997), illustrates the JVM briefly. The JVM contains three major components being the class loader, the bytecode verifier and the security manager. These components will now be explained briefly:

Java security
process flow (Source: Sun Microsystems Inc., 1997)
The final level of security is contained within web browsers. The web browsers are designed in such a way that Java applets need to be attached by developers’ certificate and signed. This enables the identity and integrity of the applet to be proved. Netscape Communications Corporation uses “Java Object Signing Technology” in their Netscape Communicator Software while Microsoft uses “Authenticode” in Internet Explorer.
1. Authentication
In terms of
network security, authentication is the verification of an individual’s
identity. It is vital because it stops unauthorized people from gaining entry
to a system. When Java
applets are downloaded, it is important to identify where the applet came from,
and whether it can actually be trusted.
When the first versions of the JDK were released there were no
authentication processes embedded. Sun Microsystems realised that there were
security implications, and in later versions they added authentication by
providing facilities for generating cryptographic keys and digitally signed
applets. A program known as “javakey” does this task and in addition it groups
the required class files into a Java JAR formatted file. The user can then
verify the digital certificates, and if they are valid, then the user can be
reasonably sure that the applet will not cause damage to his system. It must be
pointed out however that both Microsoft and Netscape’s browsers do not ask the
user whether he wants to stop the execution of the applet, either before or
after viewing the certificate. This somewhat defeats the purpose of the digital
certificates.
2. Authorisation
Authorisation may be defined as the granting of privileges to an
individual by a designated official to access information based upon the
individual’s clearance and need-to-know. Java’s authorisation features may be
divided into two categories: the access control in the classes, and the
abilities of the programs which are controlled by the Java security manager.
Because Java is an object-oriented language, authorisation fits
naturally into its framework. This essentially means that the classes and
methods within classes and methods can be made public, private or protected and
this will influence access decisions. Public methods allow other objects to
have full access, while with protected or public methods, access will depend on
whether the object, which issues the request, is a subclass of it. All of these
rules provide security enforcement at a static level.
The security manager takes care of access control during runtime. It is
responsible for enforcing the security sandbox model and checks whether
operations should be permitted or not. Internet Explorer and Netscape
Communicator have enhanced the Java security manager by providing their own
APIs. This has allowed applets to be created, which can break through the
security sandbox and access critical resources. Both browsers will alert the
user if a suspect applet is loaded. However it is difficult to educate users to
have security awareness – the browser alerts may be incomprehensible to the
user and not everyone will understand what a socket is, for example. Naïve
users may, in fact, allow the applet to execute, resulting in dire
consequences.
3.
Data
Integrity
Data integrity ensures that the data within databases remains consistent
and correct and that the computer resources are operating in a correct manner.
There are two ways in which Java can maintain data integrity. The bytecode
verifier within the Java Virtual Machine makes sure that the format of the Java
bytecode files is correct, and this avoids a situation where seemingly valid
instructions are executed, when they, in fact, are not valid. The verifier
checks for proper program construction and it also checks for possible errors
such as runtime errors.
The applet’s digital signature can also be used to verify whether the
applet has been tampered with during transmission. The algorithm is designed in
such a way that even if the applet changes slightly, then the digital signature
will not match the original one. It is also almost impossible to forge a
digital signature and therefore this mechanism is considered highly secure.
4.
Confidentiality
This is the property that information should not be disclosed to
unauthorised parties. There was great concern when Java first came out because
it had the capability to create applets, which could be transmitted across the
Internet and executed locally. These applets could then gather information,
such as credit card numbers, from the users’ hard drives and then transmit them
to an unknown location.
Java protects its users by defining a security sandbox model. In this
model, the applets can do anything they want within the sandbox but they cannot
access elements outside it. This means that even dubious code can be run
without the risk of damage to the machine. If the applet tries to read from or
write to the user’s hard drive, then those operations will fail. The applets
will also be prevented from making connections to other computers.
These strong restrictions have provided a greater level of security but
at the same time they have greatly reduced the number of tasks that an applet
can perform and this has greatly reduced their functionality.
5.
Containment
In Java terms, this refers to the constant monitoring of a loaded applet
while it is running. This task is performed by the components of the Java
Virtual Machine. The JVM maintains the containment of the applet during
execution after the above-mentioned authentication and authorisation phases.
However since the makers of the web browsers have adopted their own sandbox
models and security mangers, it is still possible for malicious code to break
out of the original Java sandbox model and cause havoc.
6.
Non-repudiation
During authentication there must be a service that provides proof of the
integrity and origin of data, which a third party can be called upon to verify.
This can be done by digitally signing the applet with certificates issued by
third party authorities.
The latest versions of the JDK include APIs, which contain such digital
signatures. For this reason parties cannot deny knowledge of a transaction
since there will be proof that they were involved in the transaction. This is
useful for electronic agreements because now both parties can authenticate and
prove each other’s participation.
Again the web browser level poses problems. For example in Netscape
there is a dialog screen with a “Verify” button which, when clicked, allows the
user to have the certificate verified by the relevant authorities online. The
user has no way of knowing whether the browser actually contacts the
authorities and has not been tampered with in some way.
7. Auditing
Auditing is a function, which allows security threats to be detected and
investigated. If a system has such a function then, if there is a security
breach, then the System Administrator can use the audit trails to investigate
and solve the problem.
Java unfortunately does not have auditing facilities. There is no way of
tracing what an applet has done when it was loaded. The web browsers provide
minimal logging facilities – the logs are stored in a text file. However the
browser will only log program bugs or debug messages, and the logging facility
has to be enabled manually in any case.
Listed below are some example programs taken directly from McGraw and
Felton (1999) which illustrates how Java can be used to cause havoc to a user’s
system. The examples below show some code which could be used in a
denial-of-service attack.
“Listing
4.4 The Ackerman function implemented as a Java application.
Ackerman takes integer n and exponentiates n by itself n times. This means that
Ackerman(3) is equivalent to three cubed, cubed. The program can be run by
typing the command java Ackerman n, where n is an integer. Computing anything
greater than Ackerman(3) takes a long time and many CPU cycles. This code was
written to be as inefficient as possible. This version of Ackerman could easily
be used in a denial-of-service attack.”
import java.lang.System;import java.io.IOException;import java.lang.Math; class Ackerman {public static void main(String[] args) { long ackValue = 1; long exp = 0; if (args.length >= 1) { try { exp = Integer.parseInt(args[0]); } catch (NumberFormatException e) { exp = 0; } } if (exp > 1) { ackValue = exp; int numLoops = (int)exp; for (int i = 1; i < numLoops; i++) { exp = ackValue; for (int j = 1; j < numLoops; j++) { ackValue = ackValue * exp; System.out.println("current value is " + ackValue); } } System.out.println("Ackerman vlue: " + ackValue); }} |
“This
denial-of-service approach is simple and elegant. There are literally hundreds
of things that can be done in Step 5. Other possibilities include endlessly
appending to a StringBuffer and using drawString to display its entire
contents. This ends up as a double whammy, eating both CPU cycles and memory. Another
possibility would be calculating p using the most inefficient algorithm
possible. If you have trouble remembering how to code poorly, just teach an
introductory programming course to jog your memory.
On
a more serious note, this line of attack is both very simple and very
successful. Most browsers seize up and die under such an attack.”
Another
example is a fragment of code which opens up countless windows, making the
computer virtually unusable while the code is running :
// In the code below, littleWindow is of type Frame// Adapted from an idea by Mark LaDuetry {// create a windowlittleWindow = new bigFrame("Whocares"); // make it very biglittleWindow.resize(1000000, 1000000); // position it to cover everythinglittleWindow.move(-1000, -1000); // finally, open the windowlittleWindow.show(); }catch (OutOfMemoryError o) {repaint();}class bigFrame extends Frame { // constructor method Label 1; bigFrame(String title) { super(title); setLayout(new GridLayout(1, 1)); Canvas whiteCanvas = new Canvas(); whiteCanvas.setBackground(Color.white); add(whiteCanvas); }}
It is fairly evident that Java currently solves many of the security
issues inherent in networks. Security measures have become a core component of
Java’s design. Although the security features are not perfect, the Java
language, on its own, can be considered a reasonably safe and secure language.
Unfortunately manufacturers of web browsers have introduced weaknesses into the
system because they have implemented their own security managers and JVMs, and
they have not adhered to the standards set by Sun Microsystems. It is thus up
to the end-user to investigate whether his web browser will provide a safe
environment for running applets, otherwise security holes may jeopardise the
health of his system.
References
|
McGraw & Felten (1999) |
Securing Java 2nd Edition, 1999 Published by John Wiley & Sons Inc |
|
Sun Microsystems (1997) |
The Java Language : An Overview |
|
Wang & Yan (1993) |
Security ---- How is it implemented in the
Java language? Available : |