13.1 Java

only for RuBoard - do not distribute or recompile

Java is a complex object-oriented language that has a syntax resembling that of the C++ language. Invented by engineers at Sun Microsystems, Java was originally intended for writing small programs that would be downloaded over cable modems to television set-top boxes. Because the theory was that set-top boxes might change over time, Java programs were intended to run on a virtual computer that could be adapted, over time, to any particular combination of computer hardware and software. Because it was theoretically operating-system independent, Java was quickly championed by competitors of Microsoft, who saw the new language as a way of attacking the entrenched monopoly of the Windows/Intel desktop computing environment.

Alas, raising the performance of Java applications to the level of native desktop applications proved to be beyond the technical abilities of the entire computer industry. By the late 1990s, most of the "Java on the desktop" projects had failed. At the same time, Java became increasingly popular for server-side applications particularly at large financial companies, who found that they could develop Java applications on relatively slow desktop computers and then simply move the programs to large-scale "enterprise" servers and have the programs run a hundred times faster and/or serve thousands of simultaneous users.

Today Java also lives on as an instructional language at many colleges and universities. A subset of the Java language is now used on some embedded devices, including smart cards and cellular telephones. Finally, many web sites continue to download small Java "applets" such as stock and news tickers to their visitors. Ironically, these applets finally deliver on Java's original vision they are small, mobile programs that can be downloaded over a reasonably fast Internet connection and that provide a limited amount of local interactivity.

13.1.1 A Little Java Demonstration

Here is a simple Java program:

import java.awt.*; import java.applet.*; public class HelloWorld extends Applet {   public void paint (Graphics g){     g.drawString("Hello World!", 100, 25);   } }

This program creates a Java applet class called HelloWorld. The class has a single method called paint. When the class is loaded and run, the string "Hello World!" is displayed at location (100,25).

The Java program must be placed in a file called HelloWorld.java. It is then compiled with the javac Java compiler, creating a file called HelloWorld.class:

% javac HelloWorld.java % ls -l Hello*  -rw-rw-r--  1 simsong  wheel  418 May 27 16:10 HelloWorld.class -rw-rw-r--  1 simsong  wheel  167 May 27 16:05 HelloWorld.java %

To display this applet, you need to have an HTML file that references the class file with an <APPLET> tag. Here is such an HTML file:

<html><head> <title>Hello Java!</title> </head> <body> <hr> <APPLET code = "HelloWorld.class" width = 300 height = 50 ></applet> <hr> </body></html>

If the HTML file and the HelloWorld.class class file are placed in the same directory on the web server, you can run the Java applet by viewing the HTML file using a Java-enabled browser. Once the HTML file loads, the browser will automatically download the file HelloWorld.class and start executing the applet. You can also run the applet using the Java program Applet Viewer. Both are shown in Figure 13-1.

Figure 13-1. The HelloWorld Java applet running in a web browsers and in the Java Applet Viewer

The HTML 4.0 specification states that the <APPLET> tag has been deprecated in favor of the <OBJECT> tag. Using the <OBJECT> tag, the previous example could be rewritten:

<html><head> <title>Hello Java!</title> </head> <body> <hr> <OBJECT code = "HelloWorld.class" width = 300 height = 50 ></OBJECT> <hr> </body></html>

For more information on the <OBJECT> tag, see http://www.w3.org/TR/html4/struct/objects.html, and the many excellent Java books available today.

13.1.2 Java's History

Although today Java is widely thought of as a reasonably secure language for writing programs that are downloaded over the Internet to web browsers, it wasn't designed for this purpose. Indeed, Java's security model was added largely as an afterthought. To understand the security issues with Java today, it's important to understand something about the history of the language.

Java came into existence in April 1991 when a group of "refugee" engineers from Sun Microsystems were hard at work on a stealth project designed to catapult Sun into the world of consumer electronics. Sun envisioned a future in which toasters, remote control systems, stereos, and cable decoder boxes were all programmed using a common computer language with programs that would be downloaded on demand over a network. The stealth project was designed to leverage Sun's experience with computer languages, system design, and silicon manufacturing to turn the company into a major consumer electronics technology supplier.

The key to dominating this new world was a new computer language developed by James Gosling. Called Oak, the language was designed to produce programs that would be compact and highly reliable. Compactness was necessary because Oak programs were going to be downloaded over networks whenever it was necessary to change them. And reliability was necessary, as well, because programs in this language had to be able to run for months or years at a time without outside intervention: you can't expect to dominate the market if you sometimes need to tell the average American that his toaster oven has to be rebooted to continue operation.

Instead of being compiled for a specific microprocessor, Oak was designed to be compiled into an interpreted bytecode that would run on a virtual machine. Simple economics drove the decision to use a virtual machine: a portable bytecode would allow consumer electronics manufacturers to change their microprocessor without losing compatibility with existing programs. Unlike the desktop computers of the day, the microprocessor would truly become a commodity.^[1]

^[1] Sun was correct that desktop computers were destined to become a commodity, but it happened a different way than Sun anticipated. Instead of adopting a new architecture and architecture-based programming language, companies such as Advanced Micro Devices and TransMeta simply cloned the overly-complex Intel x86 instruction set. Meanwhile, Intel started releasing low-cost microprocessors such as its Celeron series, essentially competing with itself.

The first test for Oak was an interactive cable TV decoder box that Sun was designing for Time Warner. In April 1993, Time Warner assured Sun that the workstation vendor would be awarded Time Warner's contract for the interactive cable TV trial because Sun had superior technology. But on June 14, 1993, Time Warner awarded the set-top box contract to Silicon Graphics, Inc. It was perhaps just as well for Sun that interactive cable TV was a failure.^[2]

^[2] Eric Greenberg, formerly a lead in Netscape's security group, writes, "Jim Clark, Netscape's founder, initially envisioned Mosaic as a product to be used within an interactive cable TV box for programming the programs you wanted to see. This was the first business model for Mosaic. Fortunately, the Mosaic team saw past this pipe dream and quickly focused on the Internet and the enterprise." (Eric Greenberg, personal communication, March 22, 1997)

In the months that followed, the Oak team repositioned their language for the world of CD-ROMs and multimedia publishing. The goal was to use Oak to develop CD-ROM applications that could run on Windows, Macs, and Unix-based personal computers. Right around this time, another multiplatform phenomenon was sweeping the computer industry: the World Wide Web. This was great news for the Oak team; they had a language that was designed to be small and portable. The team quickly realized that they could use the Web to download programs to an end user's computer and have the programs run instantly on the user's desktop.

In July 1994, Patrick Naughton, a member of the team, wrote a "throwaway" web browser named WebRunner to demonstrate the idea. Within a month, the browser was rewritten from scratch in Oak, and a system for running downloaded applets was designed and implemented. Realizing that "Oak" was a poor name for a computer language, Sun renamed the language "Java" after the coffee craze that was sweeping the country. Eight months later, Sun formally announced Java and its HotJava web browser at the 1995 SunWorld tradeshow.

That same day, Netscape announced its intention to license Java for use in the Netscape Navigator web browser.

13.1.3 Java, the Language

Java is a modern object-oriented language that has a syntax similar to C++, dynamic binding, garbage collection, and a simple inheritance model. Although Java was largely promoted as a language for the World Wide Web, Java is, in fact, a general-purpose computer language that can be used for writing anything from simple five-line toy programs to complicated applications. One of the largest users of Java today are investment houses, which have used Java to create large-scale web-based applications and financial models.

What initially distinguished the typical Java implementation from other computer languages was the runtime environment. Instead of being compiled for a particular microprocessor, Java programs are compiled into a processor-independent bytecode. This bytecode is loaded into a computer's memory by the Java Class Loader . Finally, the bytecode is run on a Java virtual machine ( JVM).

The Java virtual machine can run Java programs directly on an operating system such as Windows or Mac OS; alternately, the JVM can be embedded inside a web browser, allowing programs to be executed as they are downloaded from the Web. The JVM can execute the Java bytecode directly using an interpreter. Or, it can use a "just-in-time" compiler to convert the bytecode into the native machine code of the particular computer on which it is running. This whole Java cycle is depicted in Figure 13-2.

Java can also be compiled directly into machine code and run on a target system. Used this way, Java loses its runtime advantage of being able to run on any computer and any operating system that has a Java virtual machine, but it retains many of its advantages over C++ (and similar languages), including that of generating code that has automatic memory management.

Figure 13-2. The Java cycle

13.1.4 Java Safety

From the beginning, the Oak team wanted to create a language that would encourage programmers to write code that was inherently reliable. Starting with C++, Gosling and his team removed many of the features from C++ that are confusing or commonly misused. In this way, they sought to increase the safety of the language and the reliability of programs written with it.

The main way that Java achieves this reliability is by providing automatic memory management. Specifically:

Instead of forcing the programmer to manually manage memory with malloc( ) and free( ), Java has a working garbage collection system. As a result, Java programmers don't need to worry about memory leaks, or about the possibility that they are using memory in one part of an application that is still in use by another.
Java has built-in bounds checking on all strings and arrays. This eliminates buffer overruns, which are another major source of C and C++ programming errors and security flaws.
The Java language doesn't have pointers that can be arithmetically manipulated and dereferenced. That's good, because many C/C++ programmers don't understand the difference between a pointer to an object and the object itself.^[3] Contrary to the understanding of many non-Java programmers, however, Java does have "object references" that behave in a fashion similar to C pointers in many circumstances.

^[3] C lets you do some interesting things. For instance, if you define char *p; int i; in a program, you can then use the terms p[i] and i[p] almost interchangeably in your code. Few C programmers understand the language well enough to understand quirks such as this.
Java has only single inheritance, making Java class hierarchies easier to understand. And because Java classes can implement multiple interfaces, the language supports many of the advantages of multiple-inheritance languages.
Java is strongly typed, so you don't have problems where one part of a program thinks that an object has one type, and another part of a program thinks that an object has another type.
Java has a sophisticated exception-handling system.

All of these features combine to make Java what's generally known as a safe programming language: Java programs rarely misbehave wildly when given data that is slightly unexpected. (Instead, they simply generate an exception, which usually causes the program to terminate with a runtime error.) Because most security problems are the result of bugs and programming errors, it is thought that programs written in the Java language will be more secure than programs written in traditional languages such as C and C++.

In fact, Java's claims of security-through-safety are largely true: network daemons and web server plug-ins written in Java simply do not have the buffer overflow problems that have plagued the same programs written in C and C++. But there have been some controversies around Java security; for example, Java's supporters claimed that Java's safe execution environment could also provide sufficient security for executing downloaded mobile code. As we'll see, that is an overstatement.

13.1.5 Java Security

Java was not designed to be a secure programming language. Under Java's original vision, programs would only be downloaded by an equipment manufacturer or an approved content provider. Java was designed for a closed programmer community and for a somewhat constrained set of target environments.

When Java was repositioned for the Web, security became an obvious concern. By design, the Web allows any user to download any page from anyone on the Internet, whether or not it is from an approved content provider. If web users can download and run a program by simply clicking on a web page, there needs to be some mechanism for protecting users from malicious and poorly constructed programs.

13.1.5.1 Safety is not security

Having a safe programming language protects users from many conventional security problems. That's because many security-related problems are actually the result of programming faults.^[4] As we've stated, Java eliminates many traditional sources of bugs, such as buffer overflows.

^[4] In technical terminology, programmers make errors that result in faults being present in the code. When the faults cause the code to produce results different from the specifications, that is a failure. Most casual users simply refer to all of these as "bugs," and here in the book, we will too.

But a safe programming language alone cannot protect users from programs that are intentionally malicious.^[5] To provide protection against these underlying attacks (and countless others), it's necessary to place limits on what downloaded programs can do.

^[5] Ironically, Java's safety is an aid to people writing Trojan horses and hostile applications. Safety helps minimize the chances that a Trojan horse program will crash while it is reformatting your hard disk. Safety also helps ensure that the applet scanning your computer for confidential documents and surreptitiously mailing them to a remote site on the Internet won't go into an infinite loop.

Java employs a variety of techniques to limit what a downloaded program can do. The main techniques are the Java sandbox, the SecurityManager class, the Class Loader, and the Bytecode Verifier. These processes are illustrated in Figure 13-3 and described in the following sections.

Figure 13-3. The Java sandbox, SecurityManager class, Class Loader, and Bytecode Verifier

Sandbox

Java programs are prohibited from directly manipulating a computer's hardware or making direct calls to the computer's operating system. Instead, Java programs run on a virtual computer inside a restricted virtual space. Sun terms this approach to security the Java "sandbox," likening the Java execution environment to a place where a child can build and break things, generally not get hurt, and not hurt the outside world.

SecurityManager class

If all Java programs were restricted so that they couldn't send information over the network, couldn't read or write from the user's hard disk, and couldn't manipulate the computer's input/output devices, they would probably be nearly secure: after all, there would be little damage that the programs could do.^[6] Of course, these limitations would also make Java a much less exciting programming environment. There wouldn't be much of anything interesting that Java programs could do either.

^[6] But the code could replicate itself and tie up processing resources, resulting in a denial-of-service attack.

Java uses a series of special classes that allow programs running inside the sandbox to communicate with the outside world. For example, the Java class FileOutputStream allows a Java program to open a file for writing to the user's hard disk.

The creators of Java believed that programs that are downloaded from an untrusted source, such as the Internet, should run with fewer privileges than programs that are run directly from the user's hard disk. They created a special class, called SecurityManager, which is designed to be called before any "dangerous" operation is executed. The SecurityManager class determines whether the operation should or should not be allowed.

Class Loader

Because most of the security checks in the Java programming environment are written in the Java language itself, it's important to ensure that a malicious piece of program code can't disable the checks. One way to launch such an attack would be to have a malicious program disable the standard SecurityManager class or replace it with a more permissive version.

Such an attack could be carried out by a downloaded piece of machine code or a Java applet that exploited a bug in the Java runtime system. To prevent this attack, the Class Loader examines classes to make sure that they do not violate the runtime system.

Bytecode Verifier

To further protect the Java runtime security system, Java employs a Bytecode Verifier. The verifier is supposed to ensure that the bytecode that is downloaded could only have been created by compiling a valid Java program. For example, the Bytecode Verifier is supposed to assure that:

The downloaded program doesn't forge pointers.
The program doesn't violate access restrictions.
The program doesn't violate the type of any objects.

The Bytecode Verifier was originally implemented as a series of ad hoc checks, although there has been some academic work on developing bytecode verifiers that use theorem-proving and other formal systems for algorithmically asserting that the bytecode is "provably correct."

One of the purposes of the Bytecode Verifier was to allow the Java runtime system to replace runtime checks with load-time checks. As a program only needs to be loaded once, this would theoretically allow a Java application to run faster than might be expected in a purely interpretive environment. Verified programs could also be compiled into machine code without risk.

There are many problems with the Java security approach. These are described later in this chapter in Section 13.1.7.

13.1.6 Java Security Policy

Java security policy is complicated by the fact that the Java programming language is designed for two fundamentally different purposes:

Java is a general-purpose computer language for creating word processors, electronic mail clients, web browsers, and other kinds of productivity software. These programs might be resident on a user's computer or downloaded from an organization's internal web server.
Java is a language that is used to download applications from the Web that perform animations, create interactive chat systems, and perform complex calculations on the user's machine.

These different purposes require fundamentally different security policies: you want to be able to read files on your hard disk with your word processor, but it is probably inappropriate for an applet that implements a chat system to do the same. This dual nature leads to a much more complicated security model, which in turn leads to more potential bugs in the Java security enforcement mechanisms.

Java's original implementors envisioned three different security policies that could be enforced by web browsers that implemented the Java programming language:

Do not run Java programs.
Run Java programs with different privileges depending on the source of the program. Programs downloaded from web pages would run with severe restrictions. Programs loaded off the user's hard drive would have no restrictions. Table 13-1 summarizes a variety of restrictions.
No restrictions on Java programs. Allow the Java program to do anything at all with the computer's hard disk, network connectivity, and anything else.

Sun's HotJava browser implemented all three of these policies; the choice was left to the user. Most users chose policy #2.

Table 13-1. Some of the restrictions on downloaded Java applets present in most web browsers
Restriction	Reason
Cannot read the contents of files or directories on the client computer.	Protects the confidentiality of information on the user's computer.
Cannot write, rename, or delete files on the client computer.	Protects the user's data from unauthorized modification.
Cannot initiate a network connection to a computer other than the computer from which the Java applet was downloaded.	Prevents a downloaded applet from probing for security problems behind an organization's firewall.
Cannot receive network connections.	Prevents an applet from appearing to be a legitimate server on an organization's internal network.
Cannot display a window without a special "untrusted" border.	Prevents applets from creating windows that appear to be system windows.
Cannot create a ClassLoader or SecurityManager.	Prevents subverting the Java type checking system and disabling all Java security checks.
Cannot run system programs.	Prevents running arbitrary code.

As web developers have tried to do more with active content, Microsoft and Netscape have been forced to allow downloaded Java programs to execute more functions on the local computer. Rather than giving potentially hostile Java applets carte blanche, both companies have modified their Java runtime environments so that the user could decide on an applet-by-applet or program-by-program basis whether or not additional capabilities should be granted.

13.1.6.1 Internet Explorer's "security zones"

The Internet is an exceedingly complicated place; a security policy that makes sense for one web site might not make sense for another. You might work on a critical computer and normally want to have Java disabled; however, the HR department at your corporation might deploy an application that requires you to use Java to file employee evaluations and schedule vacation time.

Rather than force users to routinely open control panels as they move from one web site to another, Microsoft's Internet Explorer allows you to create multiple security policies for different categories of web sites, and then to assign web sites to these different categories. Microsoft calls these categories security zones . They were introduced with Internet Explorer 4 and are controlled with the "Security" tab of the Internet Options control panel (see Figure 13-4).

Figure 13-4. Microsoft's Internet Explorer allows you to assign different security policies to different categories of web sites. These categories are called security zones. Besides the four security zones that are shown in the window, there is a fifth security zone called the "My Computer zone."

Internet Explorer has five predefined security zones:

Local intranet zone: This zone is for all web sites that are located behind an organization's firewall, all sites that are accessed using Microsoft's networking protocols, and all sites that are accessed by unqualified domain names (e.g., http://site/). You can also add individual web sites to the Local intranet zone (see Figure 13-5). This is useful for organizations that have intranets accessed over the Internet using SSL. (If you need to access an intranet site without using SSL, you should uncheck the box that says "Require server verification (https:) for all sites in this zone." Using SSL is more secure because it encrypts the data, and because server certificates are used to verify the identity of the remote site, rather than relying on DNS.)

Figure 13-5. Internet Explorer allows you to control which web sites are included by default in the Local intranet zone. You can also explicitly add sites to the Local intranet zone.

Trusted sites zone: This zone is used for web sites that you specifically wish to trust. By default, this zone is assigned a "low" security level. This level allows all active content to be run without prompting the user or requiring that the content be digitally signed. By default, there are no sites in this zone.
Restricted sites zone: This zone is designed to be used for web sites that you do not wish to trust. By default, this zone is assigned a "high" security level.
Internet zone: This zone is for all web sites that are not in the Local intranet, Trusted sites, or Restricted sites zones. By default, this zone is assigned a "medium" security level.
My Computer zone: This security zone includes everything that is stored on the computer on which Internet Explorer is running everything on your hard drive or removable media but it excludes cached Java classes in the Temporary Internet Files folder.

Internet Explorer displays the current security zone in the lower right-hand corner of the status bar (see Figure 13-6).

There is an description of security zones in Chapter 7 of the Internet Explorer Resource Kit (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ie/Default.asp).

Figure 13-6. Internet Explorer displays the current security zone in the lower right-hand corner of the status bar.

13.1.6.2 Setting Java policy in Microsoft Internet Explorer

Microsoft Internet Explorer 4.0 and above establish four different policies for running Java programs. The policy that Internet Explorer uses depends on the current security zone for the web page that you are viewing. You can also create custom policies. These policies can be distributed to other users with the Internet Explorer Customization Wizard or the Internet Explorer's Administrator's Kit Profile Manager, both of which are included with the Internet Explorer Resource Kit.

To change the security policy for an Internet security zone, click on the Select the Security tab from the Internet Options panel, then select the Custom Level button. This will display the Security Settings panel (see Figure 13-7).

Figure 13-7. The Internet Explorer Security Settings panel allows you to change the security policy for the Microsoft Java virtual machine. If you select the Custom option, a button will appear allowing you to specify custom policy attributes.

The default Java security policies are:

Disable Java: This setting prevents Java programs and applets from executing.
High safety: This setting allows applets to run in the Java sandbox. It is the default setting for security zones that have the "high," "medium," and "medium-low" security levels.
Medium safety: This setting allows applets to run in the Java sandbox, to access "scratch space," and to access files as allowed by the user.
Low safety: This setting allows Java applets to run outside the Java sandbox, accessing all resources on your computer and making network connections to any other computer on the Internet. This is the default setting for security zones that have the "low" security level.
Custom: This setting allows you to specify each individual permission. When you select Custom, the Java Custom Settings... button appears, providing you with fine-grained control over the Java custom settings. See Figure 13-8.

Figure 13-8. When you press the Java Custom Settings... button in Figure 13-7, Internet Explorer displays a panel that gives fine-grained control over the Java security settings. Most users will not need to adjust these settings.

It is somewhat surprising that Microsoft decided to allow Java to be executed from sites that are in the Restricted security zone. You can increase the security of Internet Explorer by disabling Java for these sites. To disable Java for sites that are in the Restricted Sites security zone, follow these steps:

Select Internet Options from Internet Explorer's Tools menu.
Select the Security tab.
Select the Restricted Sites icon.
Click the Custom Level button.
Scroll down to the Microsoft VM section of the Security Settings window.
Underneath Java permissions, select Disable Java.

Microsoft Versus Java

As this book goes to press in 2001, it appears that the next Microsoft release will be without direct support for Java included. This is the latest salvo in the Microsoft vs. Java/Sun skirmishes. Earlier, Microsoft attempted to add proprietary extensions to Java. These were blocked by legal ownership of the Java name and trademark by Sun.

Microsoft personnel have explained that they want to optimize Java for their customers, and make it more reliable when used with Microsoft products. The claim is that as Windows and its applications evolve (and merge), outside technologies need to be altered to work reliably on Microsoft platforms. Many vendors and observers claim that this is another thinly veiled attempt by Microsoft to subvert a competing technology by either deploying a version that developers would need to license or purchase through Microsoft, or by shutting out competitors. The recent findings of a Federal court that Microsoft has engaged in anti-competitive activities in browser and operating system development are used to buttress these arguments.

Without attempting to judge the validity of arguments in this conflict, let us simply reiterate a general principle of security: if a vendor does not reliably support the security features of a standard or technology you want to use, or intentionally weakens them to create a competitive advantage, you should be concerned. In cases such as this, you need to decide whether to avoid the technology entirely, or reward that vendor by continuing to use its deficient products. It is important to understand the context of the products you depend upon, the history of the vendor, and the past record of that vendor's commitment to standards, security, and quality. Whatever the underlying reasons, we caution that future support for Java in Microsoft products may not be as robust or available as it has been. Caveat emptor.

13.1.6.3 Setting Java policy in Netscape Navigator

Netscape Navigator 6.0's Java policy can be set using the Advanced selection option of Netscape's Preferences control panel. On this panel there is a check-box followed by the words "Enable Java."

If this check-box is selected, then Java applets will be run on downloaded web pages. If this check-box is not selected, Java applets will not run.

If you would like to have more control over the Java security policy with Netscape Navigator, consider using an ad blocker such as AdSubtract or Web Washer. These programs allow you to selectively block or allow the execution of Java applets on a site-by-site basis. (Sophisticated users can also use the Java security policy file to obtain similar results.)

13.1.7 Java Security Problems

Since its initial release, the Java programming language has received almost as much attention in the newspapers for its security problems as for its actual uses. The majority of the Java security problems were found between 1996 and 1998 by a group of researchers at Princeton University's Secure Internet Programming (SIP) group. Most of the security problems discovered by the Princeton team were implementation errors: bugs in the Java runtime system that allowed specially-crafted Java applications to break out of the Java sandbox and execute arbitrary programs on the end user's machine. But a few of the problems discovered were design flaws in the Java language itself. The major errors found by the Princeton team included:

Bugs with the Java virtual machine that let programs violate Java's type system. Once the type system is violated, it is possible to convince the JVM to execute arbitrary machine code.^[7]

^[7] Indeed, Java's entire security system depends on maintaining the integrity of the Java type system. Maintaining that integrity depends on the absolute proper functioning of the SecurityManager class and the Bytecode Verifier. While the SecurityManager class was 500 lines long in the first set of Java implementations that were commercialized, the Bytecode Verifier was 3500 lines of rather twisty code. To make things worse, there was no clear theory or reason as to what makes Java bytecode correct and what makes it incorrect, other than the operational definition that "valid bytecode is bytecode that passes the Bytecode Verifier." For further information, see McGraw, Gary, and Edward W. Felten, Securing Java: Getting Down to Business with Mobile Code, 2nd Edition (John Wiley & Sons).
Class library bugs, which allow hostile programs to learn "private" information about the user or, in the case of Sun's HotJava browser, edit the browser's settings.
Fundamental design errors leading to web spoofing and other problems.

Most of the implementation errors discovered by the group were fixed shortly after they were reported. A complete list of the Princeton group's findings is on the Web at http://www.cs.princeton.edu/sip/.

Since then, more problems have been found in various implementations. For example, in August 2000, an error was found in the Java engine present in Netscape Navigator versions 4.04 through 4.74. The error, in a package called netscape.net, allowed Java applets to read any file on the host computer using the URL "file" protocol. For example, a Java applet could read the contents of the computer's autoexec.bat file by opening the URL file:///c:/autoexec.bat. The Java applet could then transmit the contents of files read in this manner to the web server from which the applet was downloaded. A programmer by the name of Dan Brumleve wrote a program called "Brown Orifice" to demonstrate the vulnerability. The Brown Orifice program ran a local web server on the victim's computer and allowed any machine on the Internet to view any file on the victim's computer. The vulnerability and the Brown Orifice program were publicized by CERT/CC in advisory CA-2000-15, which can be downloaded from http://www.cert.org/advisories/CA-2000-15.html. A similar problem was discovered in Microsoft's Java VM.^[8]

^[8] http://www.microsoft.com/technet/security/bulletin/ms00-059.asp

Alas, the most serious problem with Java is a not bug or a typo, but a fundamental design flaw: Java's security model was not formally specified until years after it was released! The Princeton group was forced to conclude that many of the apparent problems that they found in Java weren't necessarily security problems because no formal security model existed.

A formal security model would provide a sound theoretical and practical basis for the security policy decisions in the Java language. Such a model would start with policy goals what sort of functionality is desired of Java applets? The model would then explore the sort of capabilities the Java language and environment needs to provide these functions. The model might consider how the Java type system is used to enforce security, and therefore how the type system needs to be protected to provide those features. Unfortunately, no such security model was ever created.

According to the book Securing Java by Gary McGraw and Ed Felton:

Some progress was made toward this goal in a report commissioned by Sun back in 1996. The report, entitled Security Reference Model for JDK 1.0.2, explained (in informal English) Java's implicit security policy (at least for the base security sandbox). The SRM is available through www.javasoft.com/security/SRM.html. Creating the SRM was a useful exercise; unfortunately, any utility provided by the SRM was caught in the Internet-time cross fire. The SRM is completely out of date. Given the rigorous security demands of electronic commerce, documents like the SRM should be demanded by organizations using consumerware in their security-critical systems.

The good news for Java users and developers is that the vast majority of the security problems found were addressed shortly after they were discovered. Furthermore, there are no cases of Java flaws being used on a widespread basis to compromise end-user machines.

On the other hand, the fact that so many flaws were discovered so readily with Java implementations indicates that the technology was released prematurely into the marketplace and onto computer user's desktops. Ideally, outside security reviews should take place before products are released, rather than afterwards.^[9]

^[9] We say "ideally" because we realize this isn't how the marketplace has worked with most security-critical technology people use.

While the basic implementation flaws were all fixed, their presence created a vulnerability that continues to this day, because many browsers are still running the old, buggy Java engines. In our opinion, software vendors such as Sun and Microsoft need to be more open with their internal reviews, and they need to slow down the pace of development so that code can be evaluated more rigorously before it is deployed to millions of users. (Netscape used to have problems with openness, but as a result of creating the Mozilla project, large amounts of the Navigator code base have been released for public inspection and use.)

Users and customers, meanwhile, need to demand higher levels of security and overall software quality. They must also be willing to allow vendors to properly test code, rather than demanding the right to download the earliest "alpha," "beta," or "prerelease" program.

We recommend that users in high security environments disable Java entirely.

Hostile Applets

Dr. Mark LaDue, a graduate of Georgia Tech, has spent a considerable amount of energy developing a series of Java applets that demonstrate flaws in various implementations of Java. Applets that he has developed will crash a computer running Java, take control of a workstation on which it is running, factor integers without your permission, and divulge your email address. He has also developed a "self-defending applet killer" that will stop any other applets that are running and will kill any applet that is downloaded afterwards.

These applets and more can be found at LaDue's web page entitled "A Collection of Increasingly Hostile Applets" currently at http://www.cigital.com/hostile-applets/ and http://www.meurrens.org/ip-Links/java/codeEngineering/papers/hostile-applets.html. (The URL seems to change from time to time because of threatened legal action.)

only for RuBoard - do not distribute or recompile

13.1 Java

13.1 Java

13.1.1 A Little Java Demonstration

Figure 13-1. The HelloWorld Java applet running in a web browsers and in the Java Applet Viewer

13.1.2 Java's History

13.1.3 Java, the Language

Figure 13-2. The Java cycle

13.1.4 Java Safety

13.1.5 Java Security

13.1.5.1 Safety is not security

Figure 13-3. The Java sandbox, SecurityManager class, Class Loader, and Bytecode Verifier

13.1.6 Java Security Policy

Table 13-1. Some of the restrictions on downloaded Java applets present in most web browsers

13.1.6.1 Internet Explorer's "security zones"

Figure 13-4. Microsoft's Internet Explorer allows you to assign different security policies to different categories of web sites. These categories are called security zones. Besides the four security zones that are shown in the window, there is a fifth security zone called the "My Computer zone."

Figure 13-5. Internet Explorer allows you to control which web sites are included by default in the Local intranet zone. You can also explicitly add sites to the Local intranet zone.

Figure 13-6. Internet Explorer displays the current security zone in the lower right-hand corner of the status bar.

13.1.6.2 Setting Java policy in Microsoft Internet Explorer

Figure 13-7. The Internet Explorer Security Settings panel allows you to change the security policy for the Microsoft Java virtual machine. If you select the Custom option, a button will appear allowing you to specify custom policy attributes.

Figure 13-8. When you press the Java Custom Settings... button in Figure 13-7, Internet Explorer displays a panel that gives fine-grained control over the Java security settings. Most users will not need to adjust these settings.

Microsoft Versus Java

13.1.6.3 Setting Java policy in Netscape Navigator

13.1.7 Java Security Problems

Hostile Applets