Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

The third rule prevents someone from accessing non-local hard drives, such as those on a local area network or intranet. Like the first rule, this provision closes many opportunities the malicious programmer might have for stealing confidential information or for planting malicious programs.

	ON THE WEB
	http://java.sun.com/sfaq/#examples Use these Sun examples to test your browser’s behavior.

Sun provides sample applets at http://java.sun.com/sfaq/#examples to test your browser’s security. Your browser should catch security exceptions when you attempt to run these applets from the Internet. You shouldn’t get exceptions when you run http://java.sun.com/sfaq/example/getOpenProperties.html, which demonstrates the 10 system properties untrusted applets are allowed to read, or http://java.sun.com/sfaq/example/myWindow.html, which opens a standalone window (although you should see the “Untrusted Applet” message).

Note that Sun recommends somewhat tighter restrictions for applets downloaded from the Web versus those loaded from the local file system. For full details see http://java.sun.com/sfaq/.

Although no one has suggested that it’s impossible to build malicious applets—someone is probably working on one right now—Sun has certainly gone to great lengths to make it difficult. If someone wants to attack your system, it’s far easier for them to attack through a mechanism such as an ActiveX control than through a Java applet. As long as most users are downloading both, malicious programmers will continue to favor ActiveX controls.

	ON THE WEB
	http://www.cert.org/ If you’re responsible for security at your organization, you should get familiar with the services of the Computer Emergency Response Team (CERT) Coordination Center. They’ll keep you up to date on known security holes and fixes.

The Security of Compiled Code

The Java compiler checks Java code for security violations. It is a thorough, stringent compiler that enforces the restrictions previously listed. However, it is possible that Java code could be compiled with a “fixed” compiler that allows illegal operations. This is where the Java class loader and bytecode verifier come into play. Various types of security are enforced by the runtime system on compiled code.

Java .class File Structure

Java applets and applications are made up of .class files that are compiled bytecode. All public classes used in a Java applet or application reside in their own separate .class file. They may be transferred over the network a file at a time or bundled into a .zip or .jar file. The .class file is a series of bytes. Longer values are formed by reading two or four of these bytes and joining them together. Each .class file contains

•  A magic constant

•  Major and minor version information

•  The constant pool

•  Information about the class

•  Information about each of the fields and methods in the class

•  Debugging information

The constant pool is how constant information about the class is stored. It can be any of the following:

•  A Unicode string

•  A class or interface name

•  A reference to a field or method

•  A numeric value

•  A constant string value

As previously mentioned, all references to variables and classes in the Java language are done through symbolic names, not pointers. This is true in the .class file as well. Elsewhere in the .class file, references to variables, methods, and objects are accomplished by referring to indices in this constant pool. Security is thus maintained inside the .class file.

---

NOTE:  Each method can have multiple code attributes. The CODE attribute signifies Java bytecode, but other code attributes, such as SPARC-CODE and 386-CODE, allow for a machine code implementation of the method. This technique allows for faster execution, but such native code cannot be verified to be secure.

---

The class loader of most current Java implementations, including Sun’s own HotJava browser, considers any code that comes from a remote source to be potentially hostile and will not use any native code contained in a Java .class file unless the user designates the applet as “trusted.” Some of these browsers will run native code loaded from local .class files, however.

More About Bytecodes

In addition to the actual bytecodes that execute a method, the CODE attribute also supplies other information about the method. This information is for the memory manager, the bytecode verifier, and the JVM’s exception handling mechanism:

•  Maximum stack space used by the method.

•  Maximum number of registers used by the method.

•  Bytecodes for executing the method.

•  Exception handler table. This is a lookup table for the runtime system that provides an offset to where the exception handler is found for code within a starting and ending offset.

Six primitive types are available in the JVM:

•  32-bit integer (integers)

•  64-bit integer (long integers)

•  32-bit floating point numbers (single float)

•  64-bit floating point numbers (double float)

•  Pointers to objects and arrays (handles)

•  Pointers to the virtual machine code (return addresses)

The Java VM also recognizes several array types:

•  Arrays of each of the primitive types (except return addresses)

•  Arrays of Booleans, bytes (8-bit integers), shorts (16-bit integers), and Unicode characters

In the case of an array of handles, an additional type field indicates the class of object that the array can store.

Each method has its own expression-evaluation stack and set of local registers. The registers must be 32-bit and hold any of the primitive types other than the double floats and the long integers. These are stored in two consecutive registers, and the JVM instructions, opcodes, address them using the index of the lower-numbered register.