Java Security in the Context of Computer Networks

 

Contents

 

1. Introduction

 

2. Java’s Security Features

 

3. Evaluating Java’s Security

 

4. Examples of Malicious Code

 

5. Conclusion

 

Introduction

 

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.

 

Java’s Security Features

 

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:

 

 

figure2.gif - 5.47 K

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.


Evaluating Java’s Security

 

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.

 

Examples of Malicious Code

 

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 LaDue
try {
// create a window
littleWindow = new bigFrame("Whocares"); 
// make it very big
littleWindow.resize(1000000, 1000000);  
// position it to cover everything
littleWindow.move(-1000, -1000);    
// finally, open the window
littleWindow.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);
  }
}

 

 

 

Conclusion

 

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

http://java.sun.com

Wang & Yan (1993)

Security ---- How is it implemented in the Java language?

Available :

http://www.cs.colorado.edu/~yiyan/javaproj.html