Runtime Enforcement Enforcement of the Java Language Rules

Array bounds checking In theory, the bytecode verifier can detect certain cases of array bounds checking, but in general, this check must take place at runtime. Consider the following code: void initArrayint a[], int nItems { for int i = 0; i nItems; i++ { a[i] = 0; } } Since nItems and a are parameters, the bytecode verifier has no way of determining whether this code is legal. Hence, array bounds checking is always done at runtime. Failure to meet this rule results in an ArrayIndexOutOfBoundsException . Object casting The verifier can and will detect the legality of certain types of casts, specifically whenever unrelated classes are cast to each other. The virtual machine must monitor when a superclass is cast into a subclass and test that casts validity; failure to execute a legal cast results in a ClassCastException . This holds for casts involving interfaces as well since objects that are defined as an interface type rather than a class type are considered by the verifier to be of type Object .

3.3 Comparisons with Previous Releases

At the level of the Java language, little has changed between Java 1.1 and any release of the Java 2 platform. One thing which has changed is bytecode verification: in 1.1, the virtual machine did not perform bytecode verification of classes on the classpath. This is really a reflection of class loading policies: starting with the Java 2 platform, classes on the classpath are loaded by a traditional class loader, which subjects them to verification.

3.3.1 Controlling Bytecode Verification

Bytecode verification seems like a great thing: not only can it help to prevent malicious attacks from violating rules of the Java language, it can also help detect simple programmer errors −− such as when we changed the access modifier of acctNo in our CreditCard class but forgot to recompile our Test class. Nonetheless, in 1.1 only classes loaded by a browser are subject to bytecode verification. In typical usage, this is a workable policy. Browsers always ensure that the code imported to run an applet is verified, and Java applications are typically not verified. Of course, this may or may not be the perfect solution: If a remote site can talk an end user into installing a local class in the browsers classpath , the local class will not be verified and may violate the rules weve discussed here. In Java 2, this is much harder since the class must be added to the jar file containing the core API classes. • You may implicitly rely upon the verifier to help you keep files in sync so that when one is changed, other files are verified against it. • As a user, you theoretically have limited control over the verifier −− though such control depends on the browser you are using. If you are running a Java application, you can run java with the −verify option, which will verify all classes. Similarly, if you are using a browser written in Java −− including the appletviewer −− you can arrange for the java command to run with the −noverify option, which turns verification off for all classes. Occasionally, a browser not written in Java will allow the user to disable bytecode verification as well −− e.g., Internet Explorer 3.0 for the Mac had this capability, although it was 50 present only because the bytecode verifier could not run in certain limited memory configurations. However, although these options to the virtual machine are well−documented, they are not implemented on all platforms and they have not survived in Java 2. One way to ensure that application code is run through the bytecode verifier in 1.1 is to use the secure launcher from Appendix D.

3.4 Summary

Because the notion of security in Java is pervasive, its implementation is equally pervasive. In this chapter, weve explored the security mechanisms that are built into the Java language itself. Essentially, at this level the security mechanisms are concerned with establishing a set of rules for the Java language that creates an environment where an objects view of memory is well−known and well−defined so that a developer can ensure that items in memory cannot be accidentally or intentionally read, corrupted, or otherwise misused. We also took a brief look at Javas bytecode verifier, including why it is necessary and why you should turn it on, even for Java applications. Its important to keep in mind that the purpose of these security constraints is to protect the users machine from a malicious piece of code and not to protect a piece of code from a malicious user. Java does not and could not prevent a user from acting on memory from outside the browser, with possibly harmful results. Chapter 3. Java Language Security