US CERT reports:
Java 7 Update 10 and earlier versions of Java 7 contain a
vulnerability that can allow a remote, unauthenticated
attacker to execute arbitrary code on a vulnerable
system.
The Java JRE plug-in provides its own Security Manager.
Typically, a web applet runs with a security manager
provided by the browser or Java Web Start plugin. Oracle's
document states, "If there is a security manager already
installed, this method first calls the security manager's
checkPermission method with a
RuntimePermission("setSecurityManager") permission to ensure
it's safe to replace the existing security manager. This may
result in throwing a SecurityException".
By leveraging the vulnerability in the Java Management
Extensions (JMX) MBean components, unprivileged Java code
can access restricted classes. By using that vulnerability
in conjunction with a second vulnerability involving the
Reflection API and the invokeWithArguments method of the
MethodHandle class, an untrusted Java applet can escalate
its privileges by calling the the setSecurityManager()
function to allow full privileges, without requiring code
signing. Oracle Java 7 update 10 and earlier Java 7 versions
are affected. The invokeWithArguments method was introduced
with Java 7, so therefore Java 6 is not affected.
This vulnerability is being attacked in the wild, and is
reported to be incorporated into exploit kits. Exploit code
for this vulnerability is also publicly available.
Esteban Guillardoy from Immunity Inc. additionally clarifies
on the recursive reflection exploitation technique:
The real issue is in the native
sun.reflect.Reflection.getCallerClass method.
We can see the following information in the Reflection
source code:
Returns the class of the method realFramesToSkip frames
up the stack (zero-based), ignoring frames associated with
java.lang.reflect.Method.invoke() and its
implementation.
So what is happening here is that they forgot to skip the
frames related to the new Reflection API and only the old
reflection API is taken into account.
This exploit does not only affect Java applets, but every
piece of software that relies on the Java Security Manager for
sandboxing executable code is affected: malicious code can
totally disable Security Manager.
For users who are running native Web browsers with enabled
Java plugin, the workaround is to remove the java/icedtea-web
port and restart all browser instances.
For users who are running Linux Web browser flavors, the
workaround is either to disable the Java plugin in browser
or to upgrade linux-sun-* packages to the non-vulnerable
version.
It is not recommended to run untrusted applets using
appletviewer, since this may lead to the execution of the
malicious code on vulnerable versions on JDK/JRE.