See story in The Register about this:
"A vulnerability in a Java plug-in from Sun Microsystems used by most web browsers poses a risk for users of IE and alternative browsers alike. Because of the flaw, malicious applets can escape the safe confines of a sandbox and damage vulnerable systems.
Java Runtime version 1.4.2_05 and older are vulnerable. According to Finnish security researcher Jouko Pynnonen, who discovered the problem, the risk is not limited to IE users but also affects Mozilla Firefox both on Windows and Linux systems. Opera users also at risk.
Similar vulnerabilities have been widely exploited by malicous websites in the past. ..."
The article references another site that describes the vulnerability:
"...A vulnerability in Java Plugin allows an attacker to create an Applet which can disable Java's security restrictions and break out of the Java sandbox. The attack can be launched when a victim views a web page created by the attacker. Further user interaction is not required as Java Applets are normally loaded and started automatically.
Such Applet can then take any action which the user could: browse, read, or modify files, upload more programs to the victim system and run them, or send out data from the system. Java is a cross-platform language so the same exploit could run on various OS'es and architectures.
Details
There is a number of private Java packages in the Java VM, meant to be used only by the VM internally. Java Applets can't normally access these packages because of security concerns. Attempting to access them normally results in an AccessControlException.
The problem is that JavaScript code can bypass the access control by using so called reflection API. The following piece of example JavaScript acquires a reference to a supposedly restricted, private class "sun.text.Utility":
[script language=javascript]
var c=document.applets[0].getClass().forName('sun.text.Utility');
alert('got Class object: '+c)
[/script]
This isn't possible by a normal Java Applet, and shouldn't be for JavaScript either. The JavaScript code could now instantiate the class or pass it to an Applet that could use it.
An attacker can't do much with the utility class in this example, but could use other private classes to exploit the vulnerability. Some of them allow e.g. direct access to memory or contain methods for modifying private fields of other Java objects. The latter allows an attacker to simply turn off the Java security manager, after which there is no sandbox restricting what the Applet can do. ...."
If you are using Sun Java, and have a version of 1.4.2_04 and 1.4.2_05 (and possibly/probably earlier versions), then to close this hole, you need to get an updated version of Sun Java
"A vulnerability in a Java plug-in from Sun Microsystems used by most web browsers poses a risk for users of IE and alternative browsers alike. Because of the flaw, malicious applets can escape the safe confines of a sandbox and damage vulnerable systems.
Java Runtime version 1.4.2_05 and older are vulnerable. According to Finnish security researcher Jouko Pynnonen, who discovered the problem, the risk is not limited to IE users but also affects Mozilla Firefox both on Windows and Linux systems. Opera users also at risk.
Similar vulnerabilities have been widely exploited by malicous websites in the past. ..."
The article references another site that describes the vulnerability:
"...A vulnerability in Java Plugin allows an attacker to create an Applet which can disable Java's security restrictions and break out of the Java sandbox. The attack can be launched when a victim views a web page created by the attacker. Further user interaction is not required as Java Applets are normally loaded and started automatically.
Such Applet can then take any action which the user could: browse, read, or modify files, upload more programs to the victim system and run them, or send out data from the system. Java is a cross-platform language so the same exploit could run on various OS'es and architectures.
Details
There is a number of private Java packages in the Java VM, meant to be used only by the VM internally. Java Applets can't normally access these packages because of security concerns. Attempting to access them normally results in an AccessControlException.
The problem is that JavaScript code can bypass the access control by using so called reflection API. The following piece of example JavaScript acquires a reference to a supposedly restricted, private class "sun.text.Utility":
[script language=javascript]
var c=document.applets[0].getClass().forName('sun.text.Utility');
alert('got Class object: '+c)
[/script]
This isn't possible by a normal Java Applet, and shouldn't be for JavaScript either. The JavaScript code could now instantiate the class or pass it to an Applet that could use it.
An attacker can't do much with the utility class in this example, but could use other private classes to exploit the vulnerability. Some of them allow e.g. direct access to memory or contain methods for modifying private fields of other Java objects. The latter allows an attacker to simply turn off the Java security manager, after which there is no sandbox restricting what the Applet can do. ...."
If you are using Sun Java, and have a version of 1.4.2_04 and 1.4.2_05 (and possibly/probably earlier versions), then to close this hole, you need to get an updated version of Sun Java
so no foreign language pleeeeeze!!
