| If anyone's interested in how the exploit works, here is my humble interpretation of the pastebin link: jsaxton86's comment sets the scene nicely so I'll just copy it here: "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." 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. 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. http://pastebin.com/raw.php?i=cUG2ayjh
http://www.oracle.com/technetwork/java/javase/tech/javamanag...
http://www.cs.rit.edu/usr/local/pub/swm/jdoc6/com/sun/jmx/mb... |