Plugs for Java's Security Holes

The Java security model is not perfect. Devious developers can create Web-embedded Java programs, known as hostile applets , that can make life miserable for Web users. The good news is that JavaSoft's revamped security model, which will evolve over the next year, may shore up Java's current security weaknesses.

Hostile applets divide into two groups: attack applets , which cause dangerous security breaches, and malicious applets , which are annoying rather than destructive. Although less harmful, mali cious applets are insidious because you might load one on your machine simply by surfing to a Web page.

What Applets Shouldn't Do

Java's run-time processing enforces severe limitations on what applet-related classes can do. Applets, for example, cannot read or write to the disk.

However, an attack applet still could corrupt data on your hard drive, reveal private data to third parties, infect your machine with a virus, or install a trapdoor to your machine. A cracker could attain his or her ultimate goal -- complete control of your machine.

To date, we know of eight serious security problems in Java implementations, ranging from Domain Naming System (DNS) name-resolution problems to type confusion. One serious flaw, discovered last August, was in Microsoft's implementation of how Java checked whether a class was allowed to be a member of a particular package. An attack applet could change security parameters and ultimately gain full access to the victim's files and network. This flaw in Microsoft Internet Explorer 3.0 Beta3 was fixed in Explorer 3.0.

These attac ks are not hypothetical. Every attack has been implemented by the Safe Internet Programming team at Princeton University (led by one of the authors) to break into a test machine in the lab.

Our analysis demonstrated that attack applets require in-depth understanding of complicated Java and Internet issues to pull off. Nevertheless, it takes only one person to devise a novel attack applet; once loose, information about it would spread quickly throughout the cracker community.

Even the lesser malicious applet can disrupt your local system and invade your privacy. Malicious applets written by miscreants currently can forge mail from you to anyone saying anything, steal your machine cycles to perform their own work while your processes languish, and crash your local system by sucking up system resources. There are also malicious applets created simply to annoy: Play sound files forever, monitor your Web use, and display unwanted graphics.

New Model

To fight hostile applets, JavaSo ft will redo Java's security model over the next year (see the Core Tech article "Java Security and Type Safety" [not available on-line until the end of March 97]). The first enhancement will appear in JDK 1.1, due early this year. Signed applets would contain the creator's encrypted signature to help determine whether they can go beyond the "sandbox" -- the secure browser partition where applets normally run. Trusted applets could read or write to local storage or access a uniform resource locator (URL) other than their own.

Signing is not very robust. It doesn't stop applets from inflicting damage; it just tells you whom to blame. And it's all or nothing: You either trust a signed applet outside the sandbox or you don't.

A better alternative allows finer control over a program. Later this year, you should be able to grant specific permissions to Java programs, choose a different security policy for each program, and even change policies on the fly. For example, you could keep applets in the sandbox unless they originate from a trusted site, or allow some applets to read from (but not write to) local storage devices.

Will these improvements plug all possible security holes in Java? Even JavaSoft's security architect, Li Gong, says it probably won't. "We can't guarantee the security model 100 percent," he says, "[it's] how that model is implemented when it comes to writing the code."

---

Security Site

For more information about Java security, visit the Princeton Safe
Internet Programming team's Java Security FAQ at

http://www.cs.princeton.edu/sip/java-faq.html
 
and the authors' Web site at 

http://www.rstcorp.com/java-security.html
.

---

Applets vs. Applications

                           
Read/write
    
Access any
    
Call
          
Code

                           
local
             
URL
       
native
        
signing

                           
storage
                     
code


Applets (JDK 1.02)         No            No            No             No 
Applets (JDK 1.1)          Optional*     Optional      Optional       Yes 
Applets (future JDK)       Selectable**  Selectable**  Selectable**   Yes 
Applications (JDK 1.02)    Yes           Yes           Yes            No 
Applications (JDK 1.1)     Yes           Yes           Yes            No 
Applications (future JDK)  Selectable**  Selectable
**  Selectable**   Yes 


 *Browsers can offer users the option of relaxing security
  restrictions based on whether or not an applet carries the
  authenticated signature of its creator, and whether the creator is
  trusted.

**Applets and applications can offer users more versatile options
  based on signing, the code's point of origin, or the type of action
  the code is attempting to do.

---