Thwarting Malicious Java Attacks

By Gregory Yerxa  Since the birth of Java, evildoers have found and exploited its security problems. Protecting your users from malicious attacks via Java is necessary for a secure network. Updates in the Java Virtual Machine (JVM), Java Developer Kits (JDK) and Internet browsers have plugged many of the known holes, but network administrators still must protect their networks against attacks. Java applets and Java applications provide everything from reliable transactions to advertisements to content. From a user's viewpoint, it's nearly impossible to be completely safe from poorly written or malicious applets and applications. Although new browsers, such as Microsoft Corp.'s Internet Explorer 4.0, have features that let users define security ba sed on the location of the applet, users can not be expected nor allowed to define their workstation's level of security. Third-party products are arriving that will provide similar client-side protection regardless of the browser used, but administrators must initiate network-wide security policies that are robust enough to protect against an invisible threat. In Network Computing's University of Wisconsin-Madison lab, we evaluated the security issues and features built into Java. Standard Issue or Bolted On? Java adds valuable functionality and content to the Web and desktop. Right from the start, security and interoperability have been the No. 1 priorities of the Java language. Java, a WORA (write once/run anywhere) programming language, needs strong security mechanisms given its current uses. These security mechanisms are created during applet/application development and the actual JVM implementation. During development, the Java compiler enforces language specifications that reduce the s ecurity threat of Java programs. These specifications include type casting and pointer rules, as well as the use of class-based objects. For example, a programmer using the Java language cannot intentionally overrun a system buffer or corrupt the system stack to gain higher access to the system. Other development environments are prone to system overrun attacks. Consider the well-known sendmail bug or fragmenting ping attacks. The JVM is the second line of defense in Java's arsenal. When a Java applet or a standalone Java program runs, the JVM buffers all applet and program information. This gives the JVM more control over the execution of Java code than your system alone would. The presence of many different JVMs also can enhance the Java security mechanisms. Depending on the JVM developer, the Java security model may be expanded or cut down. Netscape Communications Corp., Microsoft and Sun Microsystems all have JVM implementations, with numerous differences. Sun's Applet Viewer, for example, provides for the use of access control lists, which give trusted applets more freedom. Microsoft's Internet Explorer 4.0 goes one step further, offering applets access to system resources. Get Your Pail and Shovel The Java security model is most often described using a sandbox metaphor. The JVM lets the applet or application play within the limits of the sandbox without risks. When the JVM executes a Java application or applet, it first creates a sandbox for each application. During execution, the JVM prevents each program from accessing or corrupting other sandboxes. It also monitors the Java code within the sandboxes to prevent malicious attacks or the nasty effects of negligent programming, such as indexing an out-of-bounds array. To understand past security risks and the potential for new ones, we must first understand the internal structure of the JVM itself.

Other Workshops Tuning NT: Is It Worth Your Time? By Jay Milne Related External Links java.sun.com/marketing/ collateral/security.html java.sun.com/security w3.org/security www.microsoft.com/ie/ie40/features/ ?/ie/ie40/features/sec-zones.htm www.cs.prince ton.edu/sip/ kimera.cs.washington.edu