Notice: This material is excerpted from Special Edition Using Java, ISBN: 0-7897-0604-0. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
by Suresh K. Lois
In this chapter we discuss security in networked computing environments, specifically in the context of the Java programming language.
We will begin by a generic discussion of security of networked computing environments, such as the Internet. We will then arrive at a precise definition of the security problem, and propose a strategy to develop security mechanisms. We will then examine the Java security architecture, and conclude with a brief descussion of open and evolving issues related to Java security.
When you finish reading this chapter, you will have a good understanding of security issues related to networked computing in general, and of the Java security architecture in particular.
The Internet, especially with the Web and Java, is rapidly evolving from a limited set of computer networks, into a mass-market, consumer oriented mainstream medium for delivering diverse forms of information. Earlier generation mass media, such as TV, have four important attributes which make them zero-security-risk systems:
The Internet (and consequently the Web and Java) has exactly the opposite characteristics, on each of the above attributes:
The above four charateristics are the major source of the power, flexibility and dynamism of the Internet (and the Web and Java). However, they are also the source of most potential security issues related to Java. In the following sections we will examine the above attributes of the Net in general, and Java in particular detail, and delineate their security implications. We will then present the specific security risk-minimizing mechanisms built into the core of the Java architecture.
This chapter is organized into six sections. Following this introduction, we will explore the issue of security of networked computing in general, and define the security problem associated with executable content. We will propose a six-step approach to construct a viable and flexible security mechanism.
We will outline the security approach taken by the Java language architecture, in the context of the six-step approach. We will also telescope in at greater detail, on Java architectural components which implement security mechanisms.
As with any new technology, there are several open questions related to Java security, which are still being debated on the Net and other forums. We will briefly examine some of them.
Finally, there is a list of references and resources for further information on Java security.
In this section we will analyze the concept of security in the general context of interactivity on the Web implemented via executable content.
We will first examine the duality of Security versus Interactivity on the Web, and examine the evolution of the Web as a medium in the context of this duality. We will see that the security problem is most acute, at the highest level of interactivity provided by executable content such as a Java applet.
Next, we will arrive at a definition of the security problem, in the context of executable content. The chapter will conclude with a delineation of security breach/attack scenarios.
As mentioned briefly in the introduction above, a unique attribute of the Internet (and the Web) which makes it a powerful interactive mass medium, is the ability to transmit information consisting of data and executable programs, using a language like Java. This is called transportable code, or Executable Content. In this subsection, we will explore the relationship between security and interactivity achieved with executable programmatic extensions to either the server or the browser or both. It turns out there is almost an inverse relationship - more executable extensions means less security (and hence more risk) on both the server and the client ends.
The Web in its original form, and the underlying HTTP protocol, allowed only data to be sent from a server to the browser. This arrangement was not qualitatively different from the TV model, where the receiving device is a passive renderer of data sent by the transmitting device. This made real interactivity over the Web pretty difficult. Web users were limited to simply browsing static content served up by the server. But at this level, the Web was also the most secure, both on the server side and the client (browser) side. The only potential security risk on the server side was that a browser could request directory and content listings of the server's file-system. But that could be prevented by server side access-control. On the browser side, a potential security risk was that the server could send a huge document, which could overload the client Operating System. But this was preventable by process resource caps enforced by most operating systems.
HTML forms and server-side CGI scripts alowed for a limited degree of interactivity. But this interactivity was very expensive and cumbersome, because data had to be constantly shuttled back and forth between the server and the browser. Also the server had the burden of keeping track of the state of interaction for each of the multitude of browsers connected to it. From the security standpoint, CGI scripts opened up a breach on the server side, in that improperly written CGI scripts could be tricked into doing dangerous things like executing file-system delete commands on the server.
The concept of helper-apps and browser plug-ins was the next step forward in making the Web more interactive. In this model, a content provider shipped a custom program to users who installed it alongside their Web browsers. Subsequently, when appropriate data arrived at the browser, the helper app would kick in and render (or "play") the data. The helper app could also interact with the server independent of the Web browser. This allowed for true two-way interactivity. But this entailed that a user blindly trust the helper-app/plug-in to be safe and benign. The security implication was the potential for trojan-horse style attacks.
Helper apps could be looked upon as a two-part implementation of the executable content model, where the executable portion is shipped upfront, and the data portion is shipped on demand. The next logical step was true executable content, using a language like Java. With Java, anything going across the wire is a full-fledged program. This makes the Web truely interactive, sine the browser becomes infinitely adaaptive and extensible. A lot of the computational load can be more equitably shared between the server and the browser. And the content served can be richer and more complex. But this also opens up the full spectrum of security risks associated with any kind of program - from bugginess to intentional malicious behaviour.
So, while more executable content means richer interactivity. it also means higher security risks. This means that any implementation of executable content, such as Java or Java-enabled Web browsers, should also be designed from the ground up with multi-stage security features. Users of a Java enabled Web browser should not have to worry that a Java applet might be deleting files or sending private information out of their computers.
In this subsection, we will define precisely what constitutes the security problem entailed by and associated with executable content, and outline a solution strategy for this problem. This will form a frame of reference within which Java security features will be explained in subsequent sections of this chapter.
Any computer program has essentially unrestricted access to the computer's resources, within the confines of access controls defined by the operating system. A program developed by a local user of the computer is implicitly trusted as not being a security risk. Any consequences of the program's behavior-intentional or due to bugs-is accepted and borne by the user.
A program arriving from outside the computer via the network has to be greeted by the user with a similiar degree of trust, and allowed a similiar degree of access to the computer's resources, to serve any useful purpose. But the program was written by someone else, under no contractual or transactional obligation to the user. If this someone was a hacker, the executable content coming in could be a malicious program with the same degree of freedom as a local program.
Does the user have to completely restrict the outside program from accessing any resource whatsoever on the computer? Of course not. This would cripple the ability of executable content to do anything useful at all. A more complete and viable security solution strategy would be a six-step approach:
Step 1: Pre-visualize all potential malicious behaviour and attack scenarios.
Step 2: Reduce all such malicious behaviour to a minimal orthogonal basis set.
Step 3: Construct a programming environment/computer language which implicitly disallows the basis set of malicious behaviours, and hence by implication, all potential malicious behaviour.
Step 4: Logically or if possible axiomatically prove that the language/environment is indeed secure against the intented attack scenarios.
Step 5: Implement and allow executable content using only this proven secure language.
Step 6: Design the language such that any new attack scenarious arising in the future, can be dealth with by a corresponding set of counter-measuers, which can be retrofitted into the basic security mechanisms.
Working backwords from the above solution strategy, the security problem associated with executable content, can be stated as consisting of the following six sub-problems:
As we will see, Java has been designed from the ground up to address most (but probably not all) of the security problem as defined above. Before we move on to Java security architecure itself, we will identify the attack targets and scenarios in the next subsection.
In this subsection, we will list the various possible attack scenarios, and resources on a user's computer likely to be targetted by a potentially malicious external executable content modeule.
Attack scenarios could belong to one of the following categories (this is not an exhaustive list):
The following table lists the resources that could be potentially targeted, and the type of attack they could be subject to. A good security strategy will assign security/risk weights to each resource, and design an appropriate access policy for external executable content.
Damage Smuggle Lock up/ Steal Non- Impersonate
integrity information deny usage resource fatal
distraction
File system X X X X X
Confidential data X X X X X
Network X X X X X
CPU X X X
Memory X X X X
Output Devices X X X X
Input Devices X X X
OS, program state X X X X
In this section, we will move forward from the generic discussion of security issues related to executable content, and take a broad look at the fundamental implicit security mechanisms built into Java by its designers, in reference to the six-step approach outlined in the previous section.
Step 1: Visualize all attack scenarios
Instead of coming up with every concievable attack scenario, the Java security architecture posits potential targets of a basic set of attack categories, very similiar to the attack scenario matrix above.
Specifically, the Java security model covers the following potential targets:
against the following attack types listed in the table:
Step 2: Construct a basis set of malicious behavior
Instead of arriving at a basic set of malicious behaviour, Java posits a basic set of security hotspots, and implements a mechanism to secure each of these hotspots:
Step 3: Design security architecture against above behavior set
Construct a programming environment/computer language which implicitly disallows the basis set of malicious behaviours, and hence by implication, all potential malicious behaviour.
You guessed it-this language is Java !
Step 4: Prove security of architecture
Logically or if possible axiomatically prove that the language/environment is indeed secure against the intented attack scenarios.
Security mechanisms built into Java has not (yet) been axiomatically or even logically proven to be secure. Instead, Java encapsulates all of its security mechanism into distinct and well-defined layers. Each of these security locii can be observed to be secure by inspection, in relation to the language design framework and target execution environment of Java language programs and applets.
Step 5: Restrict executable content to proven secure architecture
The Java class file checker and bytecode verifier achieve this objective.
Step 6: Make security architecture extensible
Design the language such that any new attack scenarious arising in the future, can be dealt with by a corresponding set of counter-measuers, which can be retrofitted into the basic security mechanisms.
The encapsulation of security mechanisms into distinct and well-defined locii, combined with the provision of a Java Security Manager class, provides a generic mechanism for incremental enhancement of security.
In this section, we will examine specific details of security mechanisms built into Java.
The first tier of security in Java is the language design itself -the syntactical and semantic constructs allowed by the language. The following is an examination of Java language design constructs with a bearing on security.
Java is fully object oriented, with every single primitive data structure (and hence derived data structures) being a first class full-fledged object. This ensures that all the theoretical security advantages of OOP permeates the entire syntax and semantics of programs written in Java:
Classes and methods can be declared as FINAL, which disallows further subclassing and method overriding. This prevents malicious modification of trusted and verified code.
Typecasting is security checked both statically and dynamically, which ensures that a declared compile-time type of an object is are strictly compatible with eventual run-time type, even if the object transitions through type-casts and coersions. This prevents malicious type camoflaging.
This is possibly the strongest guaranntor of security built right into the Java language. Banishment of pointers ensures that no portion of a Java program is ever anonymous. Every single data structure and code fragment has a handle which makes it fully traceable.
(e)Language syntax for thread-safe data structures
Java is multithreaded. Java language enforces thread-safe access to data structures and objects. Chapter 25 examines Java threads in detail, with examples and application code.
(e)Unique object handles
Every single Java object has a unique hash-code associated with it. This means that the state of a Java program can be fully inventoried at any time.
At compile time, all the security mechanisms implied by the Java language syntax and semantics are checked, including conformance to private and public declarations, type-safeness, initialization of all variables to a guaranteed known value.
Each compiled class file is verified to conform to the currently published official class file format. The class file is checked for both structure, and consistency of information within each component of the class file format. Cross references between classes (via method calls or variable assignments) are verified for conformance to public and private declarations.
Each Java class is also assigned a major and minor version number. Version mismatch between classes within the same program is checked.
Java source classes are compiled into byte codes. The byte code verifier subjects the compiled code to a variety of consistencey and security checks. The verification steps applied to byte code include:
Java classes are defined within packages. Package names qualify Java class names. Packages ensure that code coming from the network is distinguished from local code. An incoming class library cannot maliciously shadow and impersonate local trusted class libraries, even if both have the same names. This also ensures unverified, accidental interaction between local and incoming classes.
Late linking and binding ensure that the exact layout of run-time resources, such as stack and heap is delayed as much as possible. This constitutes a roadblock to security attacks utilizing specific assumptions about the allocation of these resources.
The default mechanism of run-time loading of Java classes is to fetch the refered class from a file on the local host machine. Any other way of loading a class, including from across the network, requires an associated ClassLoader. A ClassLoader is a subtype of the standard Java ClassLoader class which has methods that implement all the consistency and security mechanisms and apply them to every class that is newly loaded.
For security reasons, the ClassLoader cannot make any assumptions about the bytecode. The byte code could have been created from a Java program compiled with the Java compiler, or it could have been created by a C++ compiler modified to generate Java byte code. This means the ClassLoader kicks in only after the incoming bytecode has been verified.
ClassLoader has the responsibility of creating a namespace for downloaded code, and resolving the names of classes referenced by the downloaded code. The ClassLoader enforces package-delimited namespaces.
In C and C++, the programmer has the explicit responsibility to allocate and deallocate memory, and keep track of the all the pointers to allocated memory. This often is a maintanence nightmare, and a major source of bugs resulting from memory leaks, dangling pointers, null pointers, mismatched allocattion and deallocation operations.
Java eliminates pointers, and with it the programmer's obligation to explicitly manage memory. Memory allocation and deallocation is automatic, strictly structured and fully type-safe. Java uses garbage collection to free unused memory instead of explicit programmer mediated deallocation. This eliminates memory-related bugs as well as potential security holes. Manual allocation and deallocation allows unauthorized replication, cloning and impersonation of trusted objects, as well as attacks on data consistency.
SecurityManager is a generic and extensible locus for implementing security policies, and providing security wrappers around other parts of Java, including class libraries and external environments (such as Java enabled browsers and native methods). The SecurityManager class itself is not intended to be used directly (each of the checks defaults to throwing a security exception). It is a shell class, intended to be fleshed out via subclassing, to implement a specific set of security policies.
Among other features, it has methods to
The major source of security threats from and to Java programs is Java code coming in from across the network, and executing on the client machine. This class of transportable Java programs are called Java applets. Java applets have a very distinct set of capabilities and restrictions within the language framework, especially from the security standpoint.
File System and Network access restrictions on applets arriving from the network
Applets loaded over the network have the following restrictions imposed on them:
The above strict set of restrictions on access to local filesystem apply to applets running under NetScape Navigator 2.0 beta versions. The JDK 1.0 Appletviewer slightly relaxes the above, by letting the user define a specific explicit list of files that can be accessed by applets.
Applets cannot:
Applets can read some system properties by invoking System.getProperty(String key). Applets under Netscape 2.0 have unrestricted access to these properties. Sun JDK 1.0 appletviewer allows individual control over access to each property. The following table lists the type of information returned for various values of key.
The following information is not accessible to applets under Netscape 2.0. JDK 1.0 appletviewer allows user controllable access to one or more of these resources.
There are two different ways that applets are loaded by a Java system. An applet can arrive over the network, or can be loaded from the local filesystem. The way an applet is loaded determines its degree of freedom.
If an applet arrives over the network, it is loaded by the ClassLoader, and is subject to security checks imposed by the ClassLoader and SecurityManager classes. If an applet resides on the client's local filesystem in a directory listed in the user's CLASSPATH environment variable, then it is loaded by the filesystem loader.
From a security standpoint, locally loaded applets can:
Having examined the issue of security of executable content both in general and specifically in the framework of Java, we will now examine some aspects of security not fully addressed by the current version of the Java architecture. We will also see if for some types of threats, 100 % security can be achieved at all.
The following components of the Java architecture, are the locii of security mechanisms:
However, security provided by each of these layers can be diluted, or defeated in some ways, with varying degree of difficulty:
Security issues which cannot easily be addressed within Java (or any other mechanism of executable content for that matter) include:
One generic way to deal with security problems, is for Java applet classes to be sent encrypted and digitally signed. The ClassLoader, SecurityManager and even the byte code verifyer can include decryption and signature verification methods built in.
These and other open issues related to Java security are topics of ongoing debates and exploration of specific and involved security breach scenarios, especially on online forums. The next and final section of this chapter has pointers to references and sources of further information on this topic.
UseNet Newsgroups
Web Sites
Drew Dean and Dan S. Wallach, Security Flaws in the HotJava Web Browser, November 3, 1995.
ftp://ftp.cs.princeton.edu/reports/1995/501.ps.Z;
James Gosling and Henry McGilton, The Java Language Environment: A White Paper, Sun Microsystems, May 1995.
ftp://java.sun.com/docs/JavaBook.ps.tar.Z;
Sun Microsystems, HotJava!: The Security Story.
http://java.sun.com/1.0alpha3/doc/security/security.html;
Sun Microsystems, The Java Language Specifications: Version 1.0 Beta.
http://java.sun.com/JDK-beta/psfiles/javaspec.ps;
Frank Yellin, Low Level Security in Java, Sun Microsystems.
Sun Microsystems, FAQ - Applet Security.
Joseph A. Bank, Java Security, Massachusetts Institute of Technology,
http://www-swiss.ai.mit.edu/~jbank/javapaper/javapaper.html
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation