Java: Breaking and entering?

In the beginning, there were two categories of Java code: trusted and untrusted. Trusted code—stuff built into the Java implementation or specifically designated apps running off local storage—had complete access to system resources and the full range of Java's powerful tools. Untrusted code—anything else, including any applet downloaded from a Web site—could only run inside a software "sandbox," severely limiting its power, flexibility and usefulness as an attack tool.

While that system is far from perfect it nevertheless does present a relatively simple risk-management decision. There is a small but significant chance that a hostile applet will break out of its sandbox and do serious damage. Unless the functionality of Web-based applets is worth the risk under specific circumstances, browsers should have Java disabled.

Unfortunately, that arrangement was too restrictive for Java developers looking to deploy "full-strength" Web-based applets. Sun responded with Java Development Kit (JDK) 1.1, which created a third category of Java code: the signed applet. Under JDK 1.1, a user downloading an applet accompanied by a valid digital signature is given the option of treating that applet as trusted code.

With JDK 1.2, Sun took the concept a step further by introducing the idea of partial trust. Now, by designating which capabilities to enable on a signature-by-signature basis, users can allow signed applets "partway out of the sandbox," permitting highly adaptable policies tailored to specific users.

So why is that a bad thing? Aren't increased flexibility and user control good things? In short, not always.

By introducing user choice, the new models make it much more difficult for IT managers to enforce a consistent security policy. As has been demonstrated repeatedly by the spread of e-mail attachment worms like the Love Bug, users tend to consider security an obstacle and will bypass it given the chance.

Moreover, the new security models add a great deal of complexity to an already intricate system. As seductive as it may be in software packages, complexity is almost always the enemy of security, making more opportunities for programming bugs, configuration errors and creative avenues of attack. A month after the release of JDK 1.1.1, for example, researchers at Princeton discovered a way to forge an applet signature—an attack that would have been meaningless under the original model.

The ideal solution to that problem would be to do away with the signed applet entirely. If a developer really needs to employ the full range of Java's functionality, he should do so with a locally stored application, not a Web-based applet. Because developers are unlikely to give up the potential for more powerful applets on their own, however, it is up to IT staff and end users to give them a nudge. In other words, when it comes to accepting signed applets, just say no!

David Raikow is a contributing editor to Sm@rt Partner. Column comments can be sent to smartletters@ziffdavis.com.