If you have an applet in a signed jar, the user gets prompted to execute the applet. If the user clicks "Run", the applets gets executed with full permissions. If, on the other hand, the user clicks on "Cancel", the applet gets executed with default applet permissions.
If you have an applet in an unsigned jar, it gets executed with default applet permissions without any user interaction. This is the case of the vulnerability. The default applet permissions are very limited, but they let you call most of the standard classes of Java, including that RMIConnectionImpl class. RMIConnectionImpl had a flaw, where it did privileged deserialization from an untrusted source and that flaw can be leveraged by an applet to elevate it's privileges. (For more details, see my original advisory).
Just to clear up some of the confusion. The news of the recent release fixing 29 vulnerabilities isn't directly related to the 3 vulnerabilities cited as the biggest Java threats, as fixes for these were released earlier. CVE-2008-5353 was fixed in December 2008 with Java 6 update 11. CVE-2010-0094 was fixed in the spring of 2010 with Java 6 update 19. CVE-2009-3867 was fixed with Java 6 update 17 (november 2009?).
Not that the latest version we're all running isn't vulnerable to a ton of other stuff.
Two of the three cited vulns aren't actually buffer overflows. It's badly written Java code that other Java code can exploit to escape from the sandbox.
CVE-2010-0094 is a privilege escalation vulnerability in the JVM. The applet does not need to be signed and the user does not need to click OK on any dialog window. Even though the flaw is in an RMI related class, the exploitation does not require RMI privileges. No RMI stuff actually takes place, it just happens that this class is a trusted JVM core class that could in the previous versions of Java be exploited into elevating untrusted applet code privileges, thusly escaping the sandbox.
Having escaped the sandbox the Java code can then do whatever it wishes, within the local privileges of the user running the browser process, including native code of the platform it's being run on.
Yes, the name of the vulnerable class is RMIConnectionImpl, but to exploit it no connections are necessary. It's a local sandbox-escape/privilege escalation for Java applets, basically.
Slashdot Mirror
You are correct that the OS limits the damage where configured properly, yes.
If you have an applet in a signed jar, the user gets prompted to execute the applet. If the user clicks "Run", the applets gets executed with full permissions. If, on the other hand, the user clicks on "Cancel", the applet gets executed with default applet permissions.
If you have an applet in an unsigned jar, it gets executed with default applet permissions without any user interaction. This is the case of the vulnerability. The default applet permissions are very limited, but they let you call most of the standard classes of Java, including that RMIConnectionImpl class. RMIConnectionImpl had a flaw, where it did privileged deserialization from an untrusted source and that flaw can be leveraged by an applet to elevate it's privileges. (For more details, see my original advisory).
Just to clear up some of the confusion. The news of the recent release fixing 29 vulnerabilities isn't directly related to the 3 vulnerabilities cited as the biggest Java threats, as fixes for these were released earlier.
CVE-2008-5353 was fixed in December 2008 with Java 6 update 11.
CVE-2010-0094 was fixed in the spring of 2010 with Java 6 update 19.
CVE-2009-3867 was fixed with Java 6 update 17 (november 2009?).
Not that the latest version we're all running isn't vulnerable to a ton of other stuff.
Two of the three cited vulns aren't actually buffer overflows. It's badly written Java code that other Java code can exploit to escape from the sandbox.
CVE-2010-0094 is a privilege escalation vulnerability in the JVM. The applet does not need to be signed and the user does not need to click OK on any dialog window. Even though the flaw is in an RMI related class, the exploitation does not require RMI privileges. No RMI stuff actually takes place, it just happens that this class is a trusted JVM core class that could in the previous versions of Java be exploited into elevating untrusted applet code privileges, thusly escaping the sandbox. Having escaped the sandbox the Java code can then do whatever it wishes, within the local privileges of the user running the browser process, including native code of the platform it's being run on.
Yes, the name of the vulnerable class is RMIConnectionImpl, but to exploit it no connections are necessary. It's a local sandbox-escape/privilege escalation for Java applets, basically.