dcsimg
RealTime IT News

Sun Flaws Make Contest Fodder

Sun Microsystems has asked the developer community to help it attack the new security enforcement component in the upcoming version of Java Platform, Standard Edition (Java SE).

The company launched the "Crack the Verifier" challenge Monday, making Java SE 6.0 binaries and source code available under its Java Research License (JRL) to any interested parties.

The challenge is designed to look for flaws in both the implementation and the specification itself. Work on the technology is currently under way in the Java Community Process (JCP), under Java Specification Request 202 (JSR-202), "Class File Specification Update."

Sun developers are looking for two things: whether there are any bugs in the new verifier and whether the whole thing is fundamentally flawed and needs to be scrapped.

Graham Hamilton, vice president and fellow on the Java platform team, said that while he's hoping for the former, the latter means a missed opportunity for the Java community but the ability to replace the new technology with the existing verifier in time to launch Java SE 6.0 next summer.

There are three ways developers can look for bugs to squash: They can look for a flaw in the type-checking verifier specification within JSR-202; they can look for an ambiguity in the wording of the specification that would lead to an unsafe implementation; or they can find a flaw in the implementation Sun has provided within the snapshot builds of Java SE 6.0, code-named Mustang.

Contest entries will be accepted until Jan. 31, 2006, and judged by a panel of Sun engineers who will determine if the submitted bugs compromise the Java security model.

Those who find a significant flaw in the specification will be brought on stage during the keynote speech at JavaOne next year. Discovered flaws in the implementation will receive acknowledgment on the Java.net Web site.

Sun is fundamentally changing the way Java handles security through its applets . Java creates a "sandbox" when applications are executed in, say, the Web browser. While the applet can use some systems resources to run the program, the application doesn't normally have the permissions to write to the hard drive or scan a computer's innards.

In the existing Java code, Sun uses a byte-code verifier that monitors incoming applets and verifies that all the byte codes are structured correctly so it can't break out of the security model, Hamilton said.

The new type-checking verifier, which has been under development for the past three years, handles incoming data very differently, he said. If successful, it will result in about 50 percent performance gains while using less system memory to run the applet.

Sun officials realized that at a time when the company is opting for a more open approach to its software, it might be a good idea to open the security code to the community at large.

Hamilton said the company's first instinct was to keep it a secret, but then reconsidered releasing the source code and decided to ask for help.

"It's kind of scary but if you want people's help in finding holes you have to give them full access," he said.

Originally, the new verifier technology was intended for release in Java 2, Standard Edition 5, but officials felt it wasn't ready for deployment when it came time to launch the updated Java code.