News

Sun in hot water over Java security hole

Sun Microsystems has disclosed a serious vulnerability in the Java Plug-in technology within the Software Developers’ Kit (SDK) and the Java Run-time Environment (JRE) that allows attackers to bypass the Java sandbox and Java applet security.

The specific problem exists within the access controls of the Java-to-Javascript data exchange in web browsers that use Plug-in technology, and lets Javascript to load an unsafe class - something usually impossible. As a result, a remote attacker could execute hostile applets to access, download, upload or execute arbitrary files, as well as access the Java Virtual Machine user’s network.

"If someone has found interaction between the Javascript running within the HTML on your webpage and a Java applets, it’s very serious, as the script can now command the applet to do something its shouldn’t," said Bruno Beloff, technical director at ASP Class Calendar. Most seriously, he went on, "I see no mechanism whereby someone using Plug-ins can be notified to collect a fix."

The episode is potentially damaging for Sun. Its chief executive officer Scott McNealy has repeatedly emphasised the secure nature of Java in comparison to Microsoft's alternatives.

Beloff said McNealy’s claims for Java were "reasonable, because it was designed to be more secure, and it’s a good design".

He added that the idea of the sandbox, put forward by Sun in the mid-1990s to enable applets to run within protected environments, was "very good from the security point of view" and one which, at the time, had distinguished Java applets from rival technologies such as Microsoft’s COM components.

In disclosing the vulnerability, Sun says there is no workaround, and recommends that users of SDK and its JRE subset move to versions 1.4.2_06 and later or 1.3.1_13 and later - both of which are available from java.sun.com.

Security intelligence company iDefense, on the other hand, said "disabling Java or JavaScript will prevent exploitation as the vulnerability relies on the data transfer between the two components".

Worse still, it goes on to point out that "other Java Virtual Machines, such as the Microsoft VM, are available and can be used as an alternative".

Rik Turner writes for Techworld.com


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
 

COMMENTS powered by Disqus  //  Commenting policy