Princeton team finds Java glitch
A team of Princeton University computer scientists find a new security flaw in Java that could let a hacker gain unauthorized access to a computer by impersonating a "trusted" software publisher.
The security flaw is related to a feature in the new version of Sun Microsystems' (SUNW) Java Development Kit 1.1.1 that allows programs stamped with a digital signature to bypass Java's normal security restrictions. A sophisticated hacker could exploit the glitch to pretend to be a trusted publisher to whom the user has already granted access privileges such as reading or modifying private files on that user's hard disk.
Sun has tried to make Java more powerful by allowing programs to venture outside the "sandbox," a security area that prevents code from freely roaming a user's hard disk. However, in doing so the company may be opening Java up to some of the security problems that have traditionally bedeviled Microsoft's ActiveX technology.
Today, representatives of Sun's JavaSoft said they are aware of the problem and will release a fix for the breach to its Java licensees within the next 48 hours. JavaSoft will also release a new version of the development kit, 1.1.2, within a few weeks that will fix the security bug.
Marianne Mueller, a security expert at JavaSoft, said the company was notified of the problem last week and has been working on a fix since then.
Mueller added that Sun's HotJava browser would be affected by the glitch since it is based on JDK 1.1.1. The latest preview release of Netscape Communications' Communicator browser also supports the new kit, but both JavaSoft and Netscape said that Communicator is not affected because of code changes Netscape made to its Java Virtual Machine.
Microsoft's Internet Explorer browser doesn't yet support the new development kit so it is also unaffected by the bug.
The problem was discovered by a team of computer scientists at Princeton led by Edward Felten. The group has found several Java security problems before, as well as glitches with Microsoft's Internet Explorer 3.0 browser.
"The flaw we found allows an applet to change the system's idea of who signed it," reads a posting on the Princeton team's Web site. "The applet can get a list of the all signers known to the local system, determine which if any of those signers is trusted, and then the applet can relabel itself so it appears to have been signed by a trusted signer. The result is that the applet can completely evade Java's security mechanisms."
Trusted publishers are companies that have stamped code with their digital signature. If a piece of code performs a malicious action, such as deleting a file or installing a virus, users can track the publisher down and prosecute them, using the digital signature as evidence.
Today, Felten said that in spite of the latest Java bug he still thinks Java is more secure than ActiveX because it gives trusted publishers access to very specific access to system functions. In contrast, if a user accepts an ActiveX control, the code is free to do anything it wants.
"There are still advantages to using Java even with the Java trust model," Felten said. "Signed applets in Java give you the possibility of grades of trust. ActiveX is inherently all or nothing."
But like ActiveX controls, Java applets will increasingly rely on users to make decisions about which applets to trust and which ones to reject. That could lead to scenarios in which a user inadvertently accepts malicious code, experts say.
"Often some of the onus of deciding who to trust is foisted upon the user," said Gary McGraw, a research scientist at Reliable Software Technologies and coauthor, with Felten, of a book on Java security. "Sometimes too much choice is a little bit daunting and not a good thing."
Interestingly, Felten's persistent hunting for Java security bugs has earned him the gratitude, rather than enmity of Sun, both parties say. Sun has donated money to Felten's security research projects and regularly sends his team source code when new versions of the kit become available.