10.2 Java Security
10.2 Java Security As was briefly mentioned before, Java was built from the ground up to limit what mischief a malicious Java applet could do. Java's creators had to release a language that would allow component downloading with the toughest security of any language while giving users a portable, flexible, and powerful feature set. This was no easy task. Security is always a cost/benefit compromise. Make the security so tight that no one can break it and you probably don't have much of a program. Give a program useful flexibility and you increase the risk of malicious use. 10.2.1 Java Security -- Classic ModelJava's original security model, released in JDK 1.0, is a multitiered protected environment called the sandbox . The sandbox severely limits what remotely accessed applets can do, while allowing locally launched and trusted applets full system access. Java's sandbox (see Figure 10-2) is maintained by cooperative JVM components known as the Byte Code Verifier , the Class Loader , and the Security Manager . Figure 10-2. Java applet pathway and security Even before applet byte code reaches the JVM's sandbox, Java goes out of its way to protect the user . The Java language is designed to prevent misbehaving memory pointers and provides range-checking on strings and arrays. In most languages it is all too easy to write buggy code because memory management is the responsibility of the programmer, not the language. If you've been using Microsoft Windows for any length of time, you are well acquainted with the problems of misbehaving programs stepping on top of each other. In C and C++, memory pointers are declared at compilation time and can request specific addresses in memory. Java handles memory locations through the use of symbolic memory locations that are resolved by the JVM at runtime. This prevents sloppy coding, and helps prevent "stack attacks" that are often in a hacker's arsenal of tricks. Even more checks are implemented by the Java compiler. 10.2.1.1 Byte Code VerifierJava source-code text is compiled into platform-neutral byte code. Byte code is downloaded to a browser's JVM and eventually translated into platform-specific machine language. But before the byte code is executed, it is subjected to a wide range of security checks. Because byte code can come from any source, JVMs don't assume that byte code was compiled by a trusted, reliable Java compiler. The Byte Code Verifier assumes exactly the opposite and makes sure that the byte code is safe. The newly downloaded byte code is checked for inappropriate accesses , forged memory pointers, and for proper object usage (often called typing ). 10.2.1.2 Applet Class LoaderAfter the byte code passes the Verifier process, the Applet Class Loader takes control. When a Java program starts to execute, it can call different Java classes to assist it. Classes can be many things in Java, but for our reference, classes are Java files, subroutines, methods , and variables that can be called by a Java program. A Java program can contain many classes. And most Java programs call for assistance from the built-in Java classes to assist with routine tasks , much like the API between the operating system and a program. Remotely loaded Java programs are considered separate special classes. 10.2.1.3 Name spacesOne of the most important things the Class Loader does is maintain separate n ame spaces for each applet. A name space is nothing more than a set of rules and guidelines for naming different objects so they can be retrieved later on. All objects in a name space follow the same rules and syntax. A name space can be likened to a library's book cataloging index. In most libraries, the Dewey decimal classification system is used to index and find books. It has a particular order to it, and no two books should share the same identification number. Within a name space you can call your memory areas and subroutines almost anything you want. If different applets could share the same name space, one program could accidentally (or intentionally) overwrite a variable that another applet was using, simply because a variable name was identical. Java class files stored on the local system are exceptions to the rule. Because all local classes are fully trusted (and assumed secure) by default, they are loaded into a shared name space. Downloaded programs are usually not allowed into the local name space, and cannot overwrite a local class file with their own routine. Consider if two different applets shared a subroutine name called WRITE_BYTE. The first Java program is a locally trusted program that updates web site information and has full rights to the system. The second remotely downloaded, untrusted Java applet contains a harmless-looking WRITE_BYTE subroutine. Without the Class Loader's separate name space enforcement, the untrusted applet could possibly call the locally trusted WRITE_BYTE routine and start writing a continuous series of zeros over your datafiles. Forcing Java applets to have separate name spaces also helps prevent malicious programs from "ganging up" on or manipulating other trusted classes. Whenever an applet requests a class variable or routine, the local built-in class name space is checked first. This way, no rogue program could insert its malicious subroutine or variable in place of Java's built-in classes. It is the job of the next security component to make sure no malicious applet tries to insert a rogue Applet Class Loader that could manipulate name spaces. 10.2.1.4 The Security ManagerThe Java Security Manager, as its name implies, has the role of security enforcer. All requests for computer resources (memory, thread, operating system, and network access) are first submitted to the Security Manager, which examines the Java program for any suspicious activity. The customizable Security Manager can choose to allow the activity, or deny it. It also prevents the loading of fake class loaders, which could bypass separate name space security. By default, the Security Manager (prior to JDK 1.2) will not intentionally allow the following actions by remotely downloaded, untrusted code:
All of these enforced rules prevent hundreds of known malicious hack attacks. Even the last rule, as arcane as it seems, prevents hack attempts. Not allowing Java applets to access externally stored memory variables prevents hostile programs from learning which programs you use. A rogue program could search for programs with known security holes that could later be used in other easier hack attempts. Also, if a Java applet program could write to externally stored files or memory values, it could override the CLASSPATH variable with its own path . 10.2.1.5 CLASSPATHThe CLASSPATH memory variable is used by the JVM to learn where the locally trusted Java class files reside (most are in archive files). Locally trusted class files should include the Java support files included with your browser and any local Java programs you installed and fully trust. The cute little animated Java program you downloaded from the Internet probably shouldn't be located on the CLASSPATH. The CLASSPATH variable can be set in your AUTOEXEC.BAT file, or from the command line with the DOS SET command. For example: C:\>SET CLASSPATH=C:\WINDOWS\JAVA\CLASSES When Internet Explorer downloads a Java applet, it searches for CLASSPATH in the following order (I'm leaving out a few unnecessary steps):
If a rogue program was able to redefine CLASSPATH by modifying any of the pathways listed, it could make itself appear as a trusted program and gain otherwise unauthorized access to system resources. With the notable exception of JDK's built-in byte code (and any code lying in the CLASSPATH) and extensions, all Java programs using JDK 1.1 security are subjected to the same security verification process. Java's multitiered defense system is complex, but it works for the most part. It's important to note that if any one of the cooperative components develops a security leak, the whole Java model is compromised. Each component relies on the fact that the other is doing its job. 10.2.1.6 Some say the sandbox is too secureIn fact, one of the biggest criticisms of early Java concerned what you couldn't do with it. Because a Java applet couldn't manipulate the local file system, it was virtually impossible for any company to write a Java applet of any serious consequence. You can't write a spreadsheet or word processing program because a Java applet can't manipulate local data in any way. For a while it looked like Java's successful security model would be a victim of its own success. 10.2.1.7 Java security expandsJava's version 1.0 security model left a lot to be desired. As mentioned earlier, Java was severely limited any time it was not loaded locally from the user's hard drive. JDK version 1.1 allows Java applets to be "signed" and trusted (digital signing and authentication will covered in Chapter 11). Unsigned applets are treated as untrusted and placed in the restrictive security sandbox. Signed code, however, can be trusted by the user and gain full access to the user's system. The first browser to implement applet signing was Microsoft's Internet Explorer 3.x, which already had it working with ActiveX's security feature set. Sun's HotJava and Netscape Navigator followed soon after. Now Java's security model was "black and white." Untrusted code runs in the sandbox, and trusted code has full system access. But users wanted even more granularity. What if they wanted an applet to write to C:\TEMP or to open a new network connection to a third-party web site, but nowhere else? Was there a way to see what system resources an applet wanted before executing, and enforcing what it could access? 10.2.2 Java 2 |
Security -- A Granular Approach
|
With the release of Java 2, the security model (see Figure 10-3) where all local code is trusted, by default, is removed. All code, local or remote, is treated the same and undergoes the same security checks. New security zones, or protection domains , are used to define levels of security. Local resource access can be defined from highly restricted to fully accessible by domain. All Java programs within the same domain are granted the same level of permissions. In order to be within the same domain, the program must be loaded from identical locations and must be signed by the same private digital key. A new, customizable security policy file can be applied against byte code to implement a very granular level of control.
Figure 10-3. Java 2 security model
|
You can use Microsoft tools to define the permissions each applet can have or define one security policy to cover anything signed with the same digital signature and from the same source URL. Network administrators can create enforceable, enterprise-wide Java security policies to control what happens on each user's desktop. Unfortunately, the new security features released in Java 2 aren't being widely utilized, so that the classic sandbox security model easily makes up the majority of the security in any Java environment. Digital certificates and code signing, which are integral to Java 2 security, are covered in Chapter 11.
10.2.3 Archive Formats
In order for a Java program to be executed, all called files, which make up the program, must be loaded first. With an applet, this could easily mean a substantial number of files that would have to be downloaded across the Web before the program could be executed. An applet might contain a dozen Java class files, some graphic picture files, and music in the form of .WAV files. Because Java relies on the HTML architecture, downloading each file would mean a separate web connection and negotiation. The user could be faced with a lot of waiting.
10.2.3.1 Java archives
Java solved this by allowing all the class files needed by a particular applet to be combined into one archive file that could be downloaded all at once. Early versions used a public domain format from PKZIP to encapsulate related files. JDK 1.1 introduced the concept of the Java Archive (JAR), which built upon the public domain PKZIP standard. Although Internet Explorer does support .JAR files, not all browsers do. Microsoft strongly encourages the use of its own .CAB (covered in Chapter 11) file archive for Java applets and other programs. When scanning your hard drive looking for Java-related files, many are sure to be located in .ZIP , .JAR , and .CAB compressed files. Example 10-4 shows what my simple example would look like if it downloaded in a .JAR file.
Example 10-4. HTML page loading sample applet in .JAR
<HTML> <HEAD> <TITLE> Draw a Square </TITLE> </HEAD> <BODY> Here is a sample square: <APPLET CODE="Sample.class" ARCHIVE="Sample.jar" HEIGHT=101 WIDTH=101 </APPLET> </BODY> </HTML>
Two factors drive the discussion of file archives and HTML tags. First, most of the time when active content programs are downloading to your machine, they don't announce their presence. If you can recognize the basic HTML tags that indicate the presence of executable content files, you can view the HTML source files of a suspicious page, after turning off the automatic execution of active code, before you commit to surfing it.
Second, it's necessary to understand all of the ways executable content can be delivered to your PC. You can see that a good antivirus program or firewall has to check for a lot of different file types and delivery methods in order to catch all the malicious mobile code that will be coming your way. Simply scanning your hard drive for class file extensions will not be enough.
Similarly, in the early days of computer virus writing, many malicious programs used popular archiving programs, like LHARC and PKZIP, to hide their presence. Virus scanners work by looking for particular strings of information to determine whether the suspected file contains a virus. Virus writers used file compression programs to archive their viruses. Compression programs change the virus's structure, while still allowing it to uncompress back into its original form and attack. Scanners had to learn how to recognize and uncompress standard archived files to examine them for viruses. It's common for malicious code authors to compress their creations using the latest compression engine, which scanners don't yet recognize, to temporarily thwart scanners. The best scanners have to recognize and uncompress archive files of all major formats, producing alot of scanning overhead.
10.2.3.2 Not all Java browsers are created equally
Each browser, including Internet Explorer, is allowed to implement its own JVM environment and define its own Security Manager and Applet Class Loader. Because of this there is no guarantee that Java security will be implemented equally across different browsers. Browser vendors can implement different security rules and policies. In fact, many Java bugs have affected either Netscape's or Microsoft's browser; but not both. This disparity between JVMs complicates Java security because it increases the number of potential security holes. Every new bug has to be tested against every JVM. Different vendors can fix the same holes in different ways, again complicating security research.
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 176