CVE-2012-4681 Java 7 0-Day vulnerability analysis
http://www.deependresearch.org/2012/...-analysis.html
It looks like you will want to stay with Java 6 till this hole gets fixed.
Considering that Rapid 7 posted a working exploit and addition to the exploit packs is imminent (Attackers Pounce on Zero-Day Java Exploit by Brian Krebs), plus other analysis articles are being published such as New Java 0day exploited in the wild -by Alienvault, we decided that witholding details of the exploit will not offer additional protection but only hinder development of protection and signatures.
As we mentioned earlier, we contacted Michael Schierl, the Java expert who discovered a number of Java vulnerabilities and asked him to have a look. He sent back his detailed analysis, exploit source, the interim patch with the source code of the patched class.
...
The rest of the exploit is "only" using that reference to call the
GetField method, which can be used to get access to private fields
(which should not be a problem as the class is in a restricted package),
to get access to a field that stores the permissions for running a
java.beans.Statement.
A Statement is created that disables the security manager (by default
with permissions of the untrusted code). But before calling the
statement, the permissions stored in that field we just got access to
are overwritten with permissions that allow running all code, and the
statement can be called now and disable the security manager for us. At
this point, no security manager is left, and the applet can do anything
Java can.
As we mentioned earlier, we contacted Michael Schierl, the Java expert who discovered a number of Java vulnerabilities and asked him to have a look. He sent back his detailed analysis, exploit source, the interim patch with the source code of the patched class.
...
The real vulnerability seems to be inside the new Java7 class
com.sun.beans.finder.ClassFinder,
com.sun.beans.finder.ClassFinder,
which seems to make it possible for untrusted code to get access to
classes in restricted packages (i. e. packages that are part of the
security implementation itself and where usually untrusted code cannot
get either access or call it).
At the beginning, the exploit uses that ClassFinder class to get a
reference to the sun.awt.SunToolkit class (sun.* is a restricted package).
classes in restricted packages (i. e. packages that are part of the
security implementation itself and where usually untrusted code cannot
get either access or call it).
At the beginning, the exploit uses that ClassFinder class to get a
reference to the sun.awt.SunToolkit class (sun.* is a restricted package).
The rest of the exploit is "only" using that reference to call the
GetField method, which can be used to get access to private fields
(which should not be a problem as the class is in a restricted package),
to get access to a field that stores the permissions for running a
java.beans.Statement.
A Statement is created that disables the security manager (by default
with permissions of the untrusted code). But before calling the
statement, the permissions stored in that field we just got access to
are overwritten with permissions that allow running all code, and the
statement can be called now and disable the security manager for us. At
this point, no security manager is left, and the applet can do anything
Java can.
This method of abusing restricted package permissions is new to me (it
does not work in Java 6 either as GetField was private there); but it is
not unique - there are several ways you can use to get out of the
sandbox if you have access to restricted packages - usually they need a
bit more code though.
does not work in Java 6 either as GetField was private there); but it is
not unique - there are several ways you can use to get out of the
sandbox if you have access to restricted packages - usually they need a
bit more code though.
What makes the code a bit more complex is the fact, that the bytecode
verifier also tries to verify if you are accessing restricted packages,
therefore all access to restricted packages has to be done indirectly
(that is also good for obfuscation, but here needed to make the exploit
work, too). ~ Michael Schierl
verifier also tries to verify if you are accessing restricted packages,
therefore all access to restricted packages has to be done indirectly
(that is also good for obfuscation, but here needed to make the exploit
work, too). ~ Michael Schierl