If anyone's interested in how the exploit works, here is my humble interpretation of the pastebin link:<p>jsaxton86's comment sets the scene nicely so I'll just copy it here:<p>"This family of JRE attacks is far too common. Basically, when an unsigned applet runs, the JRE tries really hard to prevent it from creating a ClassLoader object. However, if you manage to create a ClassLoader object, it's game over -- you can break out of the sandbox and do whatever you please."<p>The exploit is very clever, it never actually creates an instance of the ClassLoader object, but rather it uses Java reflection to call a particular method on a ClassLoader object, which was tricked into creation inside a separate exploit involving the JMX (Java Management Extensions) framework.<p>JMX has its own methods to instantiate classes, and a subclass of ClassLoader ("sun.org.mozilla.javascript.internal.GeneratedClassLoader") is passed in as a String; then the method defineClass is called via reflection in a way that deceives all the ClassLoader protection. Once this method is allowed to be invoked via reflection, it's "game over" as explained at the start.<p><a href="http://pastebin.com/raw.php?i=cUG2ayjh" rel="nofollow">http://pastebin.com/raw.php?i=cUG2ayjh</a>
<a href="http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html" rel="nofollow">http://www.oracle.com/technetwork/java/javase/tech/javamanag...</a>
<a href="http://www.cs.rit.edu/usr/local/pub/swm/jdoc6/com/sun/jmx/mbeanserver/MBeanInstantiator.html" rel="nofollow">http://www.cs.rit.edu/usr/local/pub/swm/jdoc6/com/sun/jmx/mb...</a>